Skip to main content

What is Agile?

I almost didn't go to the Agile Business Conference in London, but I am glad I did.

My introduction to Agile was Scrum, through which I discovered XP and Lean. Artem reported from Toronto that Agile seemed to be focusing around Scrum and XP, and that the two factions were putting their internal rivalries behind them and calling the results 'Agile'.

Scrum and XP were not very visible at this conference. Present yes, for instance in the Keynote from Borland, but both ceded the limelight in deference to DSDM, the host of the event.

I discovered agile is a much wider than 'just' Scrum and XP, so wide that it risks turning into a bandwagen and losing all meaning. Many methodologies and frameworks were present, including DSDM, RUP (an excellent presentation from BJSS discussed developing a real time trading system using what was clearly RUP, even though they didn't call it by name), and OpenUP.

OpenUP is an attempt to turn RUP, a humungous methodology which usually needs extensive tailoring, into a slim framework which can be complemented with useful practices. However if they really want to end the "Process Wars," OpenUP's proponents should send fewer barbs and FUD in the direction of Scrum. At this point, I should probably refrain from saying that you can tell this comes from IBM. Oops.

I even heard one company say, 'we eliminated most documentation, so now we are agile.' Dilbert lives.

There were several really excellent talks, including three keynotes, and the discussions in the halls was just amazing. I learned a lot and met many interesting people! I even learned that RUP can be agile, and it is possible to develop successful projects with it.

What are my key learnings?
  • Agile is first and foremost about values. Honesty, openness, trust, courage and a responsible attitude towards money. Values are an excellent place to start the agile discussion with top management, particularly since the symptoms are magnified at that level.
  • Adopting agile values is the place to start. It is a strategic decision by top management. It is in their interest, even though they will need some convincing
  • The dangers of just 'doing agile' are substantial. So use a name brand framework and follow it to the letter for your first agile projects. As you do it, that framework will evolve to meet the needs and character of your organization. But if you start off by improvising, you will end up with a mess.
  • As a manager, start doing Scrum as the first concrete step in this direction. Scrum is a simple management practice to effectively organize teams. It's OK to start with small steps to build confidence. As confidence increases, Scrum can be applied in a broader context.
  • XP is the next step. (If you're a developer, start here, but try to get some sponsorship from higher up). The teams are encouraged to introduce solid engineering practices. XP's vision of a tightly integrated customer is what a Scrum Product-Owner should evolve into.
  • Lean principles provide additional important context for making good decisions to improve effectiveness, but don't get preoccupied with getting too lean too quickly.
Where will this take us? Agile offers a vision of dramatically improved communication, because the impediments to communication (e.g. mistrust) are removed. Dramatically improved effectiveness and productivity will follow.

What would it be like, when IT's ability to deliver value were not the limiting factor in your company's ability to deliver new value to your customers? It could happen and agile is making it happen.


Unknown said…
Would you mind elaborating on the "dangers" of following a customised methodology over a "named brand framework"? My company is taking steps to adopt Agile practices for the management of projects, but have found the information about Scrum to be somewhat insufficient in our web development agency, multi-project, multi-team environment, so we are thinking a customised process tailored to our organisation would be better.
Peter said…
If you are a master level practitioner, there is no problem improvising. Scrum and XP evolve to meet the needs of your situation.

The problem comes from either a) having no methodology or b) improvising as a beginner, i.e. without the experience to make good judgements about what practices to adopt and what to keep.

The danger is you suppress important practices (usually to protect dysfunctions in the company) and end up with no (useful) methodology.

So think Shuhari: start with Scrum or XP, follow the book for 6 months, get some training and coaching along the way, and then start to adapt the process if you fee a need to.
Great post, and I totally agree with Peter's comment back to Neil.

I want to elaborate a little further on the denominations of agile.

If you are adopting Agile bottom-up from a tech team perspective... start with XP. If you are adopting agile top-down from a business perspective, start with Scrum.

And yes, at Agile 2008 in Toronto, during the keynote banquet Uncle Bob Martin basically declared that XP and Scrum need to unite and that they complement each other. I attribute this to the fact that XP focuses on engineering practices and Scrum focuses on PM approaches. Someone at ObjectMentor once told me that XP is the content and Scrum is the box it ships in.

This whole thread will provide some good food for my own blog content.
Peter said…
Hi Kevin,

While we are scratching each other's back, I will say that I totally agree with your statement, if your doing agile bottom up, start with XP. My advice was intended for managers and I have updated the post to reflect that.

More generally stated, start within your own jurisdiction.

BTW - Developers were the early adopters of Agile. We're now getting to the Early Majority phase, so managers are getting involved (we won't say, taking over, because they're not!)
Unknown said…
Thanks for your response Peter. On reflection I think I should be asking a different question; our current exposure to Scrum is limited - we understand the principles and intend to follow it to the letter, however, our exposure to date has not covered the subject of how to do it in a multi-client, multi-project, multi-disciplinary team, agency environment where we tend to schedule jobs months in advance. This is where we are thinking we need a customised methodology - but maybe customised is wrong, maybe the more appropriate word is extended.

So, have I just not found the right information within Scrum on how to cope with this yet? If not, do you know of ay good resources online that discuss solutions to problems like this?

Your advice is most welcome - we are currently deciding on whether to spend several thousand GBP on scrum master courses or 3 times as much on an on-site training course on a methodology customised to our organisation.
Peter said…
Hi Neil,

Gee, I'd like to have you as a client! ;-)

I used to work for a web agency. Very dynamic with a very large number of relatively small projects (and maybe a few big ones).

The scrumdevelopement group is a good source for information exchange on Scrum. I'll be kicking off a sort of "ask the expert blog" but it's not quite ready for the announcement. Real Soon Now.

I believe in your environment a strong team concept (i.e. Scrum) is very important for working productively. The basic idea is bring work to teams rather than people to projects. This will massively reduce the churn on scheduling people and also reduce the contention for critical resources (otherwise known as people).

So I don't think (at least based on my previous experience) that you'll change Scrum very much, but you will change your company quite a bit! And you'll be much stronger because of it. And coaching is very important in the process. It keeps you from going off cliffs.

BTW - I just updated my courses; you might want to take a look at Agile Project Management for Scrum Teams. It's more a getting started course for the whole team than the targeted Scrum Master training that is the CSM.


Unknown said…
Thanks again for your response, I'll check out the scrumdevelopment group. Just looked at your course, sounds good except for 2 things - you're in Zurich and the course language is German and we're in England and my German is limited to "Wie komme ich am besten zum bahnhof bitte?" ;-)

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…