I’ve been an avid reader and follower of Agile Methodologies since 2003 when I read “Teach Yourself Extreme Programming in 24 Hours“. This short and simple book laid the groundwork for my entrance into Extreme Programming and eventually a Scrum team approach to software.
In recent years, many organizations have embraced the Scrum methodology. The big promises management hears are:
- Developers will produce more code in a shorter amount of time
- You can change your in-house applications more easily
- Defect rates will go to zero
All very good things. But these results are impossible to achieve if the development team is not staffed with professionals.
“Uncle” Bob Martin visited the Philly.Net usergroup in December 2012 and shared with us his thoughts on what makes up a professional development team:
Demanding Professionalism: Uncle Bob @ Philly .NET User Group (PLUS WordWrap Kata) from 8th Light on Vimeo.
As my role within our scrum project team has evolved into a lead developer, I find myself in more and more design and collaboration tasks with my developer teammates. I was initially going through oral and white board design sessions with my team to convey how the technical design for the sprint was evolving.
However, our team has grown to 5 developers (including myself), 2 QA analysts, a product owner and our scrum master. I’ve found that my verbal communication approach is simply taking too much time away from coding. In discussion with my director and our scrum trainer, we settled on a practice called the “15:5 document”. I have not found discussion of this technique on the web, and will share what I have found over the past week of using this approach.
The 15:5 document receives its name because it takes 15 minutes to write, and only 5 minutes to understand. This document is a complementary document to the User Story, and I store them as an attachment to the User Story in Team Foundation System (TFS). This isn’t a full-blown design document, but more of a place-setting. It is the springboard of tribal knowledge a developer needs in order to get about 40-50% into the design of a user story’s tasks. The remainder of the design is confirmed through periodic code-reviews when builds are pushed.
Typically, I load the document with:
- An entity-relationship diagram from Visio or a photo of one scrawled on a whiteboard
- Some bullet points describing the diagram
- A sample database table design if necessary
- A scribbled wire-frame of what the UI may look like
I was thinking of putting together an MSWord template for this type of document, but these 3 sections seem too easy to simply build out as I write out my designs.
Give it a shot… I’d appreciate any feedback or options of other scrum design practices. You should see more scrum flavored posts in the coming weeks as I adjust to this role.