Why Aligning Value and Strategy is Important

Value is often in the eye of the beholder and because we attach ourselves to the perception of that value we can’t often differentiate between what we want and what we need.

As leaders, we often follow a similar approach when deciding what projects we should take on for the w\organization.  For instance, we may read about something interesting that another company is doing and think that we should be doing the same thing, this becomes your want.

Unfortunately what that other company is doing may not be what your organization either needs right now or worse is not even strategically aligned to its strategies.

All too often organizations have an annual planning cycle where individual leaders pitch their ideas for new projects and request funding.  And all too often these projects are disjointed, competing with other projects seeking opposite outcomes, or are even duplicate efforts leveraging different technologies, all because their focus is more on wants over needs for their capability.

So how do we move from thinking in wants to acting on needs?  It starts with transparency and alignment to the organizations' strategies.

How many people in your organization know and understand the strategies that are key to delivering value to your customers?  How many more define their initiatives around those strategies?  Unfortunately, the answer is very few. 

To start you need to create a Portfolio Valuation scoring model that is tied to your strategies and then provides a scoring mechanism that is aligned to Objectives and Key Results.  The key results form the basis of the value factors that will generate a score for each initiative.

By aligning the scoring engine to strategies and having the value factors aligned to metric outcomes, we can apply the scoring model across the organization holistically.  This is key to moving from a wants to needs conversation in the organization.

Having implemented this model in several organizations what happens at the leader level is that they have a harder time justifying investments that they want if they have low scores associated with them.  How do you convince leadership that it’s a good idea to invest a million dollars in a project with a value score of .5?  The answer is it’s not easy.

At one organization that had been trying to make the case to invest in a new ERP system with no success, we were able to tell the story better when leadership saw that they were investing large sums of money into low-value returns.   So the scoring model isn’t just to stop you from working on the wrong things, it also informs future investments to support fact-based decisions.

Value needs to be the driving focus of any organization as you have a limited amount of investment capital for software development.  Adding useless features that don’t align to strategy and have low-value returns is a waste of money

Additionally building things you don’t need adds bloat to your tech stacks as this code still has to be maintained and supported long-term.  The cost of any feature is never just related to its development cost. 

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:

1. We think it’s the only way to show the cost of the work that we are asking to be delivered.
2. 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.
3. 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).

Launching SoundAgile Consulting

I've been involved with Agile with many different organizations now for over 12 years. In these years I've primarily been involved with being a contributing individual over a being an Agile coach.

The business of Agile has grown to a significant size and has now become a product that is sold to businesses who want to move their organization to Agile.  The very people who started Agile off as a movement have splintered off into several factions, each having their own opinion or approach in how to help organizations adopt Agile as a capability within their organization.  We now have Scrum, SAFe, DAD and LeSS to name a few in our acronym vocabulary.

Agile can indeed bring about valuable changes to an organizations ability to deliver software product more quickly.  These areas of Agile are fairly thought out, User Stories, Continuous Integration, Automation and Scrum.  You can move your development teams to a faster pace with some focus on specific team and development techniques that require some time to learn with some level of ease.

What Agile is struggling with is at the organizational level.  The Agile manifesto is specifically focused on building software better with a goal of delivering high value and quality software to our organizations.  A noble cause for sure and one that was sorely needed, given the changes in our software capabilities over the past 20 years.

Sr. Leadership however hasn't changed much, still managing in a large up front analysis budgeting process which creates a painful friction between fast moving product delivery teams and slow moving hierarchical management structures .

For those organizations who are being sold Agile as a product that will deliver 'x' benefits know this about what is occurring.  These organizations are finding people who have done 'some' to 'no' real Agile, meaning they haven't actually worked on an Agile team. Getting people who have the 'right' certifications doesn't provide those people with the ability to coach teams in the reality of Agile, only the theory of Agile and their current frameworks.

They are also focused only on the product development area of your business, letting you believe that you will receive huge benefits from moving to Agile without the corresponding changes necessary throughout your entire organization to support a fast paced product delivery teams.

Agile is not a small change management effort, rather it is a multi-year impact to your organization, that if done well will lead you to great success.  If done poorly will provide you with significant pain without any corresponding benefits.

I've spent many years thinking about what I might offer from an Agile consulting perspective and I've come to the conclusion that any Agile 'consulting' work that I would want to engage in must include both Sr. Leadership down and the team level.

Another thing I have concluded is that successful organizations that want to become Agile, must do so with a much smaller footprint of coaching.  You don't need full-time coaches for a long period of time.  In relying on full time coaches you are asking them to be your organizational Agile cop over owning the change within your organization.  The most successful Agile organizations I've worked in never had an Agile coach. Let me repeat that, never had an Agile a coach.  Instead they owned the move to Agile from the top down.  They provided the opportunity for teams to be empowered and fail and were not afraid to change organizational processes when they became impediments to improving Agilty.

SoundAgile will provide two levels of support and coaching for your organization.

1. Team Level - Coaching and training will be accomplished through a combination of online training videos, 1:1 coaching and targeted onsite sessions for specific techniques such as Discovery/User Story Mapping, User Story Writing and Behavior Driven Development.
2. Management Level - This will cover every management level in your organization, especially focusing in on your most impacted people, your technology managers.  Coaching and training will again be accomplished utilizing videos, 1:1 coaching and probably most importantly, targeted 1-2 day sessions that will continue for a multi-year time period. These sessions will provide for a longer term inspect and adapt change management process.

I'm really excited to be launching SoundAgile and am looking forward to working with people and organizations as they engage and encounter this thing called Agile.

SoundAgile will be live within the next two weeks.  I look forward to working with people who are motivated to move to Agile and make it work for them and their organizations.

Top Down or Bottom Up - Large Scale Agile Adoption

So I've worked in both large and small organizations where we have gone through an Agile adoption or the phrase of the day, Transformation. Having seen both sides of the coin I started realizing that you have two paths to take when considering moving your organization to an Agile delivery methodology.

I use the phrase delivery, because I think at the end of the day that is what we are talking about.  Strip away the manifesto's goals of conversation over documentation, accepting change, etc...What are are really talking about is moving an organization from a Project delivery methodology to one that is Product delivery oriented.

What is the difference?  From a Management perspective actually quite large.

1. Project Delivery - These have very strong controls which move people to a new project.  Budgets are set up for the specific time period of the project and then up front requirements and design are completed in order to ensure that the project is fully ready to be engaged.  Project Managers manage all facets of the project via extensive project planning and plans.  Management receives up dates as to the project progress on a regular schedule, usually weekly. Resources are assigned either in full or in part, yet no one actually monitors nor can they really manage whether or not someone is working 25% on a particular project.  Projects tend to focus on reporting and there is high pressure to ensure that individual projects are green, which drives teams to deliver on the easiest and often less valuable parts of the project first and only at the end of the project is the hard work tackled, which reveals itself as budget overruns or timeline delays (or worse delivery of reduced scope).  Project reporting is elaborate and management receives project reports that are often sanitized.  Value is typically not delivered to the organization until the end of the project.
2. Product Delivery - The work that is done for a Product is centered around a value stream it delivers and the work is ongoing.  Teams are funded as a whole and are kept together long-term in order to maximize their productivity.  Work is planned out in short increments called Release Plans that span anywhere from 6-12 weeks, with 2 week sprints.  Management receives regular updates (2 weeks) but can access information radiators at anytime, transparency is the key and goal with Agile Product Delivery.  Teams commit to work in 2 week sprints and their commitment is key to building trust with Management.  As time goes by management can trust that both a teams abilities and productivity can be counted on.  Teams are focused on delivering high quality code to production every two weeks which brings value to the organizations investment in them along with the increased value in terms of new sales, reduced costs, etc...Feedback loops via Product Demonstrations provides management the ability to assess where they are going with the product and deliver not what was asked for up front (Project Delivery) but rather what is actually needed (Product Delivery).

So what does the difference between Project and Product delivery approaches have to do with Agile adoption, well everything.

Most Agile adoptions begin at the bottom of the organization with the teams tasked with developing new software.  These efforts are borne, as the Agile manifesto was, out of frustration with how software was being developed in their respective organizations.  Often management is aware of the issues these teams face but are unable or unwilling to make any changes to how things are currently working and why would they?  You learn very early in your career that rocking the boat is not something that goes over well with organizations, my first boss told me I couldn't by computers that weren't from IBM because you don't get fired if you buy IBM. The message is that if anything goes wrong you need to point to well-known names, processes, etc.. with which to blame or use as support.  To think that this doesn't go on today is to place your head in the proverbial sand.

Though we can have great success with bottom up Agile adoptions with respect to improved productivity within small groups/teams, the overall Project oriented organization is typically still in place.  Management still wants to see project plans, have things 'planned' out for up to an entire year, they aren't comfortable with the fuzzy feel of product roadmaps.  They want commitments, even false ones, so that when things fail they can point to the fact that they had all of their planning in place.

For Agile to really take hold, Sr. Leaders need to change the way that they manage both their people and the work.  It starts first I think in understanding that we have not learned how to speak to management very well yet from an Agile/Scrum perspective.

We need to understand what management is really concerned about and then center our product delivery efforts around that.  One of the problems that we face with some of our leaders is that they themselves don't always know what to be focused on, they are looking at multiple balls in the air but at the end of the day as a Sr. Leader I think I have just a few things I should be focused on:

1. Growth - This is often related to sales, market and revenue.
2. Profits - Tightly aligned with the first item, our ability to make a consistent profit is what helps us continue to reinvest in our company.  Ever increasing revenue or sales without corresponding profits will eventually lead a company into bankruptcy, money isn't free and it is not endlessly available, in spite of what we think we see with new technology organizations.
3. Organizational Excellence - Because none of the above can happen unless you have a great organization.

Agile actually addresses all of the above, yet we spend more time talking about how we will improve our individual work efforts which causes us to  fail to tie this to the needs of management.  Management on the other hand often views the improvements that come from the bottom up approach as more of an anomaly rather than an organizational improvement worth adopting.

Trust is the missing component when it comes to conveying how Agile will make the entire organization better.

Agile isn't easy and it requires skills that frankly many of our Sr. Leaders lack or don't fully utilize and the politics of most organizations reward behavior that doesn't align with Agile principles such as transparency, open honest conversation and openly questioning the status quo.  We have people in power who got there by way of the non-Agile status quo and changing that means they have to learn how the new game is played in order to stay on top, it's much easier to keep things they way they are over learning how to navigate the new.

So how do we speak to our Sr. Leaders with respect to Agile?

1. Better ROI - Talk to any Finance executive about what they look at when purchasing a piece of equipment that will deliver revenue and you will hear them talk about Net Present Value of the investment, Positive Cash Flow and Depreciation costs.
   1. We improve ROI in Agile due to our focus on only the most valuable items.  In non-Agile project work often are working on features/functionality that may be important to someone inside the organization yet will bring little or no value to the organization.
   2. When we are able to start talking about the value streams of our organization, be they revenue, cost reduction or improving our brand image we begin to be able to have a better ROI conversation with management.
   3. We also positively impact ROI via higher levels of productivity gained with dedicated teams.
2. Flexibility - One of the most important elements that 21st century organizations require is the ability to be flexible enough to react to market forces or reactions.  Financing large projects far out into the future with the expectation of some level of return and no we don't really have great track records of predicting future ROI out very far into the future.  With Agile we provide the framework to identify the most valuable work for the business in small planning windows.
   1. Sr. Management needs to understand that this flexibility comes with an obligation to have consistent short term review windows as the team progresses so that we deliver what is actually needed and not what we thought we wanted.  You may have thought you needed a Ferrari when in fact what you needed was a mini-van, we provide the framework to course correct via Sprint reviews every two weeks.  If you plan all of your project up front for the Ferrari, we'll certainly try to make that happen, but in reality as the end of the project nears you will probably get the car but with a lawnmower engine and no brakes, it may look like a Ferrari but it won't operate like one nor will it provide the value the organization really needed.
3. Predictability - Another key element that we deliver with Agile is predictability and accountability.  Your teams will be much more accurate in planning and delivering in short-term 2 week sprints with a planning horizon of 6-8 weeks.  What management needs to look for is consistent delivery of the committed work that the team makes, commitment is everything.  What Wall Street analysts look for is a business that can provide a solid ROI, react responsibly to their competitors or even better be a market leaders and provide predictable results year in and year out.

So the question at hand is what is better a Top Down or Bottom Up adoption?  My money for long-term success is on the organization that can consume what Agile really means, not just to their development teams but the organization as a whole.  You can't BE Agile if you don't make the paradigm shift from command and control to one of collaborative and collective delivery.

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.

1. Using the following as a guideline we can begin to estimate costs:
   1. Team Size - 5
   2. Blended Rate - $125 an hour
   3. Hourly team rate - $625
   4. Cost of Sprint(2 weeks) - $50,000
2. Let's assume that the feature that we want the team to work on has come back with an estimate of 5 Sprints.
   1. Estimated Development Cost - $250,000
3. Let's now assume that this investment is expected to yield an additional $1,000,000 in annual revenue.
4. 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.