Just because we think something has value, does not necessarily mean it is valuable.
Often our perception of what has value is driven by a personal bias, such as that t-shirt from college you just can’t throw away. That t-shirt delivers value in the form of memories, however, you can’t derive anything valuable from the t-shirt outside of your memories.
There is a difference between perceived value and delivered value.
Value cannot be realized unless it can be quantified in some way.
This may sound like a semantic exercise but I think the distinction is an important one that needs to be made as it drives how we fund software development projects.
When organizations go through their annual planning cycles, they ask their functional leaders to come up with software projects that they want to do.
In this context, leaders may often turn to what they perceive will provide value, however, the value they perceive may not deliver the value the organization requires from a strategic standpoint and it often is not quantifiable.
This happens when the organization is not aligned with a shared understanding of the strategic outcomes that will deliver real value to the company.
There is often an inherent imbalance in many organizations, where you have one part of the organization working to eliminate some technology or functionality that another part is actively seeking to implement. These are real cases I’ve seen as a coach.
The way to deliver valuable outcomes (ROI) to the organization is to align your work to your strategies.
My valuation model takes your strategies and converts them into value factors that are applied across your entire software development Portfolio.
Using a portfolio investment approach we then define the organization's risk/return profile which will ensure that we are focused on investing in work that is both foundational as well as aspirational.
If you don’t have balance you will never reach your aspirational goals as your foundation can’t support it.
Software development is an expensive endeavor with annual investment running between 5%-10% of total revenue or more for most organizations.
Not knowing that your investment is delivering real value makes that cost go even higher.
Lean/Agile - The Art of Doing Less
Our traditional ways of managing software development projects center around generating ideas that are deemed valuable and then attempting to estimate at a detailed level the effort involved by having a team of people work to document ‘all’ of the requirements up front before the project even begins. These projects often will take many months to complete before anything of value can be delivered to the business.
Agile focuses on delivering value as quickly as possible, often within 2 weeks to 2 months. Lean focuses on maximizing work not done, which combined with Agile speaks to doing less as a part of our delivery process.
But what do we mean by less when looking at taking on a large feature/product development effort?
There are couple of ways that this comes into play:
1. Software is often littered with features that someone thought would be important to the customer, yet fails to deliver the value (need) to the customer. Worse still this code becomes part of our legacy application, stuff we have to code around and test against regardless if the feature is being used or not.
2. Often the perceived value of something changes once the project begins, causing the business to pull the plug on work before it is complete and anything of value can be derived by your software development team. This is costly both in terms if financing and employee happiness.
In both cases the business has expended money to have software developed with the end result being the business received reduced or no value.
When looking at Agile Product/Project Management we are asking the business to act not just as the agent of funding but as the consumer of the work as well. Too often the business is a distant or non-existent participant with respect to how their product is unfolding. Instead they rely on project plan updates that speak solely to progress against the agreed upon scope of the project at its inception over viewing what has actually been developed and delivered to date.
In an Agile setting business needs to review the work at regular touch points, often the Sprint review and actually see what is being developed. There is often a great difference between what the business ‘thinks’ they want and what they actually need. Seeing working software lets them see their idea in action, often with enlightening results. What they envisioned may not in fact be what they are seeing and more importantly not what they need (the value). They funded a Ferrari but maybe only needed a good old family sedan.
Business is typically missing in this very powerful process in Agile, a process which allows them to make course corrections and even stop working on features as soon as they reach their maximum value.
At one large entertainment organization I worked for several years ago, the business had us working on a large rewrite of a heavily used widget that resided on hundreds of thousands of pages. After performing a Discovery and Story mapping session we determined that the work should be done in three releases. At the end of the first release the business reviewed what we had completed and decided that this was actually good enough and then pivoted us to working on an even more valuable redesign of a key customer facing web app.
In the waterfall days the work that we did for that first release would have been put on the shelf, the money invested would have delivered no value to the business. With Agile we were able to complete the work and deploy to production, providing the business real value for their investment. They made the decision to stop this work and move on to more valuable work.
The Art of Doing less is about developing more mature approaches to how your organization funds and manages work. Instead of funding projects fund your teams, allowing for work to flow to them over having them focus on managing project scope to the bitter end of the project.
Move away from believing you have to have fixed scope to one that understands that Agile is about powerful flexibility and maximizing the value of the work that we do, while minimizing the amount of legacy code we leave behind.
A legacy system that is littered with large amounts of un-needed or under-utilized capabilities is code that is harder to scale, develop in and test against. When your teams talk to you about Tech Debt, this is what they are referring to and as a business you are both a direct owner and contributor to this reality.
The Art of Doing less brings with it a greater ability to maximize an organizations investment in its software and product development.
The focus for business should be on what is needed not what is wanted. Project funding models encourage asking for more than is needed so one of the first things you need to do is to move to a team based funding model. Develop a framework to assess value and risk so you can appropriately prioritize work as it flows through your teams.
Understand that each of your Scrum teams has a fixed cost (~40k per sprint), this should guide you further in questioning what you want your teams to work on. At some point in time in most projects there comes a point where there is a diminishing value relative to the investment.
Lean and the Art of Doing less requires changing your organizational mindset to understand there is also value in work NOT done.
Moving from Project to Team based Funding in Agile
When we move to Agile we typically form our teams and then happily keep our waterfall project based funding structure in place.
We do this for a few reasons:
- We think it’s the only way to show the cost of the work that we are asking to be delivered.
- Projects are easily understood from an operational standpoint as they have a defined start and end date which is tightly aligned with the cost of the project.
- It’s the way we’ve always done it.
As part of our project based funding model we have an annual project funding request process, where we spend weeks/months identifying the things that we think are important (note I’m not using the word valuable here) so that we can obtain funding. Things move above or below the approval line and when the dust settles we have a book of work that is committed to, with freshly minted project plans and a cadre of project managers to manage the money we just gave to these projects.
An annual project funding request process also means that we ask for what we need and then everything else we may or may not need. We ask for a Ferrari when perhaps all we need is a good dependable family sedan.
There is power in money, who has it and who controls it typically drives what gets funded and what doesn’t. It’s not uncommon for Sr. Leadership to commit to work even though their team doesn’t have any experience in the product solely to get the money to keep their teams funded and employed.
If you see a lot of potential waste here then you are correct. We see waste just in the amount of people and money needed to manage our project money. If a money market fund had as much overhead associated with it, I and everyone else would leave because that overhead just cuts into profitability.
Next let’s more waste related to developing the stuff we didn’t need and may not actually use. All of this extra stuff we develop has an expense associated with it and this is a long term expense. We have it built into our architecture negatively impacting our systems scalability, performance and security. We have to test it every time we build new stuff. Bet you didn’t take that into account when you did your Cost/Benefit analysis for the project.
When we move to Agile we have an ability to really simplify our IT funding function. It’s really quite simple – it’s the cost of your team.
In most organizations this cost typically hovers around ~$40k per sprint or over ~2 million annually. So as a financial manager trying to manage things like cash flow, depreciation and the like, this makes financial reporting much simpler. Each team becomes a fixed line item cost on my balance sheet and operating statements. I don’t have to worry about cost overruns from project funding since the team is a fixed cost. Product Owners ensure our teams work on the most valuable things in a consistent manner and at the end of the year we should/can be able to gauge the value of that work to some accuracy.
So here’s a challenge that we face, how do we actually assess value? How do we value things like reducing technical debt to make applications technically better? How do we value writing an input validation security framework that makes our application safer for the user and ourselves? How do we value things that our customers aren’t asking for, but in the end benefit from? That is the core element of software development, there is significant value in the things that the customer never sees yet we place little effort or priority in delivering these elements. Instead we focus on the visual functionality and throw quality and architecture down the drain in favor of meeting project timelines.
If you get the fact that you have a fixed development cost it actually should foster better conversations regarding what is really valuable for the entire organization to be working on. Not your pet projects, not the projects you agree to only to get funding to keep your people employed, that’s not how real value and efficiency happens and it’s time we stop thinking that it does.
Agile highlights very quickly that an organizations planning and funding functions are broken. It also typically becomes clear that we don’t have a real grasp on what our real value streams are and finding them often means removing political barriers that have built up over years. Agile requires that we redefine what value is and organize our delivery across these streams over organizational silos.
The traditional PMO also goes under a dramatic shift, moving from managing projects and funding to ensuring that programs align to the organizations value streams, are well understood and organizational impediments are removed for the teams.
So if you are looking to move your organization to Agile you must understand that your funding and planning functions must change to align to a new mindset and paradigm. Funding is easy in Agile, really it is (remember it’s the cost of your team), uncovering your value streams and maximizing the work that flows to your teams that delivers that value, now that’s harder (but not impossible).
Agile isn't Easy
Over the years I have seen many teams and organizations who start on their journey towards Agile product delivery make the mistake of thinking that Agile is easy, promotes freely changing direction and worse will fix all of your issues and make everything better quickly and easily. The truth couldn't be further from the reality. There is no such thing as a perfect software development delivery process. Unlike production lines for things such as automobiles where you have the same pieces going to together each and every time and each piece has a specific functionality, tolerance and timing, software development is the exact opposite.
Software development is about meeting changing needs across the dynamic nature of business For example - You wouldn't see an automobile company add anew feature to a car on their assembly line over a 2-4 week time period. They need time to design the entire process and ensure that the production line is capable of accepting the new change.
Traditional software development tends to align a bit more to the automobile example and in fact there are times where this type of rigid, pragmatic approach to product delivery is actually the correct process (Agile isn't for everyone nor for every situation).
However for those that are going to move to Agile you need understand that the type of discipline that you might use in the automobile example actually needs to exist in your Agile processes, seriously you ask? Yes - You need to be able to deliver high quality, well-tested and fully functional pieces of software every two weeks. Now are you seeing how difficult Agile can be?
If you think Agile is easy, then you are already on the path to failure and unmet expectations.
It is very common for teams who are moving to Agile to take their interpretation of the Agile Manifesto to the unhealthy extremes, for example:
- Working Software Over Comprehensive Documentation
Many teams I've worked with take this to mean NO documentation and that couldn't be further from the truth. We value working software over the need for documentation but I've never believed that you can have long-term success with your product without delivering some levels of documentation. Without documentation your software knowledge becomes tribal and when your tribe leaves the team or your organization, well so does their knowledge.
There are way for teams to build documentation as part of their daily Sprint development work. Using the combination of user stories and Behavior Driven Development (BDD) acceptance criteria as the foundational elements of your work you are creating your documentation as part of the work needed to deliver quickly. The great value in BDD is that the acceptance criteria is written in English syntax and then translated into test automation.
This process of writing stories with BDD is supported by Gojko Adzics book, Specification by Example and allows us to deliver light weight documentation during our sprints. I often see teams adding a story to a future sprint to handle their 'documentation' requirements of their previous work but I haven't seen this work long-term. Functional development, dealing with bugs, etc... will ultimately push these stories down into the backlog, never to be seen again.
The process described above is not easy, but it can be done and the teams that can get to this level of capability will succeed in driving value to your organization every two weeks.
One of the things that I consistently tell organizations moving to Agile is that it will highlight every current weakness of your product/software delivery methods. Agile is a game changer, it requires a mind shift in how you look at your product, the work that supports it and how you see the visualize the value your product delivers. If you are a leader who is going to be uncomfortable finding out truths about your organizations inefficient manner of product delivery then you need to think twice about moving to Agile.
Do you have TITL (To Important to Lose) people in your organization? If you do, then you need to really look at how they influence any changes in your organization. Do you need to get their approval, gain their support, etc....? If so you will find more often than not that Agile will scare the hell out of them. Successful Agile teams/organizations understand that self organizing teams take away the need for many of the day-to-day management decisions our middle management layer makes. Agile speed comes when you remove the friction of management layers and provide teams with a clear vision of what you want them to deliver.
You must be prepared for the resistance that you will face from your product delivery teams, not everyone wants to go to Agile We become comfortable with what we know and do in our daily work life and in that comfort comes stasis. If you are not prepared to lose people, especially your TITL people, then you need to question if Agile is really for you.
I know it sounds heartless, but I've been working for over 30 years and one of the first things I learned right out of college was that technology was disruptive and if you weren't on board with how it changes how you work you would be left behind. At one company I worked for many years ago, I saw Regional sales managers who had been with the company for over 30 years and when we rolled out a sales force tracking/marketing tool (which I led) there were several who refused to even turn on the computer, they were all let go within months. As employees we have the obligation to continue to grow and learn and continue to make ourselves valuable to our organization and if we don't, then you as a leader have an obligation to make tough decisions that ensure that the organization is continuing to grow and not stagnate with old processes. It's not personal it's business.
As you move to Agile you also need to understand the investment that needs to be made in your technology stack. Many organizations have decades old technology stacks which have been shoe horned into the future and though you get by you won't be able to become Agile until you have a strong Continuous Integration framework, high levels of Unit, Integration and Functional test automation. Getting to this will take time (and using the stories and BDD disciplines mentioned above will help you get there). You simply can't go fast if you don't have the technology backbone that supports it.
Agile isn't easy by any stretch of the imagination, it requires thoughtful introspection, focus on continuous improvement, disciplined delivery and a tenacity for value and quality that is never satisfied.
Baking In Quality with Agile
One of the things that I love about Agile and especially the related techniques of BDD and Test Automation is that if done correctly your teams are essentially baking Quality into your products AS they develop, not after. Traditional SDLC (read waterfall) took a very linear approach to project delivery which in turn translated into a similar approach to how we developed and delivered our software products.
In our traditional delivery methods, quality was not 'baked' in but tested out and we never ever got to the point where we are able to test out all of the 'defects' that are found, instead we create a bug database where 'bugs' go to die. Every organization typically has some form of a bug database with bugs that were 'found' sometimes years ago and were never fixed (of course begging the question were they ever bugs in the first place?) In Agile we really don't want to see a bug database because we should be instilling a zero defect policy for each sprint, meaning that we should never be introducing new tech debt into our product.
As I progressed on my Agile journey I came to realize that there are actually two types of 'bugs' that we encounter when we develop software:
- Bugs as Missed or Undefined Requirements
- Bugs as True Bugs
-- Bugs as Missed or Undefined Requirements - I will argue (and in a book that I am starting to write about this topic) that a majority of the bugs that we find and document aren't really bugs at all, but rather functionality that has been misinterpreted based upon the requirements definition that comes out of segregated development processes, ie Write Requirements, Develop Software, Test Software and Deploy Software.
Language is such an imprecise way of communicating that it almost virtually guarantees that if you have more than 1 person developing the software for your product you will get different interpretations of how to implement the requirement functionally.
Remember the old 'The System Shall' statement? that is commonly used in writing Business Requirements documents? I always thought that this missed the scope of the requirement, what about what the System Shall Not Do?. We focus so much on happy path for our functional development that we miss large segments of functionality based upon what an application shouldn't be allowed to do.
Let's take an example of an English word to convey what I'm meaning:
What do you think of when you see the word - BASS
Do you think of this:
OR this?
These have the same spelling in the English language yet they have two entirely different meanings. Our life experiences become a prism for how we interpret what we read and how we react to it. (PS, I'm a musician so I think of the instrument before the fish)
Teams that rely on written requirements documents that are reviewed and worked on independently, meaning developers develop the code/functionality and then pass it on to testers will inherently have issues/bugs related to how something was interpreted and then developed. In the above example the developers may have thought they were delivering a bass guitar, but the testers were expecting a bass fish (yeah extreme I know) but I believe this is the root of many of our issues when trying to deliver what the business expected in the first place.
-- Bugs as True Bugs - I believe that true bugs are more technical than functional (or should be). Bugs related to how integration happens are very common because although we can describe the behavior of our feature we can't always anticipate issues related to how independent systems will work together. Many 'true' bugs in Agile are caught in the moment and fixed before they ever make their way to production. For the Finance people out there this is a tremendous cost saving that has been proven time and again. ROI is greatly enhanced when you deal with tech debt up front rather over time. And please don't ever think really that it is more important to get 'something' to production over making sure that the product is operationally sound.
So what to do?
To address the inherent limitations with our communication, we need to abstract our thinking into more concrete descriptions of behavior over broad-based statements such as the System Shall.
User Stories and the corresponding BDD acceptance criteria are a great way to do this as a BDD example table clearly defines the behavior of our product functionality via outcome based upon inputs. The 'language' of BDD is unique so that everyone can begin to have a shared understanding of what the story and behavior of the product(aka system) will do. BDD abstracts our communication and removes individual interpretation.
In Agile we start by ensuring that the teams understand that they OWN the quality of their delivery. One of the things that I absolutely love about high performing Agile team is that there is no finger-pointing, if a Sprint fails to deliver what the team committed to then everyone shares the blame, not just an individual or functional group.
How we bake quality into our products is by understanding how to write User Stories that provide context without the ability to misinterpret the meaning of the requirements.
To do this we must first ensure that we have a well written user story, what does that look like?
A good user story needs to identify the What and then the Value statement. Many teams that I have worked with start to write stories that only identify the actor and What but leave out the value statement, which is really the proof that what we are working on is of sufficient value to devote our resources to. A good user story should never have any Creative or Technical design conveyed, I know that many people like to show their technical knowledge by writing stories that convey what they think the design or system will need to utilize, but all that does is start the team down a path before exploring all options.
Behavior over language interpretation is what you are striving for when writing contextually rich user stories.
BDD with its accompanied Example statements takes an otherwise basic user story and brings it to life. Much like we do when we take basic ingredients for cookies and then bring them together in the right amounts to deliver awesomeness every time.
Software quality is much like baking, you need:
- The right ingredients - Good individual team members, honest communication, commitment to quality
- The right process - Write good user stories, add quality BDD acceptance criteria, code and test in parallel and then deliver, involve the entire team in writing BDD, involve the entire team in the estimation process.
By taking the time to build contextually rich user stories and define the story with BDD acceptance you move towards a shared understanding of the 'behavior of your product' over one that is driven by functional requirements. Requirements tend to convey to little of behavior and focus more on the big win that is being conveyed to Sr. Management regarding what is being delivered.
Agile is a very disciplined delivery process and in order to bake the quality into your product you need to develop efficient processes that keep the User Story/BDD train running smoothly. If you are entering a sprint and then writing your BDD then you are already behind, you need to develop a process by which teams are working on current sprint development AND building context for the next one. It can be done and when it is you get what I call progressive regression with the automation that comes out of your BDD work.
Agile is very disciplined and to think that going Agile will make your current life easier, well guess again. What Agile will do is highlight EVERY current weakness you have in your current product delivery process and then focus your attention on finding ways of improving on them.
For those of you looking for workshops regarding User Story/BDD techniques, please reach out to me at soundagile@gmail.com.
Monetizing Agile Projects
Coming from a finance background my education and experience is grounded in ensuring that money invested returns ROI. We think of things such as ROI, IRR Cash Flow, etc... For example when a manufacturing company decides to make a hardware purchase for machinery (any kind) to produce some type of 'goods/product' they perform financial analysis regarding the cost of the equipment, the rate of return that it will generate, how quickly they can amortize it and ultimately what is the net profit that the machine is expected to generate over its anticipated lifespan.
For most of my career we start on projects that have a goal in mind, potentially new revenue or cost savings, some have gone so far as to try to determine the ROI, but in general I haven't seen the type of due diligence that manufacturing type companies perform, applied universally to software development.
This may be an underlying cause of many of the software development projects never seeing the light of day or failing to deliver the expected outcome because we never performed effective financial plans that would establish the scope and speed necessary to deliver a software product so that it warrants the investment.
In Agile I think we have ways of providing some level of financial analysis that can provide us with an understanding if an idea is worth pursuing.
- Using the following as a guideline we can begin to estimate costs:
- Team Size - 5
- Blended Rate - $125 an hour
- Hourly team rate - $625
- Cost of Sprint(2 weeks) - $50,000
- Let's assume that the feature that we want the team to work on has come back with an estimate of 5 Sprints.
- Estimated Development Cost - $250,000
- Let's now assume that this investment is expected to yield an additional $1,000,000 in annual revenue.
- Expected ROI in the first year - 300%
Before we engage our teams we need to be sure that the $250k investment will return an appropriate level of return. In this simple example its a no brainer.
But our world of software development isn't always so clear-cut, we often don't know what the expected outcome will be until we release the product into the wild. There is often additional cost for refactoring before the product hits the mark with your consumers.
But using some of these simple ways of working through anticipated costs we can easily modify the example to reflect additional Sprints for refactoring once the product is released.
In this example let's assume that the team requires an additional 8 sprints to move from MVP to final product.
The final cost of the product would climb to $625k and our return would drop significantly to 54%. Still not bad but not the eye-popping number we initially thought it would be.
Factor in sustainment costs into this over the life of the product and you begin to see that your investments in your software absolutely need to go through the same level of analysis as other types of large infrastructure purchases that non-software organizations go through.
I'm currently working on creating a lightweight model based upon Markowitz's Efficient Frontier investment model that money managers use today to ensure that your risk and return threshold is aligned. I'll be posting my initial thoughts and approach in a coming blog.