The Scrum process puts everyone on the team in the same position—Developer, doing what is necessary for the team to achieve its goal. I am guessing that in most teams, unlike pure Scrum, there is natural alignment or gravitation—each team member plays a more specialized role more often than not, like Analyst, Developer, or Tester. In my company, these are HR roles, and they are each represented on every team. Analysts write the user stories, Developers write the code, and Testers ensure quality control. I think this alignment, combined with how we portray an end-to-end Sprint on the Kanban board, encourages the team to build processes that look more Waterfall than Agile.
Step by step processes
When Kanban boards get specific, they might get prescriptive. Think about the story card wall or Kanban boards your team uses. What are the columns labeled? This can be very simple, like Backlog, In Progress, and Done; or it can be very specific, to list every step:
- In Analysis
- Ready for Development
- In Development
- Ready for Testing
- In Testing
- Ready for Product Owner Sign Off/UAT
When our backlog wall more closely resembles the steps in a process model and our team is comprised of specific HR roles that match the Kanban board, the team will naturally follow that process. Just look at what is described above—it appears like you have to complete your step, and it has to be 100% complete, prior to starting the next step; only those with the appropriate title can work on each step. There are even holding patterns, like Ready for Development, or Ready for Test to push work to the next group.
Waterfall inside a Sprint is not agile, and predictability is not quality
Performing each step, ensuring that it is complete prior to starting the next step, is Waterfall. Doing this over and over to build up the software product is iterative Waterfall.
In my company, and on my team, we encourage teams to have a complete and ready-to-play story card backlog of two full Sprints (based on the team’s velocity). I think we do this for two reasons: first, our company predominantly followed a Waterfall software development pattern until very recently—our in-house methodology started this way as well; its comfortable and allows us to reduce perceived schedule risk. Second, and more importantly, we are looking for predictability. As managers, we want to ensure that our teams will meet their commitments, and if we can take the analysis step out of the Sprint and make sure it is complete before we start, then that is one out of three steps in the process that we don’t have to worry about. Now our Sprint estimates will be more accurate, Sprint Planning Meetings go smoothly because all the information is already elaborated, and we can focus on helping Development and Testing get finished in each Sprint.
But here’s the problem—the more time between when a requirement was written, and when it is developed, increases the chances that it has changed. Couple that time lag with the idea that an analysis team that is two Sprints ahead of the development team, has fewer chances to engage the Developers and Testers in JAD and Three Amigos discussions on each user story. This lack of collaboration will yield stories that aren’t really owned by the team. User stories will more closely resemble extensive documentation, since they will have to carry the contents of what would have been collaboratively designed by the full team, for the length of time in the next two Sprints, before they are developed. If the team collaborates, the user stories can be lighter and more efficient, and the combined knowledge of the team will prevail over a fully documented solution.
Just in time analysis, and collaboration with the whole team
I think we need to start moving in the other direction. Let’s get away from having analyzed and complete user stories prior to the Sprint. We should collaborate more, and build the product together, as a team valuing collaboration over contract negotiation. Developers shouldn’t be in the role of order-followers, they should be included in writing the user stories.
We should be comfortable blending the story card wall columns, and letting the work overlap each step. Analysts should feel comfortable to include Developers and Testers, with the Product Owner, in the conversation to complete the user story, including each group’s unique perspective, domain knowledge, and experience. Developers and Testers should be pairing, writing failing test scripts together prior to development, and running the automated test scripts as soon as code is complete. We should be utilizing strategies like Three Amigos and JAD-styled discussions to build collaboration into our team process.
Some analysis may be required up front
Just like you wouldn’t start building a house without a plan, you wouldn’t want to build software without design. I am fully supportive of architecture, design, and analysis prior to engaging an agile team to developing the software product. Overall scope understanding, so you can engage other teams, properly understand the work, estimate, and plan, are crucial in an enterprise environment. Having an overview of the solution, and knowing each detail in each feature are very different discussions. We want to take the uncertainty out of the solution, but wait to fill in the details when we are about to develop the code.
Let’s be Agile and collaborate as a team, rather than breaking our work into rigid steps that must be followed one-by-one. As Analysts, we should be collaborating with the team on each story, not way out in front specifying exactly what should be developed.