Oct 24, 2006

Scrum - 9 months on

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.


More Ownership


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.


More Planning


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.


Organisational Change


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.


Summary


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.



If you wish to implement scrum (or another agile process) in your organisation remember that it's the people that make it work. Scrum is not a magic bullet that will solve all your problems, bring about world peace and get you on the Rich 100 list. It's just a framework to refocus you on what's important - delivery to the customer & improving your team.

4 comments:

  1. What did you do different from the first time around?
    Why do you think it worked this time?
    I would really like to know because I could be very soon in the same position...

    ReplyDelete
  2. What did I do different? To put it bluntly, I stopped worrying about what other people would think, and stopped trying to do it gradually.

    I educated my team on what would be happening and made sure they knew what the new ground rules would be.

    I then basically said to the rest of the business "this ain't working" and that things were going to change. Here's what the changes will be - any questions? I then spent a bit of time making sure those questions were answered and got started.

    I didn't apologise for upsetting some people (but I didn't aim to upset them either) or bend any rules either as the benefits far outweigh the incovenience some people will have during a transition period.

    I'm curious why you think you'll soon be in the same position. Anything you want to share?

    ReplyDelete
  3. Thank you for the great inspiration!
    I’m in the same position as Kalus i.e. I’m soon in the same position you were. My problem however is that my team is not so flexible. They do not handle change well and changing from our current waterfall model into scrum does mean a lot of change. Do you have any suggestions on how to handle "inflexible" team members? I read your post about the "all or nothing" approach but I’m not sure it would work in my case.

    ReplyDelete
  4. I had a number of "inflexible" staff in the past. If it's not obvious I put in more time to try and educate them, and then set a deadline. I told them that this is the way things were going to be and that I had certain expectations of them (ie take responsibility, ownership, authority, etc) and that they needed to make a decision on wether they wanted to be part of the team or not.

    I also said I would do whatever I could to support them while they got used to doing things in a new way, that I expected that they would make mistakes and that it was OK, but at the same time I expected them to try. Being passive aggressive or openly hostile to change was not an option and if they really didn't want to work in a positive way for a positive result I would give them a good reference for their resume.

    The "firm but fair" approach. If you don't have the hard conversations and try to overcome peoples hesitations and doubts then you'll never being about any sort of lasting change.

    ReplyDelete