Agile Project Management with Scrum

by oneafrikan on June 9, 2005

I was at an Agile Project Management with Scrum seminar yesterday, held at the Conchango offices in London and conducted by Ken Schwaber. Overall I found it very interesting, pretty useful, and I want to share some of what I took away here with you. It’s not exhaustive, but it will make things a bit clearer for you.

Background:
Projects fail. Lot’s of them. Ken quoted the “Standish report” for a rundown on how many projects actually do fail and why. The how and why isn’t really as important as the result, which is a widening trust gap that exists between the consultant and the service provider or client. Bottom line: clients know they need help, but they don’t necessarily trust you to deliver that help.

There are many methodologies that one could use for projects, chief among them Prince2 and SSADM. Both are quite mature, and use the waterfall approach – requirements, specification, design, build, test, deploy, support etc etc.

Ken made the point that in the past, there were good developers, but they had to crank out code by hand. In effect, they were limited by the tools available to help them be more efficient. Now, there are still good developers, but their sophistication has grown, their experience has grown, and they have much better tools that help them do much more than ever before. This is relevant because when the above project management methodologies were developed, they were developed in an environment which is a lot different from common environments of today. Things today can be changed and debugged a bit easier then they used to be.

Another point that he made was that the people who actually write the methodologies do not use the methodology they write about to produce it – they use an Agile approach. That is pretty interesting, although I’m sure some would argue against that.

What is the Agile approach:
Agile Project Management is a light, low ceremony, low overhead, fast moving approach, which empowers the builders to figure out how to do it themselves. It aims to move away from a cumbersome, prescriptive approach (where commonly 65% of functionality is not used) to a flexible and responsive appraoch where you inspact and adapt as you move from Scrum to Scrum.

The Scrum approach involves the Product owner or customer, the Team and the Scrum Master or Project Manager.

Typically, as a product owner or customer, you would work with the Team to develop a list or inventory of needs called a product backlog, in order highest importance.

The Team then figures out what they think they can deliver in a 30 day Sprint, and then they are given the space to go and do it. They meet every day to discuss what they are going to do for that day, so in effect they self-organise.

The Scrum Master becomes an individual who has responsibility, but no authority, who’s main objective is to remove impediments, keep distractions away from the Team, and to keep the Product owner from asking for more features or changes during the 30 day print.

At the end of the 30 day Sprint, the Team presents what they have done, which is typically working, production quality software, to the Product owner.

The Product owner then assesses what has been delivered, and what needs to be done next, so that the process can be recycled.

Now, this does two very important things:
1. The Product owner sees actual working software early on, which engenders trust, and empowers them to ask the Team to develop software that they want and need.
2. It means that if things are going pear shaped, or they’ve been hitting the wrong nail for some reason, then things can either be stopped, or re-directed – so instead of waiting 6 months and spending $nK on something before actually seeing it.

It’s an iterative, incremental approach, which yields results quickly. And that is good.

How do you decide what tasks are most important?
This is actually the key to the whole aproach, in my humble opinion, because if the Team is out building stuff that doesn’t add value to your business straight away, then they’re doing the wrong work. But, and this is a very big BUT, this is the Product owners responsibility, and only theirs.

Ken continually made the point that the Team is merely an engine which takes in the product backlog, and spits out software. It’s not a business team that’s there to decide what is most important for your business. Nor can it make decisions on how to fix problems. it’s an engine and you must treat it as such. So, to keep the metaphor going, the product backlog is the petrol which drives the engine, so this petrol has to be the right stuff.

To determine what is highest priority, list the items that you feel are most important, and assign them a business value on a scale which you feel works for you. Work with the Team to assign a cost value to each item in the product backlog. Soon, you should get an idea of what items are very important to you, and which ones are most expensive. The combination of this should give you a more concrete view of what needs to be tackled first.

One of the last points that Ken made was that Scrum is not a silver bullet – whatever problems you had before the project started will still exist.

My personal impressions:
Scrum makes sense. Personally, I’m an agile type of person. I like to move fast, making decisions and acting on them, so this kind of an approach appeals to my nature. From a business point of view, it really starts making sense when you consider the number of projects that start and don’t finish, or start with one aim in mind, and end up being completely different to what the client wants.

    Scrum enables you to get software you can see quickly.
    It enables you to limit risk by working in short 30 day Sprints – you can adapt and iterate as you go.
    It also creates buy in from within the business by demonstrating progress

Something to consider is that if you have a need within your business that could change at any given time, for whatever reason, then if you’re locked into a long project management cycle with inflexible contract terms and very tight specifications, then that can be a double edged sword – you lose the ability to change according to your current business needs, and more importantly you end up with something that may not suit your needs after all.

So what do you do?
Well, Scrum is a new approach that is starting to gain a lot of ground. I think that most early adopters will be looking at it already, and I suspect that most vendors will be doing some elements of Scrum already, although they may not call it such.

If you are a vendor, buy the book and read it – you won’t be sorry. Better yet, discuss it among your colleagues and ask yourselves if what you’re doing now can be improved upon?

If you’re looking to start a project, and are assessing vendors, then the following questions should be helpful:

Does your vendor release builds often, so you can see progress?
Does your vendor keep you in the loop continuosly?
Do you get the same version of the project plan that your vendor uses, and their developers use?
Do you actually get to speak to the developers who are writing the code you will end up using?
Are you paying for testers, who are actually sitting around twiddling their thumbs most of the day, as there isn’t anything to test?

What do you think?

Links:
_ Agile Project Management with Scrum
_ Standish report
_ Google: SSADM
_ Google: Prince 2
_ Conchango
_ Control Chaos
_ Advanced Development Methods Inc.
_ Agile Alliance

_ I’m going to post this on the Open Box Software blog as well

One comment

[…] neafrikan.com » Blog Archive » Agile Project Management with Scrum oneafrikan.com » Blog Archive » Agile Project Management with Sc […]

by Julian On Software » oneafrikan.com » Blog Archive » Agile Project Management with Scrum on March 9, 2006 at 10:39 am. Reply #

Leave your comment

Required.

Required. Not published.

If you have one.

Protected with IP Blacklist CloudIP Blacklist Cloud