Parlance - SCRUM and The Nokia Test
“Was hearing Jeff Sutherland talk about the Nokia test , a test developed by Nokia to test whether you’re doing Iterative development or not , and if yes if you’re really doing SCRUM.
Are you Iterative ?
- Iterations must be timeboxed to less than 4 weeks
- Software features must be tested and working at the end of each iteration
- The Iteration must start before specification is complete
The second point throws up a debate on what testing means, most of the companies that do partial SCRUM try and do a separate test sprint and for them the above “tested” - means unit tested, or at the most integration tested but not “functional “ tested , I did see a lot of implementations diligently trying to go the SCRUM way, and not being able to make it, because this is where they falter.
Are you implementing SCRUM ?
- You know who the product owner is
- There is a product backlog prioritized by business value
- The product backlog has estimates created by the team
- The team generates burndown charts and knows their velocity
- There are no project managers (or anyone else) disrupting the work of the team
…” [Post Leach Level: 75%]
Yeah, I feel that my team IS using Scrum. We pass! :)
Being new to Scrum, I may be talking out of my… well… yeah… but my feeling on second bullet in the “Iterative” section is that tested, means tested. Not just unit tested, but completely tested. I’m thinking that if the result of a Sprint is supposed to be a potentially shippable, implementable product, then doesn’t that mean it has to be fully tested? No throwing stuff over the wall for a QA Scrum or anything weird like that? IMHO, if you’re going to do that, you might as well be honest about it and go back to waterfall.
As much as it pains me to say this, I’m already hearing rumbling about “how we do Scrum.” I’m seeing movement and requests (not by me team, but by those around and above me) that concern me and our commitment to giving Scrum an honest try.
I’m going to try my best to keep to Scrum and not make an major changes until my team really “gets” Scrum (we don’t stand at our daily’s, don’t charge late people a dollar and our first Sprint may be 32 days, but I think that’s all the changes we’ve made). Maybe toward the end of this year we’ll be in a position to adapt it as needed. I feel it’s hard to tweak something effectively without breaking it if you don’t really know the thing you’re tweaking.
But you can only push back so hard without turning it into a religious debate (and making a CLM, a Career Limiting Move). Hopefully my Team can prove the concept soon enough, walk the walk by leading by example, get the other teams interested enough and get enough of our users excited about Scrum that doing the right thing will result in doing the right thing…
We’ll see. I just have to remember, “Art of the possible.”
If you really *want* to do Scrum, you need to push it. You don't know if something is possible until you try it.
ReplyDeleteJust start simple. Scrum is about *continuous* improvement, not about big bang improvement.
Show them you really do Scrum. Start by the iteration. Make it 4 weeks, that's just 4 days less than your previous sprint. Stand up during the stand up meeting. Make sure the daily scrum is only 15 minutes.
Provide clear requirements (product backlog), possibly in the form of user stories. Make your goal of the sprint clear. Make sure you reach that goal. If you don't reach that goal: what didn't go well? Try to improve that over the next sprint.
Remember: start simple. Simple. Change a small number of things. Try and see if things work for your team. Every team is different. Every company is different.