Although the flavors of Agile vary on their level of prescriptiveness, it doesn’t mean that you can’t still have other processes in place that add value. I’ve lost count of how many times I’ve heard “we’re Agile” when a team doesn’t want to adopt any rules or process. If you ask about documentation, or lack thereof, they say “we’re Agile.” If you ask about the mountain of technical debt, they say “we’re Agile.” If you ask about design, they say “we’re Agile.” The point is that beyond the roles, meetings, and methods that each flavor of Agile prescribes, there is a need for other processes to ensure that quality software is being delivered. The counterargument is that having any kind of process is “anti-Agile” in some way, but that simply is a misunderstanding of Agile software development.

Real-Life Stories

Story 1: Process Can Add Value

Having been on several large Agile projects I’ve seen the difference that having good processes can make. On one project, for example, we had a process for code reviews. Since there were many developers all in the same codebase, it was critical that all the code adhere to our architectural and quality guidelines. To help ensure this was happening, we had approved code reviewers who were responsible for completing each code review. This process had the potential of creating a bottleneck, but for the most part, it worked very well. On another project there was no such process and the code quality was much lower.

Another example occurred on one project where we had a well-defined task workflow. We were using a physical task board, but it would have worked with an issue tracking system as well. For example, as part of our workflow we defined what should happen when a defect is raised in the Sprint demo. This meant that the entire cross-functional team was on the same page. The QA engineer knew who to assign the defect to and to mark the User Story as blocked. The developer knew to fix the defect before starting on any new User Story.

Thoughts

To have processes documented and followed by an Agile team is definitely not “anti-Agile.” It is when your processes are so rigid and they are given more weight than the people and collaboration that you are then violating a core Agile principle. In fact, I think having good processes can actually support the Agile principles and help teams deliver valuable software faster. One of the ways it does this is by adding consistency and leveling expectations, which, in turn, makes teams faster because everyone is on the same page. In addition to putting good processes in place, in some organizations you don’t have much of a choice but to follow defined processes. So, I think finding areas that can benefit from some defined process (perhaps go through a Value Stream Mapping exercise) and then creating and refining that process can really make a big difference for Agile teams.

Story 2: Clear Rules

There are many things outside Agile that teams have to deal with every Sprint. If you don’t have processes in place to deal with these things, it can really hurt a team’s velocity. While on one Agile project I saw this first-hand in the form of scope changes for User Stories. We would review the User Stories during Sprint Planning. As usual in Scrum, we would ask questions, re-estimate, and finally commit to a set of User Stories to fill the Sprint Backlog. But inescapably during the Sprint, requirements would change. On past projects we would absorb these changes. But on this project we decided to have a process in place to handle these changes. We would create a Change Request whenever the business would change the scope of a User Story and then the business would prioritize the change in the Product Backlog.

Thoughts

Story 2 provides a simple example, but having that process in place made a big difference. First, it took pressure off developers to absorb extra work. Second, we were able to keep our original point commitment (we were using Scrum). Third, it put the pressure on the business to write good User Stories. Finally, it made the collaboration between the Agile team and the Product Owner better because everyone was clear on how to handle scope change.

Story 3: Simple Definitions

When I’ve been a Scrum Master, I’ve typically preferred to keep the Scrum board as simple as possible. For example, I prefer to have just the basic states of “Not Started,” “In Progress,” “Being Tested,” and “Done” on the board. But how does the team know when a User Story can make it into the Sprint Backlog in the first place? I was on one team where we had clear definitions of what “Ready for Development” meant and only when a User Story met all the criteria would it be brought into the Sprint Backlog. It was a checklist of sorts that we used during our Sprint Planning meeting. It did not replace the communication in the meeting but was, rather, a way to make sure we didn’t forget anything that had bitten our team in the past. These criteria changed over time as the team learned more. It really helped to reduce the amount of times the team was blocked in the Sprint. I’ve also been on teams that did not have this process in place and from my experience those teams had a less predictable velocity.

Thoughts

The point of Story 3 is that you can complement Scrum with processes that work for your team. There is no right answer and each team is different. You need to do what works for you. Some of the processes and the “Ready for Development” checklist I mentioned came out of the team’s Retrospective meetings. In this team’s case, making the checklist part of our process made the team faster, which meant we could deliver more valuable software to the business.