Coping with change on Scrum projects (Part III)

May 1, 2009 by Jack Milunsky

Introduction

This could be the last in this series unless of course I get new inspiration or I get specific requests to cover additional roles. This week I'll take a look at how the lives of QA testers and Developers are expected to change on Agile (scrum) projects. Frankly, I think that for these two disciplines, life gets much better i.e. developers and testers benefit most transitioning to Agile from Waterfall.

Developers

Developers love to do things right. Nine times out of ten, they'll argue against taking short cuts. They hate the fact that they are forced to deploy code that they know deep down is less than stellar. As with anything in life, making the shift to agile swings the pendulum over to the complete opposite side. So for the one out of ten code hackers out there - beware. The biggest change a developer can expect from a shift to agile is that engineering discipline or rigor is set to the max.

So what can you expect?

#1. You no longer have to estimate tasks on your own. This activity, arguably one of the hardest, will be done as a team playing planning poker. As a result, you'll get better at estimating, and you'll take a much broader outlook on estimates, so as to include all aspects of the development life-cycle including time to test, to document etc i.e. according to your definition of "DONE". Additionally, you don't shoulder the complete responsibility for a bad estimate.

#2. You will have to learn how to pair program. If you're doing XP, you'll be doing this more often than not. This is a huge mental shift that developers must make as for the first time, you are forced to open up your code to peer review. This means that you're being critiqued every step of the way. It's hard at first. But the benefit is huge - you're going to be a better programmer for it - guaranteed! This can also be a lot of fun by the way, especially with pair ping pong.

#3. No longer are you expected to throw code over the fence and expect testers to find the bugs for you. In fact you're going to be responsible for building quality in right from the start. So, you're going to have to learn how to write unit tests. You'll get to learn lot's about Test Driven Development and Test first driven development. This is where your skills as an engineer are challenged, to produce the best possible, highest quality code. The rewards are great, trust me on this one.

#4. You will participate in the complete end-to-end process from beginning to end. This gives you a new perspective on things as you're part of the initial user story workshops. Consequently you get to hear things first hand from the Customer/Product Owner as they're there to elaborate at the Sprint planning meeting. You're also part of the retrospective at the end so you get to close the loop, reflect on what went right, what went wrong and to make it all better sprint by sprint.

#5. You won't have to burn continuously. In fact if you're true to Scrum, you shouldn't have to burn at all. Velocity tracking sets your maximum sustainable team throughput, which governs how much work-in-progress there is at any given time. Too much in the pipeline and you'll deliver less than what you should, too little and you'll deliver less than what you should. Instead mature Scrum teams will set things up just right so that you can continuously produce code without long periods of drought producing nothing like in waterfall projects. As I have probably mentioned before, our Agilebuddy team deploys new builds to production every two weeks without fail. This is a huge competitive advantage. We're able to do this by setting the discipline dials to eleven and ensuring that the pipe is optimally primed for just enough work. We can learn a lot here from Lean thinking and the Toyota Product System.

#6. You wont have to worry about death marches, or code blues. Rather, at the end of each Sprint you will feel proud of what you have produced, and you'll never want to work any other way again. This requires that all Stakeholders are bought into this new process right from the start.

#7. At the end of every Sprint you get to demo what you have done - this is the cherry on the cake. This is a time for you to shine rather than hide, where on waterfall projects you'd never know where or when the next bug was going to surface.

#8. You'll work as a team and cross each milestone as a team. This is not about I's and Me's. Instead, you'll seek opportunities out to help team members when in need.

I started out thinking I'd cover both developers and testers but as you can see I am already way over my 4 - 500 word mark. So It's probably best that I leave QA testers for next week's post.

I am off to Railsconf next week. If any of you are there please pop-in to our booth (#7), I'd relish the opportunity to chat about Agile. Additionally, if you have any comments on any of the above or previous posts on this topic, please contribute, we'd love to hear from your experiences.

Permalink