It’s unfortunate that the the Scrum product iteration increment is called a Sprint, implying that each increment is delivered by the team in a mad rush, full throttle. The image I have in my head is a 100 yard dash, everyone running as fast as they can to reach the finish line. Developing software is more like running a marathon than it is a back-to-back series of 100 yard dashes. In order to successfully complete a marathon you have to find a one mile pace you are comfortable running at, and keep running at that speed for 26 miles. Sprinting hard for the first several miles often means you are walking (or even crawling) the last mile, if you even make it that far.
One of the challenges many new Scrum teams face is developing a sustainable pace, sometimes called cadence, over multiple sprints over the course of a project.
New to Scrum, teams often struggle to find a sustainable cadence for delivering potentially shippable product increments. What I’ve observed happens is this: Early in a new Scrum project the teams is (I hope) excited to adopt a new way of working. They understand the Scrum principles and the time-boxed Sprint iteration, and more importantly, they feel a strong commitment to succeed on their newly committed Sprint deliverables within the first few Sprints. After all, at the end of the Sprint they will be proudly demonstrating their work to their stakeholders, which usually includes there boss and department head. However, since everyone is new to this different way of working, it is inevitable that certain work, usually that requiring specialized skills such as QA and documentation writing skills, ends up being delivered late in the game. Undeterred, the team works extra hours, heroically delivering the Sprint goals. This extra effort delivers a much needed early success, builds organization confidence, and can kick-start viral adoption. However, this type heroic effort doesn’t scale - after 2 or 3 Sprints the team starts feeling burned out and may fail to deliver Sprint-committed work.
In an ideal situation, the Team inspects and adapts, and, over the course of several sprints, build a sustainable cadence. However, many teams will continue to struggle, and can fall back to the “old way of doing things”.
While every team, project and environment is different, here are some points to consider to help get to a sustainable cadence:
 |
| Me, still running at mile 26, in the 1998 Boston Marathon |
New to Scrum, teams often struggle to find a sustainable cadence for delivering potentially shippable product increments. What I’ve observed happens is this: Early in a new Scrum project the teams is (I hope) excited to adopt a new way of working. They understand the Scrum principles and the time-boxed Sprint iteration, and more importantly, they feel a strong commitment to succeed on their newly committed Sprint deliverables within the first few Sprints. After all, at the end of the Sprint they will be proudly demonstrating their work to their stakeholders, which usually includes there boss and department head. However, since everyone is new to this different way of working, it is inevitable that certain work, usually that requiring specialized skills such as QA and documentation writing skills, ends up being delivered late in the game. Undeterred, the team works extra hours, heroically delivering the Sprint goals. This extra effort delivers a much needed early success, builds organization confidence, and can kick-start viral adoption. However, this type heroic effort doesn’t scale - after 2 or 3 Sprints the team starts feeling burned out and may fail to deliver Sprint-committed work.
In an ideal situation, the Team inspects and adapts, and, over the course of several sprints, build a sustainable cadence. However, many teams will continue to struggle, and can fall back to the “old way of doing things”.
While every team, project and environment is different, here are some points to consider to help get to a sustainable cadence:
- Work, as a full team, on only one story at a time. Make sure that story is DONE before starting the next story. In other words, implement stories sequentially.
- Avoid picking stories targeted for one individual due to their specialized skills. Make sure the whole team is involved in delivering each story.
- Develop an “in it together” feeling among the team. If you aren’t feeling this, your team isn’t operating as a true TEAM.
- Commit to less stories to make sure your Sprint backlog really is DONE at the end of a Sprint.
- Become more of a generalist. Scrum certainly favors “jack of all trades” type of developers. Coming from a Waterfall environment, where there are separate groups for QA and documentation, work can fall to those with that domain specialization. As a team member, don’t look at work as “that person’s”, view it as a team deliverable. Learn a new skill to help a team member (and thus the Team) out, be it coding, QA or documentation.
- Be honest and innovative during your Sprint Retrospectives. It’s your chance to change how you work together to deliver software.
- Get additional training or coaching. Read Scrum blogs and ask questions on Agile forums. Likely you are not the first team to run into the issues you are experiencing.
- If you are manager reading this, realize that team cadence, a predictable velocity, is key to delivering on corporate objectives. Work hard to remove team obstacles and allow them to focus and succeed. This is the true value of a manager in an Agile world.
No comments:
Post a Comment