# Saturday, November 08, 2008

After the Scrum class last I got a chance to attend a talk hosted by SolutionsIQ on Adopting Scrum in the Enterprise.  Chris Kinsman gave a very interesting talk on his experience adopting Scrum in his organization, how executive sponsorship made a key difference, and how the adoption has proceeded.  I was particularly taken with the idea of a Sustaining Engineering scrum team.  In Chris’s organization, they run 4 scrum teams, and every sprint one of them  does the sustaining engineering, fixing customer issues and releasing hotfixes, etc.  Every sprint they rotate the duty, so the sustaining work is spread around and nobody has to bear the burden all the time.  It also means that everyone gets a better understanding of how the code works and what customer’s are concerned with.  Passing the buck on sustaining was a big issue at Corillian, and I know that I at least really didn’t like being on the hook carrying the support phone for a week at a time. 

Since Agile often gets adopted from the “grassroots” with the development team advocating for it, it was interesting to hear about a successful top-down adoption.  It poses some interesting challenges, but if done correctly the executive sponsorship could really make a big difference to making Scrum successful. 

The biggest advantage I can see to a top-down adoption is that you can work on changing the whole organization at once with a better chance of success.  Several groups I’ve worked with have adopted Scrum/Agile at the development team level, but the rest of the organization has lagged behind.  That tends to mean that the rest of the process is basically waterfall, with a little Agile in the middle.  You start with a requirements gather phase, do a little design, then some “agile” for the construction phase, followed by a formal QA process.  That sort of adoption is better than nothing, but it poses it’s own set of challenges. 

Saturday, November 08, 2008 11:41:00 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

Last week I got the opportunity to take a Certified ScrumMaster class from SolutionsIQ in Seattle.  It was a very good class, and I came away with a deeper understanding of how Scrum is supposed to work.  I’ve actually been working on (nominally) Scrum projects for a while, but the class gave me a chance to catch up on the formal vocabulary and practice the range of skills involved in running a Scrum project. 

Scrum takes a fair amount of discipline to do successfully, I think, but if you can pull it off it provides (in my experience so far) the best way to run a small development team working on a business application.  One of the things that I think hinders Agile adoption is lack of training.  It’s easy to declare a project agile, when what you really mean is “we don’t have a plan”, or “we don’t write anything down” but that’s not likely to achieve the same level of success. :-)  There’s a fair amount of work involved in running a Scrum project, and from that perspective I don’t think it’s any less work than running a traditional waterfall project, you just end up with (hopefully) better results in terms of building working software that meets your product owner’s requirements. 

To that end, I think it’s very valuable to get the team trained on the formal methodology around Scrum (or you agile methodology of choice).  I don’t think that means everyone on the team needs to be a ScrumMaster, but there are a wide range of courses available for introduction a team to Scrum (or whatever) that would really make a difference to a teams successful adoption of the methodology. 

Saturday, November 08, 2008 11:16:11 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  |