The process of process
During my time at Microsoft I worked on various teams. Somehow in over a decade, I managed to time it so that I was there during the transition from waterfall to agile like processes on almost every team I was on. One of the teams claimed they had already switched fully to agile. However, it turned out that they had just added a bunch of process on top of the process they already had. I observed several patters and have built up a set of opinions.
The biggest downfall? Randomly adding or swapping process and hoping for magic. Sort of like https://dilbert.com/strip/2013-02-15
Understand your current process. This helps avoid accidentally messing up what’s working well. Determine what improvements you want. Evaluate the well know processes and determine if you can adopt one as is or if you need to customize the team’s approach. For example, capital A Agile has a suite of processes and guidance points, but through needs to be applied on how those are applied to ensure that you actually get the desired agility or other improvements.
Process vs. Bureaucracy: Process is there to make us more efficient and or the product better. Bureaucracy is extra work that slows us down or is unnecessary. One important thing to keep in mind is that sometimes it’s simply that the value is at a broader context or not instantly obvious.
Process Experimentation: I’ve seen some teams do more upfront planning and other teams who want to experiment. Experimenting with process changes can be a helpful way to tweak and refine the process. This can also allow the team to be apart of building how the team works. However, there are some downsides. If you don’t know what improvements you are looking for it isn’t really an experiment, it’s just playing around. If you don’t have a clear plan for when you will evaluate and lock or adjust, people will be left with uncertainty.
Double tax: I have seen teams use both waterfall and agile practices together. Scrummerfall. It’s okay to be in a customized model, but it should be intentional. The problem I’ve seen is when a management team decides that certain waterfall artifacts need to be maintained and the team essentially has to do the same work in a bunch of ways. It’s a slippery slope that can lead to wasted time, slowing down, and frustrating the team.
Here are a few specific areas I’ve seen teams struggle with. These are particularly common on big teams with long entrenched process.
- Predictable velocity
Arbitrarily picking a velocity doesn’t make it happen. The important thing is to be able to accurately predict the work that can be done in a sprint. There should not be high overhead in costing because that just takes time away from the actual work. The goal is to track velocity for each team in unit that can be used consistently. The problem with hours is that it is usually subjective per dev, different folks are more accurate, it either takes a ton of effort to be accurate or they tend to be in accurate. Relative size in points split by Fibonacci units chosen as a team is known best practice. If you and your team are used to having each person estimate the number of hours, this will require a change in how you discuss cost and a change in how the team works, but it is one of the most valuable changes that can be made.
- Consistent done means done
Some teams have many definitions of done (code complete, zbb, shipped). I’ve seen teams where the level of sprint doneness is not ship quality. This means there is hidden debt. It can lead to a long stabilization times at the end of the release. If there is still long stabilization times we won’t be able to release with confidence at an on-going rate. It risks cutting quality at the end rather than features because all of the features have quality work in the end-game.
- Smaller, more focused scrum meetings
Scrum meetings should be all about unblocking and the soft escalation. It’s easy for scrum meetings to feel like bureaucracy and still not achieve the goal. There is a natural tendency to use this time to just share status. This isn’t particularly interesting to most of the folks and it doesn’t solve much. Scrum meetings should focus on raising issues before they are big issues. For example, if a work item will take a day longer because we are not blocked by someone or a new complexity came up. The idea is that information that is shared should either let others know that they will be impacted, or highlight risk so that someone in the group can help out. Standup groups should be limited to the size where those in attendance have an interest in the other areas – dependencies, ability to advise etc. Consider feature crew standups instead of full teams. Should be short. Focus on identifying blockers, issues, changes to plans – match up the right people to unblock the issues. If things were expected to be delivered but aren’t explain. If things are on track, nothing needs to be said. The reason chairs were initially removed is because it should be that short, not because it’s useful for a room full of engineers to stand around the room like a high school dance.
- Reduce sprint duration to 2 weeks to honor sprint boundaries
Work should not be added to the sprint once it is started (except P0 bugs). A month is too long to wait. A quarter is definitely not a sprint. Sprint boundaries should be reduced to 2 week sprints. If you have larger major milestones, that’s fine. There are a few issues with long sprints. First, they end up taking more time to plan. Secondly it’s very hard to keep others from adding work. A month is a long time. Too much happens. Plans change and then folks spend longer to plan next time.
- Sprint showcase
While standup meetings should be small, I recommend a broader showcase. It’s a nice way for people to see progress. These don’t need to be over built or polished, but keep things short and quick. There are a few options for keeping the transitions between people short. 1. Have everyone ensure their demo is on one machine. 2. Have everyone VM. 3. If you have multiple ways to project, have one person setting up while one presents. It’s also helpful to have someone timing. Stick to the time slot. Have a fun (but respectful) way to cut people off.
- Completing fewer, bigger, more complete things at a time*
Large teams often have many things started that take long periods of time. This is a problem for a few reasons. This makes it harder to ship at quality at regular intervals, it makes it easy for features to linger on for months. It’s hard to get feedback on each feature because they all come on line at the end. This can be hard when teams are siloed. It will require a shared understanding to make it easier for fluidity of more devs being able to work on different pieces.
- Move away from long-term detailed planning*
Big orgs can require a huge amount of coordination to land the right features across teams. However, long-term detailed planning/ scheduling removes the ability to be agile and adds huge overhead. It can lead to large negotiations and as things come up (which being agile is meant to address) the right calls can’t be made because there are ridged negotiated agreements in place and it would disrupt everyone’s planning, leading to more overhead. A more effective model is to have a shared vision and shared priority of important customer goals. Without having so much detailed long-term planning overhead the space to collaborate with partner teams and do a sprint or 2 of shared planning in a way that groups can adjust together.
- Do the postmortem
Don’t skip it. I don’t care if the sprint went fine. I don’t care if it’s uncomfortable. This is the most useful tool to increase the speed and quality of the team. Have someone moderate. Their job it to keep things constructive. This isn’t about pointing fingers. It’s about taking a moment to reflect on where the challenges are, what’s working, and what’s not.
*requires larger org changes
