I’m often amazed at the number of dogmatic “prophets” out there when it comes to the latest fad’s of agile development. I myself am about getting productive and like to take the best of ALL worlds; change is not only inevitable but necessary, even changing of a process BUT, only if the change leads to improvement! I believe a process of continual introspection and change by a team, combined with a good way of measuring the effect of that change, is essential for good team performance.
That in mind we made the following changes to the way we practice scrum:
- We added a default story to cover recovering technical debt (or refactoring if you will) in that story. Essentially we assign a “story point cap” to this story (say 5 points) that’s based on our current velocity and duration of sprint. We then assign “technical debt recovery” tasks to this story until the team feels there are enough tasks to fill the story points. I know, sounds like the wagon pushing the horse but it’s something we’re trying that other teams have used effectively.
- We’ve started estimating (wait for it…) HOURS on tasks. Stories are still broken into story points but the tasks are estimated in “hour blocks” (2, 4, 8, 16) as they are put up. The purpose of this is to act as a type of “sanity check” for story point estimation. An added benefit I found was that the team members seemed to think a lot more about a task when they had to assign time to it.
- We’ve started using a round table instead of the tradition square meeting tables. I found this very effective in encouraging participation and collaboration.
- Story point estimation was done using a technique I learned on training that speeds up the estimation incredibly (works well with lots of stories). This is how it works (well, how we did it anyway):
- All the stories are explained to the team and placed in a pile on the table.
- A wall/board is divided into sections, each representing a story amount (we used 1, 3, 5, 8, 13, 20, 40, 100).
- Each team member takes a pile of cards and sticks them in the column(s) they believe it belongs, no-one talks or interacts other than with the product owner to understand the story further.
- If a team member disagrees with where a card is, he/she simply moves it to where he believes it SHOULD be.
- This carries on until all the tasks are done. Remember, the key is NO COMMUNICATION between team members during this process, this has the effect of forcing people to think about why someone made a decision to place something in a particular column, or why they’re moving it.
- We’ve started experimenting with TDD and Paired Programming, which seems to be going well.
One additional thing I’m toying with is moving to a more Kanban based board, the team has problems with taking on too much work and I think creating a way of limiting the pulling of work will work.
Finally on how to measure if these changes are effective, well, to be honest I’m not entirely sure. I think the best way is simply to see if the team becomes better at actually doing what they predict they can do while maintaining a sustainable pace and having fun; other than that I guess we wait and see…
I’d be interested to know what kind of changes you brought about in your team and the effect of them (both good and bad), let me know…
Rick please talk more about how you have started experimenting with paired programming, have you enforced it ? If so how ? per task ? or have you just paired individuals together ?
We have paired development happening, funny thing is that it just sort of happened. To me this shows some good team work, the team self organised the development work, and when found the need teamed up together to tackle a task!
Enforced teamwork is kind of like pushing a string, fun, but not useful. The team decided paired programming was something we wanted to try, two of them ran with it for a sprint and gave critical feedback at the end (both good and bad). Oh, and to make things more interesting we added TDD in as well 🙂
We found some interesting benefits coming out of it (besides the ones we expected), like the fact that people find it difficult to “interrupt” two people working, so fewer interrupts and more focus; guys actually had fun collaborating on solving a problem, even doing boring stuff; the combined momentum of the pair was (I thought) greater than the sum of the individuals. Add to that the obvious things like automatic review of code, improved quality and constant refactoring for improvement and I think it’s a winning recipe.
In the end though I think it has to be something the team decides to do, not something dictated to. It’s a mind-shift of note to get used to and unless your heart is in it, there’s no real hope it will succeed.