Getting our SCRUM on #4

The Year In Review

We’re finishing our first year with SCRUM and I thought I’d recap the highs and lows that I’ve observed.  For me, this is the most enjoyable thing I’ve done in my 20+ year career in IT.

Highs

•   The teams have delivered more than anyone thought was possible.  Compared to the old methods where there were endless hours in meetings arguing over this word or that word, the teams got down to business and cranked code.
•   Quality is very good for the teams that implemented automation.  Simple things like automating builds, writing automated unit testing and implementing automated QA scripts has proven a huge win.  Utilizing automation emboldens the teams to make changes that they normally would be afraid to implement.
•   Our business partners are engaged and enjoy being part of the process.  They love being able to adjust features every few weeks and not being told “NO” constantly.  At times, they haven’t liked having to make tough decisions about one feature or another, but in the end, they’d never want to go back to waterfail.
•   If you follow the process, there really is transparency concerning progress and issues.  For the teams that have done burn-up charts (trend towards release scope), they have been spot on.  Velocity provides a good measure of just how much a team can accomplish sprint by sprint and the burn downs let you know whether you’re on track or if you’ve bit off more than you can chew.
•   Presenting the working product at the end of every sprint has given team members visibility to executives that they’d never experienced before.  The executives have really enjoyed getting to meet the unsung heroes who build their systems.  There’s a real sense of pride on the teams when “C” level execs take time out of their schedules to talk to them.

Lows

•   Teams can get lost in the sprint-by-sprint nature of delivery.  We’ve witnessed teams struggling when they have to integrate with other teams, because they got too focused on their timeline and forgot about the other teams.  I’m implementing a weekly “scrum-of-scrums” with my SCRUM teams, architecture, load & performance testing & infrastructure to ensure we’re engaging them appropriately.
•   Some people just can’t handle the teamwork and pace of scrum teams.  Everyone wants to believe they’re a “top dog”, but unfortunately, not everyone can handle it.  You have to spend time developing a personality profile so you know what types of individuals work on your teams.
•   Agile doesn’t prevent “death march” projects.  Even with full transparency, there are forces that drive projects into delivering more features than they should.  Quality suffers, people burn out and moral drops.  However, even on these projects, agile works better, because there’s always an end in sight in a few weeks.

So that’s my take after one year of really doing agile.  In the next 12 months, our plans are to gain more consistency across teams (artifacts & ceremonies) and just get better at it.  Organizationally, we’re still newbies, but there’s a real commitment from the top, which makes all the difference.

About these ads