Menu

Business Agility - What was step 2 again?

Vimal Pillai // April 21, 2021

Agile

You are here

We are continuing the article series to explore successful agile adoptions, and this week we are looking at actions taken early in adoptions that have huge lasting impact. If you haven’t yet had a chance to read the other articles in the series, definitely worth the time.

Business Agility – Getting Started  

Business Agility – What was step 2 again? <- You are here

Business Agility – Measuring and investing in growth 

Business Agility – Avoiding Chaos: Standards, Operations, and Guidance  ( part 2 here)

Business Agility – Keeping focus on the right things 

Business Agility – Been there, Done that… 

 

Key 2: Product vs. Project

When thinking about the next major thing that our company will bring to market, do we approach it as a long-term endeavor to better serve our customers or do we treat it as a short-term push to get something done? Both approaches have merit, but often we approach complex portions of work that will have a long and active lifespan as projects. We also naively approach short term solutions to problems with so much pomp and circumstance that we reduce the value of the solution significantly.  

One of the stumbling blocks that we often see in transformations is the idea of treating the change as a project or being made up of projects. This mindset invokes the idea of a clear definition of start and end points. This invalidly gives the impression that we are done with the work, but unlike a physical project the work continues beyond the construction for many complex knowledge work deliverables. When working on enhancement, continued development beyond the original scope, and maintenance of the delivered system can often exceed the original development costs. It also gives the invalid impression that the “value” is in getting the work completed that was planned. This can be pervasive in measurement and incentives, like on time and on budget bonuses. If we broaden the focus to the product, and the value it produces, then a different picture emerges. That broader picture starts to include many factors that we take for granted in the short-term tradeoffs against long term maintenance costs.  

Modern project management has roots way back to the early 1900s, and many project managers would, rightfully, claim that some practiced Agile before it had a name. There is not an inherent issue with projects, but they do have some implicitly communicated commitments that we want to explore. There is risk in having too much project management and planning, just as there is risk in having too little. We often see that this problem in adopting agile practices. There is an odd tension being agile advice and planning, that when we look at Key 1 doesn’t exist in the values and principles. Implicitly presented in principles 1-4 of the agile principles is the assumption that we have a plan but are ok with it changing. That doesn’t mean that change has no cost, and ultimately that is the collaborative conversation that we want to have. 

If we can get this balance right, we can serve to create the best outcomes for the organization. The difficulty for striking this balance is in matching the rate of change, cost of change, and value of the change with the conversations that we are having in developing the product. When a product owner comes to the team on day 6 of a 10-day sprint with a new “must have” feature, how do we respond? If we accept the new item without discussion because that is the product owner’s prerogative, then we have failed as a team. If we tell the product owner no because the sprint commitment is sacrosanct, then we have failed as a team.

Imagine a different conversation: 

Product OwnerI have this great feature X that has to be in the sprint, it is the highest priority straight from the CEO. 

Team: Do we have all the information to build it? Acceptance criteria, UX mock ups, etc.? 

Product Owner: Not yet, but they will be ready in a couple days.  

Team: Great, sounds like it will be ready before planning of next sprint. Let’s make sure to set aside some time to understand it before sprint planning. 

Or, maybe this scenario… 

Product Owner: I have this great feature X that has to be in the sprint, it is the highest priority straight from the CEO. 

Team: Do we have all the information to build it? Acceptance criteria, UX mock ups, etc.? 

Product Owner: Yes, it is all here. 

Team: Ok, let’s estimate it. ... omitting significant discussion … It looks like this would be a 13, what 17 points should we remove from the current sprint to make this possible? 17 because there is cost to change, and we would have to close off some of the work already started. 

Product Owner: Wow, that is more than I thought. This doesn’t make sense anymore comparing the cost to develop to the value we think it will produce. Let’s put it on the backlog and revisit later. 

Or, maybe this scenario… 

Product Owner: I have this great feature X that has to be in the sprint, it is the highest priority straight from the CEO. 

Team: Do we have all the information to build it? Acceptance criteria, UX mock ups, etc.? 

Product Owner: Yes, it is all here. 

Team: Ok, let’s estimate it.... omitting significant discussion … It looks like this would be a 13, what 17 points should we remove from the current sprint to make this possible? 17 because there is cost to change, and we would have to close off some of the work already started. 

Product Owner: It hurts to lose that many points, can’t we just add it to the sprint? Maybe work the weekends just this once? 

Team: Unfortunately, we don’t have the capacity. We strive to get as much business value as possible done in a sprint already. We have seen multiple times that pushing so far beyond our historical velocity will cause burn out, quality issues, and likely still not get the full story done.  

In each of these scenarios, the development team and the business are having substantive conversations around the value of the product and the cost of change. None of those conversations are easy, and all include trade-offs. There are times where working a weekend is the right answer, there are times when a major item becomes the highest priority because of reasons outside the teams control. Agile is meant to create a framework for collaboration, not chaos or onerous rulesets that impede value creation. 

Key 3: Follow the recipe

null

There is a friend of Improving that throws a party each year, and it is at this party where the world’s best chocolate cake was discovered (in our opinion). Beyond the normal difficulty of getting such a delicious and moist cake, it was a gluten free vegan chocolate cake. After trying this cake, an Improver asked for the recipe and tried to make it themselves. It came out as a hockey puck. Calling the chef to ask for advice, a couple of likely problems were pointed out. It could have been the almond flour, or potentially the time cooked. Adjustments were made, and the cake came out of the oven as warm cake soup. Many more calls and adjustments happened in the coming weeks, but the results were hockey pucks or soup. Defeated the Improver stopped trying. The problem is not the recipe, we know that the recipe worked because the cake was real. The problem is not having the experience of baking the 10,000 cakes that preceded the recipe. 

We often see this story in the agile community, and it ends with blaming the recipe. It is often time followed by years where “Agile”, “Scrum”, or “Iterative development” are bad words. This can impede the adoption across the company and is typically the unintended consequences of seemly simple changes. Teams will seek to change things about the systems they use, and often for good reason. When a process or system has friction in it, the natural reaction is to try and remove the friction to allow the system to run smoothly. This often leads to better results and efficiencies. Unfortunately, if we don’t evaluate the friction, we can smooth things that are meant to force change. Like the team that doesn’t like retrospectives because they talk about the same issues every time. This can easily be met with a response like “Let’s only have quarterly retrospectives” or worse “Let’s stop having retrospectives”. The root issue is likely deeper and harder to solve, like not having commitments from retrospective items. Solving the root issue would be more uncomfortable work but reap longer term rewards. Like the team that gives the same update in scrum multiple times a week and determines that they need 2 daily scrums a week. This will allow problems to linger much longer but is easier than breaking down tasks into smaller pieces so that work moves more visibly and frequently. 

We typically give the guidance to follow the "by the book ”recipe of whatever framework you select for at least 6 months before changing something. This helps to push past the pain of adoption and gives enough time to grow and understanding of why each part of that framework exists. With that baseline of understanding and experience the changes are better informed and targeted at friction from the process not growing pains.

null

One of the advantages that we have at Improving is access to a great network of thought leaders in this space. One of the great thought leaders in the product ownership space is Don McGreal. Don’s book is generally accepted as the top source on Product Ownership. It covers and expands on many of these topics. Don was nice enough to share a significant discount through this link with the discount code “SCRUMORG”.  

If you are currently working agile, just starting the journey, or evaluating a move to agile ways of working, we would encourage you to read through this series. If you have specific questions, please reach out and we will strive to help with a no cost consultation. In addition, if you are interested in a Professional Product Owner Certification training, please contact us and we will provide you with a 2 for 1 discount code to help in that area.  

null

If you are looking to connect on a broader set of topics and connect with other community members and leaders, as well as hearing from industry leading experts, take a look at Improving Edge and register for a great set of thought leaders in many areas.

Most Recent Thoughts

How can we help on your next project?

Let's Talk

Like what you see?

Join Us
Top