Scrum Project Management from K.H. Pries and J.M. Quigley discusses this branch of Agile Project management as seen from the front line trenches. This is not theory. This is battle hardened experience from day in and day out application of SCRUM and this is what they have to say about it….
First off, I better give a quick definition of SCRUM. “Scrum is an iterative and incremental agile software development methodology for managing product development”, thanks you Wikipedia. It can perhaps be best illustrated by way of a simple diagram, see below. The development cycles, known as sprints are short term, intensive collaborative team efforts to deliver a version of the product. The content of the sprint is defined by the team in a Sprint list or Sprint Backlog, which is a subset of the Product Backlog. After the conclusion of a sprint, the product is evaluated, feedback received and another iteration of the development loop kicked off.
The History of SCRUM can be traced back to work from Takeuchi and Nonaka in the 1980’s and later described as a “Rugby Approach”. In the 1990’s Ken Schwaber used such an approach and eventually penned the name SCRUM to describe it. For a detailed SCRUM description head over to the SCRUM Alliance page.
The two Authors of “SCRUM Project Management”, Kim and Jon like SCRUM. And, this is hammered home time and time again in this book. I get the feeling though that they practice what they preach and quite frequently past experiences have been cited in the book. Let’s review the topics covered.
This book covers many aspects of SCRUM and not just SCRUM, how it can also integrate with other development methodologies. The key topics were,
- Why SCRUM?
- Introduction to SCRUM
- Integration with traditional project management approaches such as waterfall
- Organisational items, SCRUM of SCRUMs, integration with Matrix organisations etc.
- Application of SCRUM to Defence, Six sigma, Education, Service industries and making coffee
OK, I made up the last bit there but clearly Kim and Jon see many applications of the technique.
Kim and Jon have covered each of the fundamental building blocks also and described their operation along with some tips to get the best of the components in real world scenarios. These include,
- Retrospectives – discussion on good/bad points of the sprint
- Sprint velocity – speed of completing tasks
- Initial planning sprints
- Use of kanban in sprints
- Daily sprint meetings
- Sprint kickoff/review
- SCRUM tools
- Burndown charts
- Story points – description of user features
- Work breakdown
- Creation of product backlog
A couple of key items struck me from this material. First was their idea of “atomization”. It is very similar to the approach that I use of micro-tasks. Essentially, very small, digestible actionable tasks. The advantages they also highlighted were that they provide a digital done/not done status and therefore an accurate indication of work complete. Additionally the work seldom extends beyond the sprint duration due to the small and accurate detailing of these tasks.
The burndown chart is also a nice way to measure progress. The x-axis is time. The y-axis is accumulated hours of work and actual hours.
In SCRUM there is also a great emphasis on the project team and this has also been described in the book. Several key team aspects are highlighted,
- SCRUM teams develop to be self directing – a bit of a boon for the SCRUM Master/PM
- The role of the SCRUM master, the equivalent of a Project Manager
- The journey towards high performance teams. 4 key features are highlighted
- Team task
- Clear boundaries
- Authority to manage their own work
- Membership stability over time
SCRUM is a branch of Agile Software Development and as such traces it’s roots back to the original Agile manifesto of 2001. These simple four points illustrate the background and raison d’etre of the technique,
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Several cases are made in support of SCRUM. When compared to traditional waterfall planning several advantages are outlined,
- Short term focus mitigates long term planning inaccuracies
- The ability to change project scope quickly
- The engagement of team members as it becomes a self-directing team, to the extent that minimal management is necessary
Additionally the authors see it as a means to not only move from inefficient multi-tasking methods to mono-tasking but also to increase the tempo of the project. No doubt the daily sprint meetings can assist in that when every team member accounts for themselves and what they have done. Examples of the reduction in backlogs tasks when SCRUM was applied were highlighted – 50% to 75% reduction cited.
Integration with other project management approaches
For people coming from other methodologies, fear not. “SCRUM Project Management”, has your back. Kim and Jon have also looked at how SCUM can integrate with other approaches such as waterfall phases and Kanban.
For Waterfall, SCRUM sprints can also be integrated. Since Waterfall phases tend to be much longer than sprints, months/years vs. Weeks, the integration would mean having multiple sprints per project phase. This may have the effect of increasing tempo in those project phases. The authors also see no disadvantage in such an approach and indeed cite several advantages
- Increased feedback on variance from schedule, budget or quality
- Daily audit via the scrum meetings
- Accelerate response to any issues that emerge
For Kanban, there are possibilities in both the sprint backlog and product backlog to integrate Kanban style boards.
Whatever the flavour of project management there is inevitably a tinge of burocracy. Some elements of this have also been addressed,
Large Scale Projects: The approach advocated here is SCRUM of SCRUMs, whereby each smaller SCRUM team provides a delegate to a core SCRUM team. This essentially provides a form of hierarchy whereby the subordinate SCRUM teams can deliver parts of a larger project.
Documentation: In the manifesto for Agile project management the role of documentation is secondary to working software. However, not to say it is neglected but there is a just in time mentality in delivering this.
Communication: Small, tightly knit teams are common theme in SCRM and to scale up, they do not add team members they form SCUM of SCRUM configurations. This kind of scaling also comes through in the way members communicate. Instead of having a central node, a Project Manager, acting as a communication hub SCRUM teams have direct contact to all members in their team. Interacting beyond that is usually done via the representative to the SCRUM of SCRUMs core team.
Product Backlog management: For large projects, this can become unwieldy.
Application of SCRUM
In “SCRUM Project Management”, many different possible applications of SCRUM were highlighted. These included,
- 6 sigma projects
- Defence projects
- Service Industry
- In hospitals
So, if you find yourself in any of those areas you can sleep well knowing that SCRUM has got your back.
So, let’s sum up. “SCRUM Project Management”, is a helpful, hands on guide to the approach. It takes SCRM through the basics, it’s essential components, to perils and pitfalls, integration with other systems to final applications in a number of sectors. I would not consider it as a reference for the approach but rather a view of it’s implementation from the front line.