Saturday, February 28, 2009

Bringing SCRUM to my organization

How do I successfully bring SCRUM into my organization?


Believe


I've discovered that the first, most important thing, is to really BELIEVE. Believe in SCRUM and that you can make it happen where you work. Last year, before my training, while I had some experience with SCRUM at my previous employer, I didn't have a firm grounding in it a.k.a. formal training. While I was learning SCRUM, I asked the instructors a lot of questions about how to successfully convince my management that SCRUM was going be useful for us (Thanks very much to the instructors at Berteig Consulting for being so helpful). On the last day of our training there was a somewhat confrontational, but extremely inspiring back-and-forth between a student in the class and the instructor regarding co-location and productivity. The student insisted co-location was impossible, and the instructor kept asking 'why' until it was learned that the company the student worked at was choosing to value 'other concerns' over productivity. What I saw in that dialogue, was the sorts of challenges I was going to have to deal with. Essentially, the people I work with, and my management telling me what I wanted to achieve was 'impossible'.


Our instructor said that being a Scrum Master required courage and a belief that nothing is impossible. I used to laugh at statements like that, but for some reason, I'm changed... I totally believe that I can make anything happen. Now that I have formal training in SCRUM and the SCRUM-Master designation. I am working on bringing SCRUM to my organization and blogging about my journey.


So Far, So Good


What have I achieved so far? Well, I have engaged my supervisor. He did some SCRUM presentations to our organization last year, and while he is not a scrum master, he has a good working knowledge of the process. We put together a 1/2 hour presentation where I did a comparison of waterfall and SCRUM, and described the SCRUM process. He continues with how SCRUM can benefit our company and how it fits, and the organzational impacts. We presented to our team (development team) and to our direct management. We are calling our presentation the 'SCRUM roadshow'.


The Road Show


The SCRUM presentation we have so far is very simple. We have some notes that we've jotted down, and NO SLIDES. We have handouts as take-aways, but the presentation is done completely on a white-board. Except for the fact that my back is turned to the audience while I'm writing (I'm working on sideways writing now), I think the lack of slides makes the presentation more engaging. So, for the moment, this is our road show. We are presenting it to everyone who could possibly be impacted, first within the IT organization, and soon, hopefully to the business.


The Pilot


We have the go-ahead to pilot SCRUM with some small, low visibility projects, to get our feet wet and get our team used to the process. I am seriously considering buying the Scrum Alliance scrum board game as a way of solidifying the SCRUM process with our team. In any event, I will be Scrum-Mastering 2 pilot projects. We have additional projects that will be managed in our traditional fashion, so it will be interesting to compare results.


Challenges


Of course, resistance to change is evident everytime I even mention SCRUM. I get the best response from people who have managed waterfall projects and have felt the pain of those projects. So I'm focussing on describing the pain of waterfall and hopefully hitting a nerve. This seems to make people much more responsive to a new approach.


Enter, Denial. I see denial when I talk about waterfall pain. This is much more difficult to deal with than resistance to change. Success stories work here, and I have a small one that I share (more on that later). I think talking about your own challenges with waterfall projects gives you credibility and shows people that 'owning up' to problems actually shows strength (instead of incompetence).


A Small Success


We have a project that, for various reasons, is about 12 months overdue. The software has a large list of bugs and some small feature requests. All of which are listed in our QA tool. I have taken on the task of rescuing this project.


Before I applied SCRUM to it, I had some of the following issues,


  • Seemingly flip-flopping requirements

  • Massive quality issues

  • BA/PM unaware of project status

  • Blame and unclear responsibilities

  • Lack of BA engagement




The first thing I did, was estimate the complexity of each of the bugs and changes in the bug tool using a number between 1 and 5 (I.e. a 2 is 2x the complexity of a 1). I then asked the BA to prioritize the items and mark the bugs that are critical to the release as 'high'. At first the BA just said everything had to be fixed. I told him that would mean we don't release for several months. I also showed him that some of the bugs were just minor inconveniences, and that the cost of fixing them was quite high (this happens all the time in software development).


Prioritizing the bugs, forced the BA to actually read and understand each issue. I had effectively put the BA in the Product Owner role. Immediately the BA's engagement increased, and he had an excellent idea of the project status and what was standing between where we were, and our release to production. I had also made the Product Owner (our BA) responsible for the release date. He was deciding how many sprints we would be doing based on how he rated the criticality of items. This also helped stop the flip flopping of requirements. Now, it was not longer the developer's fault for the late release, the team was accountable, and the team included the BA.


On the quality issues, I engaged another developer to do QA. Bugs or Changes weren't closed unless the QA developer was satisfied. I encouraged her to be very strict and to note everything using the tracking tool. On many occasions, she would re-open items I thought were ready to go.


I set each sprint to a 1 week duration, including a planning meeting on monday, daily scrums and a demo and retrospective on friday. I've found the Demo to be absolutely critical to ensuring a clean sprint completion, it serves as an excellent test for 'shippable software'.


4 sprints later, I believe the product is ready to release. And I believe I have won over the BA to the SCRUM process.