Re: [scrumdevelopment] Scrum 9 Months On
- Great Story Richard!
Great to see all of the benefits you are experiencing. This is just the start. Now that Scrum is working, you can look at the plethora of other engineering, design, and testing techniques that will further your teams progress. You can also take this the other way - into the field, to incrementally test ideas and understand what the marketplace is demanding for new features, or new products.
Another direction to consider is adding Lean to the team's toolset, especially if you are automating business processes. Lean provides a toolkit that is complementary to Agile, and can help define the right requirements for the system under development.
On 10/28/06, Richard Banks <richard.banks@...> wrote:
I'm about 9 months into doing scrum where I work and took time to take stock over what has changed since then.
I posted the article on my blog at http://richardsbraindump.blogspot.com/2006/10/scrum-9-months-on.html but it's here in full to avoid having to go there and read it.
Hopefully there's something in there that can help you. And feel free to use it as a success story if you need some ammunition with your management.
P.S. I'll be off the air over the next few days, so I'll respond to comments after I get back.
Oh, I shouldn't forget... To the people who started the agile movement I can only say THANKYOU!!!
Some time ago I posted about how I completely screwed up the introduction of Scrum into my organisation. I talked about the problems I had trying to do it piecemeal and some of the mistakes I made.
Well, I'm happy to say that since I went back to the drawing board 9 months ago and started again that Scrum is not only well implemented in product development but the principles of scrum are starting to filter through to other areas of the business.
I've taken a look around me now and tried to determine what has changed in the last 9 months. If you're thinking about implementing scrum in your organisation here are some of the good things that can happen.
The product development area now really owns what they are doing and takes pride in delivering a visible product increment every two weeks. Not only do they own what they are doing but they also look out for each other as well. There's a genuine sense of camaraderie and teamwork evident in the place that other parts of the business have noticed.
The teams within product development are also acting more responsibly in their coding, testing and design efforts. They want to ensure that quality is shown from the start, instead of being a bolt-on at the end of the development process. While anyone will claim responsibility for things that work well few people will stick their hands up and claim responsibility if they screw up. The team has learnt that taking responsibility for failure is OK and won't result in being shown the door.
Less Centralised Management
What do I mean? Well, when there's a problem the first person someone will turn to now is another person within their team. I'm only really made aware of issues when they are escalated or when there is a genuine impediment to progress.
The teams are also self organising - I don't need to allocate people to tasks. The team gets the priorities from the product owners and accepts a quantum of work to be done in the 2 week sprint cycle. Once this is done the team will go off and allocate amongst themselves who does what.
Estimates made by the team are typically met. In the last 40-odd sprints (multiple teams) there have been 2 failures. Just 2. Not that a 5% failure rate is desired but it's certainly a lot better than industry norms. Also one failure was early on, and the other was a result of a change in development practices (introduction of pair development) where the impact on estimates for time weren't all that well understood.
While plans will always change, there is more up front thinking being done over what should be worked on and in what order. The stakeholders and product owners feel more involved in the development process and they can talk more confidently with their customers over what will be happening in the product.
More planning also means less scope creep and less ad-hoc requests. One of the things I did was to ensure that anyone who wanted to pull a team off for other work (pre-sales, etc) would have to either plan it in advance or, if it was last minute, cancel the sprint.
This has been tested on a number of occasions but given that the requestor is usually negatively impacting other people in the business if the sprint is canceled they have changed their minds and approached the problem they have in a different manner. The previous habit of people turning to PD and sucking up resources on an ad-hoc basis and yet still expecting delivery and quality is gradually becoming a thing of the past.
Less Staff Turnover
Believe it or not, the turnover of staff has dropped dramatically. There was a period for about 6 months after I started where staff turnover was quite high. Some of that could be attributed to a change in manager, but most of it related to burn out, unclear objectives, no sense of work pride, etc.
After the introduction of scrum, the turnover in staff has dropped right off. There is still the occasional resignation, but people are working at a sustainable pace, have a sense of direction and have clear goals to work towards.
Staff retention not only reduces payroll costs and head-hunter fees, but helps improve productivity and morale. It's a feedback loop as well, lower staff turnover increases morale, higher morale reduces turnover, and so forth.
Even if Scrum didn't bring all the changes listed here then this alone would have made it worthwhile.
More Customer Focus
Agile development in general is focused on delivering business value to the customer, not on producing what you hope is what the customer wants.
Introducing scrum has not only helped us refocus on the customer but also given us a structure wherein we can have our key customers and development partners involved in assessing what we have produced, giving input into what they see as priorities, providing feedback on product ideas we may have, helping improve usability and so forth.
If we develop something as a prototype and it's shown that it's not really what someone needs or wants, we lose at most 2 weeks worth of work, which is a helluva lot better than 6 months of full on development. However because of the tighter customer involvement we have we are even less likely to screw up in the two week sprint cycle because we have improved communications and gained a better understanding of what the customer actually needs and the risk of doing the wrong thing is even less.
A Better Product
The product itself has improved. No question about it. The things we have added to the product are what customers are asking for and so our value proposition for the customer is improved. Would this have happened without Scrum? Maybe, there's no reason why not. As it turns out our product plans as at 9 months ago and what we actually produced since then are actually quite different.
The organisation itself has changed quite a bit since the introduction of scrum. We are now more outward looking and more adaptive to customer needs, there is more responsibility being taken across all parts of the organisation for what they produce, there is a greater focus on delivering value to the customer - not just in product development, but in other areas as well and there are overall improvements in morale and teamwork.
Does this mean that everything is perfect now? Of course not! We still have problems, still have people issues, customers still need support, there are still shortcomings in the product and all there is still plenty of room for improvement. Regardless though, things are a lot better now than they were before.
Was this all achieved because of me? I'd like to say of course it was and then rabbit on about how wonderful I am but I'd be lying. All of this was achieved because of a combination of factors. The biggest success factors were a willingness from the team to change and a structure with scrum that was focused on that change. The fact that an agile process is built around an understanding that it takes people to make something work and that we're not automatons is a great enabler for improvements. All I did was facilitate the change, lead a little bit by example to get things started and then get out of their way. If it wasn't for my great team then none of this would have happened and I'm indebted to them for the willingness and adaptability that they have shown over the last 12 months.