I’ve been developing products the agile way for the past ~10 years. While I have plenty of cynicism on the topic, I have even more about a waterfall approach.
Most of my cynicism over agile comes from the fact that getting everyone to play the various agile roles is near impossible and most products/companies will drop the purity of agile long before they give up sales driven deadlines. Not that I would choose to do it differently, but it points to some amount of futility in trying to fully adopt agile. This is often why people pick and choose what’s useful from agile for their group. I accept all these limitations, but there are still several lessons from and about agile that are often missed at first glance.
The Psychological Effect of Agile/Scrum
Typically, when someone hears about scrum the first time, they think it’s a process to inform everyone about what’s going on. There is some truth to that, but the more prevalent effect in my experience is it presses on everyone’s guilt gene. The basic manifest of a daily scrum entry is:
- What have I done since the last scrum
- What do I plan to do before the next scrum
- What, if anything, is blocking me
I may have a stronger guilt gene than most because I can’t go for more than a couple days not having something interesting to say that I have done or will do. Whether people like agile and scrum often depends on how well they deal with this pressure. Some people probably spend way to much time worrying about how well their reports sound each day. Others may monologue a bit too much in an attempt to impress everyone else. In a few cases, this may weed out team members who aren’t really contributing. But you might also make people feel like the system is built around distrust to have to ask you to share what you’ve done each day.
Similar effects can also occur from end of sprint demos which are generally meant to be a way to let everyone get informed about what’s being delivered as part of the sprint. But they also have the effect of peer pressuring everyone into presenting something or feeling like they aren’t delivering.
Overall, scrum promotes a model for continuous productivity. For me, the knowledge of the psychology trick doesn’t dampen the positive effect. It does help me relax a little from any undue stress the status updates might normally trigger.
Sizing is an area that most people tend not to get right away. Let’s start with some general rules of sizing:
- Sizes are based on the Fibonacci sequence (1,2,3,5,8,13,…)
- If you think the correct sizing is between two values on the Fibonacci sequence, round up. The point of using the sequence is sizings are less accurate the larger the item is.
- Sizings are not relative to the person working on an item. They are relative to each other. 5 == 5. Not my 5 == your 8.
- Sizing with planning poker should be as blind as possible. Details for anyone not familiar with planning poker: https://en.wikipedia.org/wiki/Planning_poker
- It’s important that there is discussion about the sizing resulting from planning poker even if everyone voted for the same size. As much value comes from the discussion about what the task involves as does from assigning an accurate value.
- People must stand up for their sizing for the duration of the voting round. Perhaps they were thinking of an easier way to do something and voted for a lower sizing. Or perhaps they saw complexity that no one else did and voted for a larger sizing. It’s toxic for someone to back down from their vote because everyone else voted differently.
- You shouldn’t change sizings after work is completed unless the end state varied drastically from what was originally sized. For example, if you didn’t finish half the work and decided you would never do it, it’s fine to cut the sizing in half and consider the task complete. Resizing shouldn’t be a common occurrence though or your knowledge of velocity for planning future work will lose accuracy.
I wouldn’t consider these the decisive rules. They are primarily intended to call out the pain points. It’s a fairly big problem in getting everyone to use the same frame of reference, but it’s important that two items sized with the same number are approximately the same size.
I’ve never been a fan of using sizing as a review of anyone’s personal performance (other than perhaps in a more binary sense). Doing so will tend to have a bad effect on morale and might cause unintended side effects of people trying to get the cheap points or generally inflate their sizings. Other than the discussion that happens as an item is sized, the primary benefit is gaining knowledge about your team’s velocity as it relates to future work.
The biggest problem with agile tends to be the development teams are often left on an agile island all on their own. From a business perspective, agile often sounds great. You’ll get well tested features delivered constantly and all you need as input is a list of priorities. However, pretty much everyone on the business side of the house also wants a schedule for which features will be delivered so they can talk to customers in advance. Plus the overhead to constantly stay on top of a development team’s backlog is generally more than anyone officially in a product owner position actually has time for. This typically means the responsibility of prioritizing the backlog falls back to a team lead type position who does the best they can based on whoever is yelling at them the loudest.
Regardless, the more technical a product is, the more the product owner role becomes a collaboration between the team lead/architect type and a product manager type. Pretty much every product I have worked on has fallen into this bucket to some degree. Typically, the more involvement from the product manager you can get the better. The OpenShift team is fortunate in this regard, but it’s always necessary for the team lead to fill in gaps and ensure the team isn’t blocked from owner/stakeholder feedback in the day to day activities.
Depending on the product, it might be possible to skip release planning entirely and instead focus on continual backlog grooming and prioritization. But if you can’t actually release your product each sprint, which is typical for most non hosted solutions, planning significant releases every quarter to year is typical. In making this step, it’s important to avoid the technical debt traps that come with waterfall. You still need to make sure your sprint boundaries are taken seriously and your product is essentially ready to ship each sprint even if you and/or your customers can’t actually afford to do so. OpenShift fits into this bucket with OpenShift Container Platform.
We can’t generally afford the overhead of a release (upstream stabilization, install/upgrade development/testing, performance testing, reliability testing, scale testing, etc.) more than once a quarter and our customers generally can’t afford the overhead of deploying major releases more often than that either. So release planning is somewhat necessary for us. We, however, try to mask the release planning from our scrum teams as much as possible by using agile metrics to approximate rigorous planning. Our process is as follows:
- Continuously groom backlogs (everything sized and in priority order). You can see each of our team backlogs in our Trello organization.
- When it’s time to plan the next release, refer to your team’s velocity to know how much you can accomplish per sprint. We track velocity for each team in our public reporting tooling.
- Multiply (# of development sprints in release) * (velocity per sprint to know how many points you can potentially accomplish)
- Take a percentage off the top to account for tech debt or unknowns. Typically at least 20%.
- Draw a commit line at the half way point.
- Target up to 100% depending on how aggressive you need to be. Don’t rely on anything targeted actually getting done.
We publish the results of this process on our public reporting tool and we also have it broken down by team. The end result is that teams can work their way through their backlog in priority order and accomplish their committed items with a fairly high degree of certainty each release. Targeted items will more often than not be delivered as well. But the separation between targeted and committed allows wiggle room for other items to rise to a higher priority mid release and take precedence over targeted items without making everyone feel like they have failed to deliver what was promised.
Overall, the pick and choose method of agile/scrum can be very effective. The key is understanding where there is value in each of the processes. Asking an engineer to blindly trust a process and expect it to solve their problems will generally end in apathy or revolt. Getting engineers to understand and believe in a process will foster self driven teams.