One-week Sprints?

Background

Early in 2015, I was assigned to help a team that was struggling to deliver value for one of our major clients.  It was a small onshore requirements and design team of about seven BAs and Architects.  They were supposed to produce documentation for a large offshore development team who would implement those requirements.  When I joined in February 2015, the team had produced nothing.  The product was due to ship in September.  Requirements and design had stalled.  The offshore development team was idle.  The program was burning thousands of dollars per week with no tangible results.

The Problem

After having interviewed the main people involved, I found that the root of the problem was a highly energetic but somewhat unfocused Product Owner.  The entire product was dependent on the PO for definition.  His job was to feed his ideas to the requirements and design team, who would then document those ideas for the development team, who would then create the product.  But the PO was changing his mind daily.  He would shift the team's focus from one area to the next on a daily basis, assuming that they had gotten what they needed out of him for the previous day's focus, and the team was not given time to complete their work.  The result was that not a single document had come to completion despite several months of effort.

The Solution

The solution is simple in hindsight, but it was not apparent to anyone at the time.  The team had recently been introduced to Scrum and was attempting to carry out its events and responsibilities.  But they had not learned Scrum properly, nor had they embraced its values, so they were not able to reap its benefits.  They were working in eight-week "iterations," which is to say that they were not actually doing Scrum at all.  

So the first order of business was to get them properly trained and correct the mistakes they were making.  A one-hour "course" on the philosophy, responsibilities, events, and artifacts of Scrum gave the team a much better understanding of "how" they were supposed to work within this framework. And a small change in how they had implemented Scrum gave them the focus needed for success.

That small change was to start working in one-week sprints.  This is not common among Scrum teams due to the overhead of the Scrum events, but this mechanism was desperately needed for this particular team.  When the Product Owner came up with a new idea for the team's focus on a Wednesday, for example, he would have to wait until the Sprint Planning event on the following Monday to shift the team's focus to start working on it.  This gave the team time to finish their current week's priorities and present them on Friday before being reassigned to work on something else the following Monday.

Within weeks documents were being completed, signed off, and sent to the offshore team for implementation.  The program was able to ship their first release on time in September.  The product went on to become a successful global solution for this company.

Keys to Success

At the time, AgileThought had several Agile-related mantras.  "Respect the Sprint" was one of them.  As the team (and especially the PO) came to respect the Sprint, they were able to succeed with Scrum and in producing a viable product (in this case documentation for the offshore team).  The other key to success was the training.  People who hate Agile hate it because they've worked on teams that say they are Agile when they actually are not.  Once the team got properly trained and started using Scrum correctly, they started becoming effective. Very effective.  Until then, they were having a miserable Agile experience.

Also of Note

The Scrum team in this case was the documentation team.  The offshore team was not Agile.  The artifacts being produced by the Scrum team were documents for the offshore team, not the software itself.  This illustrates the fact that Scrum is a framework for solving complex problems, not just producing software.  In Agile we say that "Working software is the primary measure of progress."  In this case, the documentation team was hindering that progress. By implementing Scrum properly in a manner that solved the team's problems, the Scrum team was able to contribute its portion of the work required to produce the working software.  The entire program was not necessarily Agile, but the Scrum team was.  Its entire existence was to enable working software to be created, even if it wasn't creating the software itself.

<<Previous  |  Next>>