Scrum Secret #2 - low tech rocks!
August 1, 2008
There are a number of elements to SCRUM that really work well for us. One of the most obvious features is our ‘SCRUM Wall’, where we ‘publish’ all the work items that form part of the current sprint to ‘The World’.
The Wall is primarily for the team, but it’s surprising how many ‘outsiders’ take a real interest. Initially there’s the comments about ‘nice wall - but a bit low-tech isn’t it’, to which we respond - ‘that’s the point’. The great thing about the Wall is that each card is a tangible thing, representing a tangible deliverable. Rather than being locked away in a spreadsheet or web app (though we do use TACKLE to track our tasks electronically to - more on that later) the cards can be accessed easily by everyone.
The cards typically begin life with a one-liner describing a deliverable, and estimate of how long it will take and the initials of one of the developers. However it doesn’t take long before the card has evolved with the scribblings of several members of the team as more information is discovered.
Quite often one card will become two or three as the iterative process of understanding more about the task unfolds. The pure simplicity of the wall means that things don’t get forgotten or fall off the radar - every thought and new discovery is captured quickly and easily.
The wall only represents 2 weeks of work at a time - a Sprint. This means that every 2 weeks the wall gets cleared. The completed tasks are archived. The items that are not complete or blocked are taken down and form the basis of the ‘Backlog’ for the next sprint, in addition to new scope items that we take from our ‘product Backlog’.
We are currently running a one-hour planning session with the whole team every 2 weeks, which gives us ample time to review where we are with the existing work items and allows us to estimate how much new scope we can bit off to keep us occupied for the next 2 weeks.
This process is incredibly tranparent and efficient. The constant replanning and course correction means that: we rarely build anything that is not part of the final solution; everyone on the team is cross skilled and across the big picture; we can easily slot in refactoring tasks to increase the robustness of components we have already built but need some ‘love’; reporting upwards to management on progress is easy due to the high visibility of the methodology (lets face it - who could miss our scrum wall!).
The best thing about this methodology is that the team is completely behind it. The core team members don’t want to work without it and new recruits accept and join in with the processes eagerly.
LONG LIVE SCRUM!
Scrum Secret #1 - take the furniture out of the office
June 16, 2008
Having your daily scrum stand-up in a dev team “scrum room” has its advantages.
You can be more honest and talk more openly, have robust discussions and generally not have to worry about being overheard, as well as use of a whiteboard for planning sessions and nutting things out.
In our experience, dev teams tend to lose their office first, as competing business teams and managers are almost always deamed to be more “important” than the dev team.
So we have some simple psychology for keeping your scrum room - take out the furntiure. That’s right - have the office empty, no desks, no computers, nada. Even better, put in a couple of empty computer boxes in there for effect.
We are currently working in a very busy office, yet we have kept our scrum room for several months so far, and no one has challenged our use of the room, yet in the adjoining office we have seen a rotatiing door of occupants come and go.
Stay tuned for more scrum secrets.
Quality Assurance - QA all the way!
June 15, 2008
I am amazed at how often organisations will not place a strong enough focus on QA. For the small amount of time spent on this task there are a number of major benefits. These include:
- Bugs can be found earlier, where it is much cheaper and quicker to fix them
- It is easier to enforce coding standards to give the code base a common style and pattern usage.
- Poor programming techniques or inadequacies such as not sufficient unit tests can be fixed earlier.
Whilst it is probably a good idea to not go too overboard with extremely strict QA enforcement, I believe that every line of code developed should be reviewed, or walked through with someone other than the developer of that code. To help with this goal, our SRUM methodology again comes in very handy. This is due to the short 2 week sprints in which we develop. It means QA’s are occuring frequently thoroughout the development cycle, and prevents it all having to occur at then end, with the various issues that that entails.
Scrum Rocks!
June 4, 2008
We have been using SCRUM at Buildmasters for over 2 years now and it continues to form an incredibly important part of our process. The key benefit that I see as ScrumMaster is that the dev team are able to concentrate on doing what they do best without being distracted by the inevitable ‘Noise’ that surrounds a typical IT Project.
Here’s my list of everything I love about SCRUM:
- Communication! The daily stand-ups and quick but effective. Everyone know what everyone else it doing and it’s amazing how often we turn up issues that no-one knew existed.
- Heartbeat! The regular two week cycle of planning, developing and reviewing allows for a very structured appraoch to everything we do. Rather than an amorphous pot of tasks being juggled endlessly we have well defined short term goals that we can concentrate on for 2 weeks.
- Regular Planning! There is always constant change in the world we work in. The regular planning (at the beginning of every 2 week Sprint) allows us to adjust course and take into consideration new scope and anything else we have learnt in the previous Sprint.
- High Visibility. All our work items are written on small cards and posted on our Project Wall. Low tech but effective.
