Sergey Shishkin

on agile software development

Archive for the ‘Agile’ Category

Story Of Change

Friday was a huge day for me! My team officially announced that we a going to implement Scrum. This was by no means an easy change. It took us 9 month and I just want to save this story in my blog for the records.

Why Change?

In April 2009 I was architect in a company using “waterfall” process with 3 month release cycles in a team of 40 people separated in 3 full blown departments of “product management”, “development” and “quality assurance” with its own organizational structures and typical “us against them” mindset. In addition to that there are also technical writers, who have to write all the user manuals on weekends after the code is implemented, and support engineers, who keep distracting developers with all those “urgent customer issues”.

PM was aimed to complete the software specifications before the “spec-freeze” milestone and throw it at DEV over the fence. Specs were long boring documents with faked GUI screenshots and lots of ambiguity. While PMs were writing specs, DEV made housekeeping, fixing bugs or writing code that DEV thought will be useful in future. With a spec at hands DEV coded like crazy to hit the deadline. Then QA started thoroughly comparing the spec with the software and filing found bugs or what QA thought was a bug. Nobody had time to make his or her job right.

After each release we heard the same annoying phrase from our management: “It was the toughest release ever, but we did it!” It supposed to be motivating 😉

After an unfortunate try to present Scrum with all its “pigs” and “chickens” to QA and PM, the word “Scrum” by itself became a taboo…

At that point in spring 2009 I was about to leave, especially seeing some of my colleagues leaving too. But after some management rearrangements in DEV department, I decided to give it a try to facilitate the change to Agile before I leave.

What Changed?

Today we have:

  • Sprints, which are 2 weeks long and relative consistent in terms of work committed and work delivered.
  • Teams consisting of DEV and QA sitting together in one room (pro team), communicating with each other and helping each other.
  • Teams estimate requirements and pull them from the Product Backlog into their Sprint Backlogs during Sprint Planning meetings.
  • Teams decide how requirements are going to be implemented.
  • Specification is emerging during the Sprint as a joint effort of PM, DEV and QA in form of FitNesse tests.
  • Technical writers use Sprint deliverables immediately and have an opportunity to schedule their work accordingly.
  • All “urgent customer issues” go first through the Product Owner, who is responsible for prioritizing them and putting into the Product Backlog. If it is really urgent, it goes directly to the Fast Lane on the Task Board to be pulled by a team member.
  • A few Certified ScrumMasters and Product Owners.

How?

These are all things that we practice for some time already. Although not everything from the list works frictionless. Nonetheless the “change” on Friday was more like a Scrum training for all teams and an announcement “Oh, by the way, we are actually doing Scrum already” 😉

It was an incredibly hard change, I must say. And it did not come by my will only. It could not happen without support from several people in our company who were willing to listen. Together we did it. But there are still a lot of things to do on the way to Agile. The only thing I know for sure is that there is no way back to the stone age of waterfall process anymore.

I write all this because since then Agile has become my topic of interest and I hope to be writing more on it in future. I stumbled upon many obstacles while bringing agile ideas to different people and it was always fascinating and invaluable experience. Stay tuned 😉

Technorati Tags: ,

Written by Sergey Shishkin

16.12.2009 at 18:15

Posted in Agile