To me – scrum is a way of life- and if you are coming from a waterfall- its a very different way of life…
To effectively adopt scrum- we all have to change our ways… this is in fact ,I think the hardest part – to change our work habits and to change our beliefs.
These are my reflections on what a developer needs to do to be effective in scrum. Much of it is based on what I understand about scrum not entirely about what I have experienced in scrum.
Iterative vs Incremental development
Consider that you have a manufacturing plant which makes shirts.
You get a work order of 50000 shirts.
What would you rather do ?
A. Make 50,000 collars first and then 10,000 arms next and then…
B. Or would you rather make 1000 shirts and then another 1000 shirts and so on…
I guess you know – I want you to select B.
Actually – a part of me wants to choose A- because that is probably more efficient process.
But would you rather have efficiency or mitigate a huge risk ?
If it was only efficiency I was bothered about- I would probably choose A.
But if it was my dime on line- I guess I would choose B.
To translate this into a software development process…
You have to write a CRUD screens for some object
A. Would you rather do the Data Access layer first , and the service layer and then UI layer ?
B. Or would you do the entire layer first and then keep on adding functionality to the product – across all layers
I have always coded as in A. To move on to B- would be a big shift for me personally.
But its difficult to deny the benefits of this approach.
Quick delivery, quick feedback, less wait time for users, validation team gets to test sooner and so forth…
So while A maybe be better for me as developer – B is probably better for the team in general…
Note: In the earlier example- I didn’t suggest a shirt at a time. You need to find your own balance between the two extremes.
So why is this important in Scrum ? In every sprint, you want to produce a potentially shippable product- 50,000 collars aren’t shippable though 1000 shirts are…
Software development is more than coding
Discuss with a developer a development task- She\he will probably not think beyond the coding part.
For us (developers) ,software development is almost synonym with coding. Everything else- testing, configuration,deployment , data migration – all seem so auxiliary.
But in truth- software development is more than coding.
The other tasks- maybe not as mean as coding (but actually in some case, and I would venture to say often- they are tougher and more complex than coding itself !!!)
We (software developers) need to think beyond coding and consider all that happens before and after the software is made.
So why is this important in Scrum ? Because in scrum- you will see the roles getting blurred.
The key is- it’s team’s responsibility to deliver product ,rather than developers responsibility to code and QA to test and RA to get requirements
If you are a developer- do not hesitate testing what another developer did or maybe contribute to the requirement specs. Quite an idea- eh?
Another things is- in one sprint, you will see the whole life cycle of the software run from start to finish- What was traditionally kept for the last- is now up-front all the time.
Repeatable automated testing
Ah! This has been beaten to death on the blog world- so I am not sure what else can I add to this- except that you need to have some sort of testing strategy which is repeatable and automated.
THIS is your insurance policy against future breakage.
If you live in Florida- you buy flood insurance
If you are in software development business- you write repeatable automated test cases.
So why is this important in Scrum ? In scrum, you will be doing stories , and its more than likely that you will be coming back to the same module again and again in every sprint.
E.g. you develop a search functionality in the first sprint and then you add more search features in the next sprint. To make sure that you don’t break what was coded in the earlier sprints- you need automated repeatable test cases
The burden of testing increases dramatically in scrum- which is almost impossible to keep up via manual testing.
Sprints are not mini-waterfalls
So we discovered scrum- and decided to do iterations.
But iterations alone- doesn’t scrum make.
If you have an iteration of analysis followed by an iteration of design and another of development- voila !!! You have created yourself a scrum-ish waterfall !!!
Not sure if you are better off or worse off then before…
Develop small. Develop complete. Develop well.
So why is this important in Scrum ? This actually ties back to my earlier point of doing iterative over incremental development. You have to do all in one iteration to have a shippable product. Analysis or design alone do not constitute a shippable product.
Note- I am very hesitant on this- I still prescribe to the old philosophy of upfront design. I don’t mean design all the way- but still spend some time designing the software upfront and discuss with peers before you plunge in head long
Are you done ? or are you done-done-done ?
The first time , I heard about this was from my manager about 8-9 years ago.
When we would tell him that we are done. He would ask us back – Are you done ? or are you done-done-done ?
If you replied back saying that you are done- but …. He would stop you and refuse to listen more till you took back that you are done.
To be done but not done-done-done – carries a huge weight of keeping track of what all minor tasks remain. And if you have whole bunch of tasks that need to be done before you release your product- how realistic is your statement that you are done.
So – unless you are not done-done-done- you are not done.
Developers are smart people. The moment they are done with the challenging part of the problem- they want to move on to the next challenge. But this doesn’t work well with scrum.
So why is this important in Scrum ? In scrum- when you are done with a story- you don’t come back to the same story in the next iteration
You need to move on.
And the only way to do is to ask- Are you done ? or are you done-done-done ?