Agile is getting a lot of great press lately as we see companies like Amazon thriving by leveraging the concepts. But we also see push back from other business leaders on why Agile won’t work for them, or companies that have tried going Agile but are not seeing the expected improvements. Instead of realizing Agile as an all or nothing idea, we should analyze each of the Agile principles, taking a pragmatic approach to leveraging Agile within our own organizations.
This focused segmentation on each Agile principle is key since no individual practice will provide a competitive advantage. If something is easy to replicate, everyone will do it. Also, what organizations do is not simple – each one is completing a complex combination of different tasks to create customer value.
That leads me to this – The secret sauce of Agile is: It’s a framework built on strong principles you adjust to fit your organization. The goal is to make the right adjustments while not losing the underlying strengths that Agile brings.
To do that successfully, you need to understand each of the principles in depth. The four key Agile principles we have identified are:
BREAKING PROJECTS INTO SMALLER BITES
CONNECTING WITH CUSTOMERS
LEVERAGING THE POWER OF TEAMS
BUILDING IN CONTINUAL LEARNING
Join me over the next few posts as we delve into each one of the principles throughout this Agile blog series. Today, we start with: Breaking Projects into Small Bites.
Smaller Bites
The first principle is breaking projects and initiatives into smaller bites, following the old adage that the way to eat an elephant is one bite at a time. As we think about how to break up projects, we need to also answer:
- How will this project deliver value to the customer?
- How will it deliver value to the organization?
- How do we do it, including how long will it take, or how much will it cost?
If you think about construction, where traditional project management comes from, these questions are fairly easy to answer. If you are looking at building a new bridge, for example, to see if there is value, it’s easy to see what those who would use the bridge are doing today, and if they are willing to pay for a replacement. This answers the first two questions, so then the real focus is on how we do it. Since this isn’t the first bridge that’s been built, we can get a reasonable idea and estimates from previous projects to help us answer the last question. If we found ourselves without previous information, we would need to experiment. That’s much harder on these types of projects since there may not be an easy way to break the project up into smaller bites. We could start with a rope bridge, but chances are it’s not going to add any value till we have a four-lane highway ready to use, thus failing the first question.
Construction projects are not the only ones that may provide this complication. IT infrastructure or software upgrade projects are often similar and are quite a bit different from software projects – which is where Agile came from. Software projects are far more unique and have their own conditions to be considered. You see similar issues in marketing, educational design, business process changes, or any project where we don’t have a good, previous solution to copy.
The problem with these types of projects is:
- We may know what people are doing today, but we don’t necessarily know the best approach to solve their problems or how much value the customer will get.
- Without knowing the customer value, we don’t know the organizational value.
- Without knowing the solution, we don’t know if we can build it, and if we do, what it would take.
Even with this complexity, there is some good news. Unlike construction projects, these projects are easier to break up into experiments where we can test our assumptions and reduce the risk to the organization. The key is to focus on breaking the project up into the right pieces, that will help answer these questions as quickly as possible.
How to Break Projects Into Small Pieces
Let’s talk about how to break that elephant up with a real-life example. A company I worked with had a hypothesis that they were paying generous benefits but employees weren’t seeing that value since they didn’t know what those benefits cost. For the three questions, the hypothesis was:
How will this project deliver value to the customer?
If employees knew the cost of their benefits, they would be more satisfied
How will it deliver value to the organization?
Satisfied employees would provide more value to the organization (in this case reduced turnover)
How do we do it, including how long will it take, or how much will it cost?
We have access to the benefit information and can present it in the right format to make it easy for employees to understand.
Looking at how to break this project up, we would want to:
- Present employees an example of a current benefit to see if this increases satisfaction. If possible, we probably want to start with the biggest benefit.
- We don’t have time to wait for turnover, but we still need to measure satisfaction, perhaps with a questionnaire, targeting a group of employees that have the most turnover.
- We need to test if we can get access to the data and test different ways to show the information to make sure it is easy to understand
As you lay out what you want to learn, it gets easier to understand how to break the project into the right pieces.
Value of Breaking Projects into Smaller Pieces
So whether you’re agile or not, let’s talk about the benefits of this approach:
As an organization – testing the value of ideas early lets you focus on the good ones. It also helps to uncover big technical risks quickly so you get a picture of the real effort projects will take. Finally, delivering the projects quickly, and in small increments lets you deliver value faster, speeding return on investment.
As a customer – teams are already testing on real customers today; all of them when they release. Smaller testing means you get to see what approach a team is considering early, provide meaningful input on finding the best approach, and only a small group of customers is impacted.
As a team – testing early means you waste less time on bad ideas. It’s demoralizing to put your heart into a project and then not find out till the end it didn’t deliver the value you expected.
By taking this approach, Agile is pushing an empirical tactic, pressing you to think like a scientist, understand what ideas are really theories, and find ways to test the theories early.
As you look at getting this same value with your own projects, think about the three questions around organizational value, customer value, and the approach. If you have good evidence to support your ideas, it may be more similar to the construction project example, and focusing on how to efficiently put the project in place could be the best approach. But, if there are a lot of assumptions like we described above, it’s worth the time to set up a quick experiment and validate them.
On our next post, I’ll be reviewing the second principle, Connecting with Customers.
Don’t forget to view our Agile Transformation Services to learn more about how Kolme Group can help!