All Companies Overpay for their Technology Products and Features

I think one of the biggest challenges we face with Agile and the frameworks we use is that the concept of a project has not gone away, it’s even referenced in the Agile Manifesto. Yet when we talk about how best to maximize agility we talk about flow which is much more aligned with lean principles.

Business leaders need to have things presented to them in predictable patterns and projects provide that, having a set scope, and a start and end date. Simple, easy to understand, yet leaders also face the drama that unfolds when key projects fall behind, go over budget, or fail to deliver the benefits, which causes them typically to concede on scope in favor of getting something to the customer.

There is a solution, it’s to stop thinking in a project mindset and focus on value delivery. The sad fact is that ALL companies overpay for the projects that they fund. Why? Because every project has a tacit assumption baked in — The original scope of requirements are all treated as equal when they are not. Projects often are filled with extra features so that they have enough buzz associated with them that they will get approved.

If you want to maximize your technology investment it requires two changes to your management approach:

1. Develop a holistic valuation model that is part of your intake process.

2. Engage in close inspection of value delivery.

These two changes sound easy but are where your most entrenched processes and people are located. Think about how these two changes will impact your PMO. A group that is responsible for managing the organization’s projects through top-heavy and low-engagement management. Think I’m wrong? I was a project manager long before I became an agilest, I don’t make these statements without a deep understanding of what PMOs are charged with at most organizations and how they operate and I’ve seen no substantive changes in many of the organizations I’ve coached, some are better, but the project management mindset exists.

Moving to a flow-based approach aligned with lean agile principles will require a significant change in your funding model. It will also move you away from tracking dates and budgets and over to tracking value and investment. It will treat your technology costs as a long-term asset, not the cost center approach that still exists today in agile companies.

And as a leader who wants predictable results, your focus is not on predictable progress towards the fixed scope and end-date projects and instead is focused on ensuring that the organization is optimized for value delivery, which means removing the impediments that exist in the flow of work to your teams.

Everyone in your organization should be asking themselves one simple question — Is what we are doing improving our ability to deliver value quickly? If the answer is no, then you have a starting place to improve value flow. This means removing organizational impediments, removing managerial hierarchy (not management itself), providing teams with the necessary tools to develop high-quality products, and ensuring that teams have a manageable amount of work.

I’ve developed a valuation model, QValue, that aligns strategy to quantifiable outcomes. When we align value to outcomes, we also have a clear view as to what we need to change to optimize value delivery efficiency. To learn more about QValue go to www.soundagile.com

Join me on April 12th at 5:30pm if you would like to learn more about QValue. Signup here — QValue Sign-up — SoundAgile Consulting

Agile and Change require Consequences

A few years ago, I was brought in to be an agile leadership coach and during my time there I was responsible for coaching the Director of Architecture who after meeting me a few times, looked at me and said, ‘as long as I’m sitting in this chair and in this office, you won’t be allowed to do any of the agile things you are talking about.  We work the way I say we work, so you can cancel our remaining 1:1’s as we aren’t going to be doing anything agile while I’m here. ‘ 

I thought to myself, well at least I know where I stand.

I then went to the VP and relayed my conversations with the Director of Architecture and was not really surprised by his feedback.  He told me that she was the most important person on his team, and he relied on her to lead architecture over almost everything else. He said she was old school, but they go back many years together and frankly he trusted her more than he could trust me or the agile approaches I was suggesting as he didn’t have any experience working in agile.  And worse, he wasn’t willing to support some experiments in visualizing some wins that would help move behavior toward a new normal.

It was during this engagement that I developed what I call the three pillars of organizational change:

Transparency, Accountability, and Predictability. 

The transparency pillar is almost entirely focused on leadership and if you can’t get this pillar right no amount of focus on the other two, which are supported by the frameworks will result in real change.

We talk about the failures of agile, they are however often a result of having no consequences for not adopting agile.  That organization is still thriving in its industry, could it be doing better, delivering more value?  More than likely, but at the end of the day unless there are consequences for lack of change, no change will happen and no amount of coaching can change that.

Real change starts with establishing the transparent reasons the organization needs to move towards agile.  Explain the reasons, the challenges, and the outcomes to everyone.  Only after you have defined why you need the organization to become more ‘agile’ and the outcomes that everyone will track towards, will the organization have the support of everyone and real long-term change will happen.  These outcomes will be a key OKR for your leadership, which will support real change and this must be supported by agile coaches who have been leaders themselves.  Unfortunately, most coaches in the industry today do not have any real-world experience in development, organizational change, or leadership.  A certificate does not convey any underlying experience.

Agile transformations are sold as a waterfall project, and after 12-18 months your organization will miraculously become agile by implementing ‘x’ framework.  You won’t, organizational change is harder and long-term in nature.  If you are in the midst of trying to become more agile or just now thinking about it, talk to me.  My Soundagile Learning journey is a way for your organization to own and manage your move toward business agility.  Check out the learning journey here - Learning Journey — SoundAgile Consulting

Moving towards agility is an evolutionary step that must take into account how your organization works today.  Your business has been in a continuous state of evolution from its inception, to think that agile can be implemented any other way is just kidding ourselves.

Agile Is Dead (Or so everyone tells us)

So, here’s the thing, how we manage our businesses has changed so fundamentally, that it’s often hard to understand and even if there are companies letting go of their agile support functions, they are more agile today than when they started and once an organization moves towards agile, even if they go back to older ways of working, it won’t be all the way back.

When I got out of college PCs had just made their way into organizations. I remember creating elaborate forecasting models in Lotus 123 that fundamentally changed how we managed our manufacturing inventory. To create these models, I had to manually add data from all sorts of input, from SMSA marketing reports put out by the government to green-lined production and sales data spit out by our mainframes. It took me months to assemble this information into the models we used for our annual planning. Can you imagine anyone doing this now?

Today we operate at warp speed with information at our fingertips captured in vast data lakes. One only needs to look at the massive investment in data management capabilities to understand that Data is King in the business management world. But here’s the thing, investing in data only gets you so far, you still need people to interpret the data and, in many ways, companies may have over-invested in their data capabilities.

These changes have occurred in my career, and I understood many years ago, either adapt to your surroundings or you will be left behind. Yes, there will be those that don’t, like the Regional Sales Manager who threw the PC I had just installed in the garbage or the other one who put it in a closet as soon as I left. Both people, regardless of their previous sales success, were let go from the company.

Business leaders today face ever-increasing challenges and frankly, the Agile industry has for the most part let them down. We blame them for our failures, but the reality is that we have been working with one hand tied behind our back, and we are the ones who did that. Leaders need to understand how their engagement in technical agility will change how they deliver value to the business and its customers. Let’s also be real in that most CEO’s did not take a technical career path, so they aren’t as connected to how technology is delivered. Their expectations are that projects are approved, work is completed to deliver whatever my leaders decided was important and I’m given updates on two things — Budget and progress, Agile doesn’t come into play in decision-making at my level, and Agile is a ‘technology’ thing.

Since they don’t understand and don’t engage, they keep us at a distance or worse ignore us.

So though there is a question about whether the investment in Agile has delivered sufficient value (it has but has more work to do) the reality is that Agile is a response to the way the world is changing. Let’s look back to the 1990s when Agile and Scrum had their foundational beginnings. It was during this time that we entered the dotcom era. There was a massive change in the technology landscape (the internet) and when a change like this happens money will follow. Can you imagine investors coming to a dotcom business only to be told, thanks for your investment we’ll let you know when we have a website in around 18 months…. That wasn’t going to happen. This is where Agile approaches provided the avenue for change.

Now that Agile is over 20 years old, it’s time to recognize what has worked (team productivity, and quality) and what hasn’t (traditional project management and funding still in place).

Things are continuing to change at a rapid pace, so much so that perhaps Agile in its current approach and mindset is not going to work. Agile needs to address what they have missed, which is leadership needs. Without providing a clear way for them to translate the way they want to manage into an Agile delivery model, Agile is yes going to fail to deliver on its value proposition and be excluded from the conversation at the highest levels of organizations.

What is QValue? Managing your Technology Investment by Value

One of the things that have been consistent with organizations I’ve worked in is that we struggle, whether we admit it or not, with understanding if the technology projects will be a valuable investment.  And one of the key reasons is that we don’t look at technology from an investment mindset, but from a cost-benefit perspective, with cost being the way we determine if something ends up ‘above or below’ the line for approval.

We spend millions of dollars annually across the globe, and yet don’t have a meaningful way of identifying what is valuable, and worse we don’t often align our projects to organizational strategies.  Agile and the frameworks that are used say your teams should be delivering value every sprint or quarterly plan, but none of those frameworks has a value-based planning component.  The value proposition from an Agile perspective is primarily at the team level, which means we are delivering bottom-up value, it’s too isolated and siloed to provide clear strategic growth.

What we need is a holistic intake approach where we begin to quantify the value that we expect to deliver which is aligned with our corporate strategies.  We need to start having a value conversation before we move from our idea phase, to have the conversation if this is even something we strategically need to invest in.  I assure you that we spend a significant amount of capital every year because someone in the organization wanted to do something that they thought would be important, never having to quantity the value return from their ideas before receiving funding for their project.

Moving to an investment mindset for technology means that we will look at three primary elements:

• Value

• Cost

• Risk

Professional portfolio money managers develop an investment strategy that looks to diversify their investment portfolio across different investment types, such as stocks or bonds, and within these categories, they look to diversify further into small-cap companies, or those that have consistent dividends.  As a leader, you need to treat your technology investment in a similar manner.  Both business and architectural needs must be balanced, over investing in one leaves the business exposed to higher risk when something bad happens.

Nothing of value comes without a cost and eventually the cost to acquire an investment will outweigh the current and future value of the investment.  Investing too much in a diminishing return will result in lower ROI and lower growth long term.

Risk in the context of technology and value is all about developing transparency related to predictable value delivery.  If a team is inconsistent in its delivery, the cost of value acquisition will be correspondingly higher.  There is a point where the cost to deliver value exceeds the value we have identified and at that point, we should stop the work and look for something else.  Investment portfolio managers are constantly evaluating their portfolios to ensure that their investment is performing well, and when it is not, they sell it off so that have the capital to purchase something else.  In most organizations we don’t make that trade-off we simply throw more money at new projects; this is good money chasing after bad.

Over the years I’ve developed a model that adopts modern investment theory to technology portfolio management and the result is what I now call QValue, which stands for quantifiable value.  What the QValue model does is translate and align a company’s organizational strategies into a set of holistic value factors with associated value outcomes that can be leveraged consistently across your technology project intake process.  The model does not favor any one way of project delivery, but will most definitely support any agile ways of working as it is expected that the value being delivered will be tracked via value realization dashboards which will confirm if our ideas are delivering the value, we commit to with the value factors.

In addition to building out a strategically aligned way to quantify value, we also assess the organization’s delivery capabilities to create a delivery risk dashboard.  When making an investment we need to assess the expected outcome correlated to the expected cost and then risk adjust that cost to reflect the delivery confidence we have in the teams tasked to take on the work.

 Having implemented QValue at several organizations here are some of the key outcomes we have seen:

1.      Leaders begin to have investment conversations that ask if this is a strategic investment.

2.      They begin to see that many of their projects fall into lower value higher cost categories, making it harder to justify the investment.

3.      Leaders are able to make hard decisions on investments they have been reluctant to make in the past.

4.      People are more connected to why they are doing the work that they do, leading to better solutions and higher quality.

If you would like to transform your technology intake, funding, and planning capability to focus on value delivery, contact me at michael@soundagile.com to set up some time to talk.

The Dichotomy of Software Planning and Delivery

I’ve always been struck by the dichotomy of organizations that live on quarterly results, but whose technology planning aligns with annual (or longer) planning and delivery.  As a business leader, I need to provide quarterly updates and guidance on how my company is doing while hoping that the projects that have been approved will deliver the value that has been identified (even if only loosely defined).

Waterfall project management provides leaders with false comfort and evidence of how a project is progressing (how many projects are green right up until they are red right at the end?) but what this does not provide is any understanding of the work being done is delivering any value and we won’t know until the project is over.  Worse we rarely track whether the expected benefits of the project were realized, instead happy to have this project in the rearview mirror. 

If we want to align quarterly business needs with value delivery, we need to fundamentally change how we intake, plan and execute software projects.  It must start with value identification, are we able to quantify the value we expect to receive, and is it aligned with our strategies?  Outcomes delivery value, not output (which is what our current delivery capabilities, agile or otherwise, focus on)

Value must be the driver of what we do and that value must be realized in smaller increments of work.  This is where Agile can help, not with the implementation of frameworks, but through the adaptation of your organization to short-term value delivery.  You will find in this mindset that every aspect of your organization will need to be rethought to support this.  Implementing a framework to make you Agile will not deliver value in the way you need to operate in the fast-paced world we all live in.

Business Leaders Need to Understand Agile — It has NOTHING to do with Frameworks

I’m a businessperson first and foremost, having led several companies. As someone who has been involved with Agile for 20 years, I struggle with the myopic nature of what Agile has become, which is almost entirely focused on implementing and mastering an Agile framework.

Agile is now mostly about the operational optimization of a framework with value delivery an assumed attribute, but Agile hasn’t established an effective way to understand or identify value. Teams are expected to understand what it is and how to deliver it. The problem with this is that to deliver long-term value to my business I need to understand what I need to invest in first. Value delivery is entirely dependent on investing in the right things at the right time for the right reasons. Satisfying my customers is certainly important but there are so many peripheral aspects of my business that aren’t tied directly to customer satisfaction that also require that we make smart investments. And investment decisions should be coming from leadership with them directly tied to strategic outcomes.

Every part of the organization has strategic needs, but often what my operational leaders provide for funding are things they want or think will be valuable to them, and many times these requests end up creating organizational dissonance as the initiatives being approved aren’t functionally or strategically aligned. There isn’t an Agile framework out there that has provided a solution that helps organizations optimize their value stream investments so that they both understand the outcomes that are expected and how we will deliver on those outcomes. Value in Agile is not quantified, it’s either inferred or objectively assigned by people who are required to commit to the delivery of value, rather they are committed to delivering the project, which may or may not deliver value.

For Agile to succeed as a business framework we need to have a clear and unambiguous way to quantify value, prioritize it and confirm that the value we planned for is delivered. Failure to provide this is operational malpractice and yet we spend millions of dollars working to implement frameworks that have no hope of making your organization agile, at best you get some improved levels of transparency but without optimizing your delivery capabilities around value then Agile as it is configured today will only get you so far from an investment return perspective.

Agile is All About Value — why don’t we manage it that way?

I ran this statement through ChatGBT regarding value- How does Agile identify and determine what is valuable?

Key items I got back included:

• In Agile software development, value is determined by the customer or end-user.

• One of the core principles of Agile is "Working software is the primary measure of progress." This means that the primary focus is on delivering working software that meets the needs of the customer and provides value to the business.

• Another important aspect of Agile is the concept of a "minimum viable product," which is a version of the product that has the minimum set of features necessary to provide value to the customer.

• Overall, Agile teams use a combination of customer feedback, user stories, and a focus on working software to determine what is valuable and prioritize the development of features and functionality that will provide the most value to the customer and the business.

All very valid responses given the plethora of content related to the question.  And each one of them has a major flaw in how most organizations ‘do’ agile, which is that their teams have virtually no engagement with their customer and often have no idea how their work ties to a customer, think about that for a minute.

Most of the organizations that do agile still have antiquated planning processes that were in place long before agile was even a thing.  Projects are still planned up front, and perhaps even worse for value delivery the traditional way of capturing requirements in a business requirement document has given way to lightweight benefits documentation that provides little in the way of value context.

Planning projects up front with established requirements already in place, which are typically gathered by a business analysis group that is the ‘voice of the customer’ means that how the teams working in agile are already disconnected from the customer or user.  Value is lost in vanity statements about benefits and lofty language such as the ‘user shall’ do something.  Though it sounds user-centric, it’s not, and trust me I’ve written, reviewed, and tested off of hundreds of BRDs over the years.

So how should we define value?  From the strategic level, not at the team.  Teams should be delivering incrementally and responding to customer/user feedback to ensure we deliver the best possible outcome for the strategies we want to emphasize.  To do that the organization must define a value model that provides value scores that have quantifiable outcomes.  Teams that understand the expected outcomes will then have a clear understanding of what is expected and how they can design something that delivers upon those expectations.

I have seen too many teams get lost in the excitement of new technology that supports something they think the customer wants, to the point that nothing ends up being delivered or what is delivered is vastly different from what the customer actually needed.  The reality is that customers could care less about the underlying technology of a feature, if you told them it was developed in dbase they simply wouldn’t care if it met their needs.  To deliver the right solution we need to have the value we are expected to deliver clearly in focus, if we develop something highly complex we aren’t likely to meet our value/cost expectations.

QValue - Managing Your Technology Portfolio by Value

Over the past few years, I’ve created a Portfolio Valuation model that helps organizations develop a set of strategic value factors that when aligned with a comprehensive intake and planning process provide a value-scoring mechanism that will prioritize and fund work for their teams.  The model is called QValue which stands for Quantifiable Value.

 QValue design is based upon the Efficient Frontier model, created by Dr. Harry Markowitz.  This model is leveraged by investment fund managers across the world and provides them the ability to build a portfolio of securities (investments) that will yield a maximized return relative to accepted risk.  To simplify the intent of the model, it essentially helps fund managers develop an investment fund that maximizes the return they seek within the context of quantifiable risk.  Fund managers create investment portfolios that contain a set of securities that will be expected to provide a stable return, from which fund participants can select various portfolios in their 401k and stock portfolios to reflect their individual investment risks profile.

Organizations need to take a similar approach to manage their technology investments.  Your organization is the portfolio, and all your technology projects and initiatives are the various securities that when combined should provide a quantifiable return relative to quantifiable risk.  The QValue scoring model provides the framework for your organization to build a risk/return profile for all your technology investments, providing you with the ability to quantify value directly related to your strategies.  This represents a fundamental mindset shift from traditional cost management approaches to project funding.

You can’t effectively improve the flow of work to your teams if you don’t have an effective way of planning and prioritizing by value.  Non-value-based planning with its focus on cost benefits does not provide the most effective way to plan and prioritize with its lack of focus on value and return.  Understanding the actual return, you are getting from your team’s work, allows you to make better investment decisions and not over-invest in work that has diminishing or little value related to the cost of development.

Delivery Risk is Found in Your Teams

In my QValue Portfolio Scoring model, the way we develop the risk model is to focus on our teams. The reason we do that is that teams manifest risk in your organization and if you look at their delivery cadence sprint over sprint you can assess the risk of delivery by quantifying the team’s predictability.

Predictability often becomes a weaponized performance metric, but this is not at all what you should be doing. First, you need to understand that a team’s predictability is a manifestation of the inefficiencies of the organization in general. For example, if there is an inefficiency in the flow of work to teams due to a lack of strategic direction and roadmap, this will manifest itself in team delivery cadence as they jump from one top priority to another.

Risk in the QValue model looks specifically at the cost the risk may entail. We don’t directly look at risk from a delivery date perspective as we are focused on delivering small strategically aligned outcomes that are associated with an expected return which is then compared to the expected cost of acquiring that value. Unpredictable teams, through no fault of their own, have a higher risk of their estimates (and cost) being larger and taking longer to deliver.

Moving to an investment mindset for our technology portfolio we need to assess our expected return relative to the risk to that return from a cost perspective. At some point in time cost may exceed the return. The QValue model provides the framework to make informed decisions on whether to continue investing or move to something else.

If you want to understand where to invest in organizational/process improvements, look no further than the impediments your teams face, from lack of strategic direction, siloed management decision-making, and lack of clear objectives to high levels of technical debt or lack of automation. Your teams are the guiding light showing you where to make organizational process improvements that will support the smooth delivery of valuable technology solutions.

Rethinking Your Organizations IT Planning, Investing in Value

If your organization is typical, then you spend anywhere from 4%-9% of your annual budget on technology projects. The key word here is budget. If your focus is on a budget, then the way you plan your technology projects will inherently be centered around the cost of those projects. Though we typically accompany these projects with lofty rhetoric identifying the benefits of doing this project the reality is that we don’t quantify outcomes and the focus of the project management of these projects is on budget and scope.

To begin to reshape your mindset that emphasized cost, you need to adopt a modern investment theory that quantifies both the risk and return for specific investments (aka stocks or bonds) that are part of an overall portfolio of investment. To apply an investment approach, you need to view your organization as a portfolio that would include work to enhance business capabilities, and process improvements, as well as to ensure your infrastructure is stable and up to date. A portfolio is a diversified set of individual securities (eg - technology projects) that have a portfolio objective associated with it that defines the risk and return that the organization is willing to accept as managing their investments.

By moving to an investment mindset, you change your focus towards quantifiable outcomes that are strategically aligned as defined by your portfolio/organizational objectives. Too often annual planning processes concentrate almost solely on the cost of the project. Making investment decisions based primarily on cost, we miss the important value conversation that must come with it. We need to know if the cost of acquiring the value exceeds the value returned. We want to make informed decisions before investing. This is the only way to maximize ROI.

My QValue Technology Investment Model provides organizations the ability to quantify both tangible and intangible value so that we properly diversify our IT investment across the organization.

Agility Isn’t Found in a Framework

The Agile Manifesto is now at the 20-year mark, and I remember back in the very early, those of us working in it took everything we learned and applied it to how our organization worked and, in those situations, our ‘agile’ was customized to our organizational needs. We weren’t focused on any framework and the scaling we need happened within the context of the organization and work we did.

It wasn’t long after the beginning however that Agile Frameworks, some of which were designed by the Manifesto creators, started to take over. And in the ensuing years the promise of Agile has become the pain of Agile.

Now we are mainly left with an environment where we have Hatfield vs McCoys fights about which framework is right, who is doing it wrong, etc… which takes away from what business really needs — solutions to the challenges and problems that face them.

Agile frameworks have in many ways become the problem not a solution. Leadership doesn’t look to frameworks to solve the problems that face them, yet what they really seek is agility, not Agile.

What I’ve learned over the many years is that though frameworks provide some level of foundation for agility, they are still mainly focused on optimizing technology work and.

What you need as an organization is to develop three fundamental agility capability pillars:

Transparency, Accountability, and Predictability

1. Transparency — Must be pervasive throughout the organization. It involves:

a. Transparent Intent — The organization must be transparent in their strategic intent, expected outcomes and their people empowerment.

b. Transparent Empowerment — Establishing the guidelines, outcomes and expectations that will be part of empowerment is a proactive step towards real empowerment.

c. Transparent Strategies, Objectives and Outcomes — Without this key component, the people in your organization won’t understand intent nor will they feel empowered to pursue any outcomes without someone directing them first.

d. Transparent Planning — Everyone in the organization should understand how value is derived so that they all focus on defining the most valuable work that delivers long-term value.

2. Accountability — Must be embedded in the culture, fear of failure must be removed and replaced with learning and empathy.

a. Accountable Leadership — Leaders can’t define large projects and then place the responsibility of delivering onto people who haven’t had the opportunity to understand the intent, goals and objectives.

b. Accountable Goals — Must be quantifiable and defined collaboratively. We create dissonance when organizational goals are siloed, often pitting one functional group against another.

3. Predictability — High performing organizations and teams thrive on developing a consistent cadence of delivery, not towards a fixed date and scope project, but towards a goals and outcomes.

a. Predictable Decision Making — Decision making must be derived from data and aligned to the organization’s strategic goals and objectives.

b. Predictable Planning — Work must flow through the organization to the teams that perform the work. This will result in higher productivity and quality which will have the added benefit of reducing costs.

c. Predictable Cadence — The best teams deliver high quality outcomes when they are allowed to work in a consistent cadence. Teams that are provided clear goals and outcomes, while being empowered to decide how best to accomplish these goals, will consistently meet and exceed expectations.

This non-framework approach to agility is called TAP2Change.

Notice nowhere is a framework mentioned in the Pillars, they are implied to some degree, but not required.

Additionally, Frameworks don’t work if we don’t develop the Transparency Pillar first. This is because the frameworks have an implicit assumption that we have transparent intent, tied to strategic goals and outcomes supported by leadership that creates an environment of empowerment for the people who do the which results in actual value delivery, which delivers long-term results.

TAP2 Change seeks to influence your organizations’ culture through so that you can approach solutions to challenges from a platform of commonality of purpose.

If you would like to learn more about how TAP2 Change and develop effective Agility in your organization, please reach out to me at michael@soundagile.com or visit our website at www.soundagile.com

Business Agility Requires Transforming Your PMO and Annual Planning Cycles

As a leader as you think about everything that needs to happen for your organization to be and remain competitive in a world that now has the ability to change direction in a moment’s notice, you likely aren’t thinking that Agile is what you need.

You are however thinking about things that equate to Agility.
One of the primary places you need and want to have Agility is in your Technology investment. Yet, that is one area that rarely changes when we think about being agile or developing agility.

To build a foundation for business agility you MUST change several things:
1. Annual Planning cycles must be replaced by continuous planning that does not focus on large project funding for long periods of time.
2. Funding must move from projects to supporting stable long-standing teams. Work must flow to your teams.
3. Plan by Value not by Cost by developing a Portfolio Valuation Model that forms the basis for your Intake model.
4. Develop an Investment mindset.
5. Develop an Innovation mindset that focuses on identifying ideas that can be developed in smaller value components allowing for better management of costs and risks associated with your technology investments.

You can’t develop a high level of business agility by maintaining the status quo on your funding and annual planning cycles.

Agility requires that we work in smaller increments of work that is strategically aligned to value and flows to teams in a consistent manner.

Expecting to develop Agility with large projects funded by annual planning cycles is an approach that many organizations still take, leading to frustration across the entire organization as your planning and delivery capabilities are mis-aligned.

If you want to learn more about how SoundAgile can help you transform the way that you flow work to your teams then connect with us at www.soundagile.com

Predictability in Agile isn't Bad, Just Really Misunderstood

As a business leader I have a lot of pressure to deliver consistent results as there are people who rely on my business for their livelihood, customers want to have predictable quality in the products they purchase and investors who make decisions to invest based upon the expectation of predictable financial results, the key work here is predictable.

In Agile if I speak about needing predictability from teams, I get strong pushback. There are of course reasons for that as most technology projects start with fixed date and scope and then are expected to deliver, because as a Business Leader I need predictability.

Leadership who is typically removed from the day-to-day work of technology teams expects the same commitment to predictable results that they are held to. Leaders who don’t deliver don’t stay Leaders for very long.

For technology teams to not be expected to have some level of predictability to their work is something that doesn’t resonate with leadership. In many ways they see Agile as a way to not make commitments or be held accountable in the same way they are.

The problem comes from where each group is coming from.

The leader seeks to tell their customers, investors, etc…concretely something that will occur in the future. Future sales, new product features, improved cost savings, etc.. are what these personas seek. The stock price for companies is based upon the future looking as predictable as it does today, investors HATE surprises.

To solve this problem, traditional project management was brought into the realm of software development and applied with the expectation that software development was as predictable as the construction industry, it's not.

Agile sought to address this misalignment by focusing on technical excellence (XP) and improving the way business and technology work together (Agile Manifesto).

Unfortunately, the key changes that must occur in an organization, which is the tight alignment of customer, business and technology have largely remained the unchanged.

What needs to change is that how work is defined and delivered which is aligned to value and broken down in small valuable increments that can be delivered. Leadership cannot expect large transformative projects that take months and months to complete to be managed without any risk or changes in direction, it’s just not realistic.

Where we need to focus then is building strong and stable teams who can deliver work predictably whether they are working on a POC to review with leadership, new features for our customers or implementing new systems that manage the business more effectively, everyone in the organization requires both predictability and accountability, two things that create a strong business and trusted relationships across the organization.

For Leaders put it in this perspective — Is it more valuable to deliver a $3 million dollar 18 month and not know if the value you seek will be delivered? Or is it more valuable to deliver a sub-set of capability for $300k in 3 months that delivers 70% of the entire value of the $3 million dollar project. Do you really want to spend another $2.7 million to deliver the rest of the 30% in value?

This is the value proposition that is essentially missed in Agile at the leadership level.

Defining and Aligning Value

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 bala­nce 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.

Why you need to have an Investment Mindset to Manage Your Product Development Intake

If your organization is like most, you have an annual planning process where your functional leaders come up with things they think are important to do and then provide a cost estimate to your PMO, ­then you are not having the right conversation in your planning process, nor are you making an informed decision as to whether these disparate projects have strategic value.

In the worst-case scenario, you have two different groups working on opposing efforts or they may both be working on the same capability, meaning you have doubled your cost for the same capability (at a minimum).

By focusing only on cost, you are missing the key aspect of your investment in your software and product capabilities that support and drive your organization. 

To ensure that you are building real long-term value you need to develop a value-based investment mindset that incorporates expected value (outcomes), cost, and risk associated with an anticipated investment.

My valuation model translates your organizational strategies into value scores that are associated with quantifiable outcomes.

When an idea is submitted, it is accompanied by a lean business case and a value score.  The value score defines the outcomes at the outset of any planning.

It allows for healthy conversation in the Intake stage as to whether or not the idea should even be considered, value score aside.

You have limited investment dollars for your software/product development and you cannot waste them on work that is not valuable or aligned to strategic outcomes. 

In truth, your software is filled with features and capabilities that are rarely or ever used.  Keeping people busy working on things that have no value is not any fun from a technology perspective and it fills your code base with significant tech debt since many of these unneeded features were part of a project plan associated with unrealistic dates. 

Moving to an investment mindset also gets you thinking about the flow of work to teams over the project and date-driven work that is already decided upfront.  Developing a consistent flow of work for your teams is one of the single most important steps you take to develop mature agility.

Additionally, by taking an investment approach you allow for investments to be stopped, just as you might drop a stock from your portfolio if it isn’t performing to your risk/return profile. 

You would do well to adopt the investment maxim that I was taught, have a sell trigger as soon as a stock price drops below a certain threshold, meaning don’t hold onto bad investments to the point they have no value.

What this means from an agility perspective, is that you have the power to stop investing in an idea if you discover that the cost or the efficacy of the idea won’t deliver the value you had expected.  In your waterfall project approach, you would be forced to continue the project even if you had realized it wasn’t going to deliver what was expected.

If you would like to learn more about my Portfolio Valuation Model connect with me at michael@soundagle.

Developing an LPM defined by Value and not Cost of Delay

The Agile Manifesto states ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’

The problem is that most organizations haven’t defined what value is and they aren’t set up to deliver it continuously.

To do both we need a way to translate our strategies and objectives so that it provides consistent and relatable outcomes for our customers.  Creating a consistent flow of valuable work via continuous intake is the way we need to work, your teams won’t be effective in another setting.

By not doing this we do what many organizations do and pursue features and capabilities that an individual customer might pay for (or someone internally thinks might be valuable), which tend not to be aligned to product strategies that move us materially forward.

The only way to enable all of this is to have a strategically aligned Portfolio Valuation Intake model that results in a consistent valuation of initiatives, features, and capabilities flowing to your teams.

SAFe’s Lean Portfolio Management approach is a good start, but there is a limitation with using the Weighted Shortest Job First method as it focuses on the cost of delay over value delivered as its method for prioritization.  My Portfolio Valuation model is designed to integrate with SAFe or any other Program Intake process you may currently have.

We want to move away from a focus on cost and change to an investment mindset that causes us to define the organization's risk and return profile for the work that delivers defined value via ROI.

Look for me at the Enterprise Agility World conference where I’ll be talking about the importance of moving to a value-based investment approach to your Product Development efforts.

In the meantime, if interested ping me via Linked In or michael@soundagile.com

How Are Belief Mindset Affects Change

Change is easy, said no one ever.

Change is hard because we all have an established belief structure or perseverance that shapes and molds how we think about what we do, how we do it, and when we do it.

Belief structures are important because they provide the platform of our life and much of the success we experience from it.

When you start to think about changing how an organization operates you are talking about taking on the belief perseverance of every single person in your organization. They operate your organization and they have beliefs about what is right for the organization and more importantly what benefits they obtain from those beliefs, ie promotions, high levels of influence, etc…what we often call What’s In It For Me (WIIFEMe)

As a leader, if you want to move your organization to become more ‘agile’, then you must understand that the process of becoming more agile, starts first with clearly understanding how your organization operates today, what drives decisions being made, how are things funded, who owns decision making, the list goes on.

You need to make this effort because it is understanding how you operate today with all of the inherent beliefs that support this way of working, that lays the foundation for understanding where you need to change people’s belief structure or mindset. You need to get them to replace their current belief with new more agile ways of thinking and working, which will become their new belief perseverance.

When we talk about getting to a new normal, what we mean is that our organization has new belief perseverance towards agility and not towards previous ways of working.

Agile as it’s sold today is focused mostly on changing the way that we develop and deliver software, however for Agility to truly emerge as your organizations’ culture, then it must be viewed as a systemic organizational change.

You can’t empower teams to be accountable for defining how they work if you don’t address the belief structure that your managers have been instilled with.

For example, I have noted when I have been in leadership roles, that both my manager/leader and my peers viewed the empowerment of my teams as a source of weakness, even though those people and teams vastly outperformed those who were managed by more traditional managers who made all decisions and hoarded ideas as their own.

Holding on to my belief perseverance even though I was viewed as a weaker leader, was challenging and frankly caused me to leave those organizations in the end. We all lose in this situation.

Change is not easy and if you don’t address it as a formal change management effort and if you don’t explain to everyone Why this change is happening, Why it is necessary and How you can support the change, then you can’t expect to change your organizations’ belief perseverance towards away from keeping everything status quo.

Should Agile Reduce the Cost of Development? (Spoiler, the answer is No)

On a recent thread I had started, on Linked In, the conversation turned to whether or not organizations should expect to see a reduction in the cost of their development when they ‘go agile’.

To be clear, Agile frameworks and Agile delivery aren’t about reducing the cost of your development costs, and if that is your goal, then the best way to do that is to stop funding as many projects. Fewer projects will directly reduce your cost of development.

If however,  you are looking to maximize your investment in your software development, then Agile is how you can do that. But don’t expect Agile frameworks to be the sole vehicle do to that.

Frameworks organize work that teams will be taking on, however, if that work is mapped out in a large project orientation, then all you are doing is delivering waterfall in smaller increments.

Instead for you to maximize your development costs you must do two things well:

·        Prioritize by value (strategically aligned with OKR’s)

·        Become engaged more often (via regular reviews)

Again Agile frameworks only get you so far in most of this, and the agile frameworks and community has done a poor job in helping figure out what value means and how to prioritize by it.

The value of what your teams work on will emanate from your organizations’ strategic goals and objectives. Too often I see teams working on things that they are not necessarily sure are the most valuable to the organization, but when left in a feedback void, they will do what they think best. 

Generating a value model is an important first step in value identification (more on this soon). Valuable ideas can and should come from anywhere in the organization. When ideas are submitted you need a quick and easy way to identify value (with a value score) to provide input into your overall portfolio of work.

Having a value-based roadmap of work ensures everyone has transparency to what teams will be working on. This process also provides a smooth flow of work to our teams, which will increase quality and productivity.

The second part of maximizing your development costs surrounds being actively engaged in reviewing what your teams are delivering. This is not about being fed a status report, this is about you the leader sitting in on sprint reviews and seeing the working software as it’s delivered. 

What’s the goal of this? To STOP working on something, when you see either the team has delivered enough to meet your needs today OR the team delivered something that isn’t what you had in mind, which will cause you to go back to create a new hypothesis, or ditch the idea completely.

The objective is a lean concept, there is value in work not done.

In one organization where I worked, we had a large initiative that our leadership wanted us to take on. We broke it out into three phases, with the most important elements being taken into our first set of sprints. Because our leadership was engaged when we delivered during the first phase (MVP), when we were done, they said ‘this is good enough, we have another more pressing need for the team to take on’.

In your waterfall world, two things would have happened if you decided to stop this project (which is your only option) in favor of another one.

• Nothing in the first project would be released, which means no financial benefits (CapEx/OpEx) happening.

• The code from the first project is in the codebase and is now causing bloat and tech debt that will slow down the team(s) long-term.

Working in an engaged Agile environment is what will maximize your development investment.

The goal of agility is about value and speed, not reducing costs.

Product Or Capability Teams?

One of the most important decisions you make as you reshape your organization to support agility is establishing what we commonly call Product teams and it’s one of the least understood.

Some organizations I have coached Products were defined more along the lines of enhancements to something that already existed or was so large as to be meaningless.

 In the former, if you create a team for a short-term enhancement then by definition you won’t be creating a long-standing team, they will get funded for the project enhancement and then disbanded.

Conversely, defining a Product as your website misses the mark because you would not typically have a single Product team responsible for an entire website.

The challenge you will face with organizing Product teams for the short term is that you won’t realize the underlying value that dedicated long-standing teams will provide you in terms of productivity, quality, and employee engagement.

As you begin to reshape your organization around agility, there are two key decisions to be made:

• Changing Your Funding Model – Move from funding Projects to Teams

• Determine Your Long-Standing Teams – Move from people moving to projects to people on stable teams.

The standard guidance you will receive from Agile coaches is that you have to create Product teams.  The problem with this is that for most of us our mindset for a product is that which we purchase something: A car, an iPhone, a Waffle Iron, etc…

Unfortunately, most organizations don’t produce a ‘product’ from that mindset, instead, they have long-standing business capabilities that support their business operations.

I’m suggesting that as you move to create dedicated teams that you focus on a business capability mindset over a Product one.

What is a capability?  Think Accounts Payable/Receivable as an easy example.  Your organization from its inception has had a business need for Account Payable and Receivable activities.  When you were small perhaps Quickbooks sufficed to support this operation but as you grew larger and larger the application that supported this may have changed but the capability to pay our vendors and receive cash from our customers is unchanged.

A Capability that supports the ongoing enhancement, support, and growth of our Accounts Payable and Receivable business capability is where you will create a dedicated team.

The best way to create a model of how you will align your teams is to generate an Enterprise Business Capability model, which will define your highest level business capabilities, down to the business functions that support your daily operations. 

If you align your teams at the wrong level you may not have a strong strategically aligned operational team.  Obtaining a continuous flow of work, removed from your annual funding cycle are your goals for attaining high levels of business agility.

Avoid the more common way that teams are aligned, which is via the underlying applications that support your capabilities.  Aligning by systems and not capabilities ensures that we focus more on the health of the systems and not what is needed by the business. 

In one organization the technology leader became so focused on the technology they were using for a new product we were developing that they never delivered anything for the customer.  When they canceled the contract the manager told me, ‘if they only could see all of the cool technology we are using’… to which I said they don’t care, we didn’t deliver what they needed now.

As you seek to remain competitive in our ever-changing world, agility is something that will help you, however, done poorly it will slow you down.  Focus on building teams around capabilities, and don’t worry about what ‘product’ they are supporting.

Transparency, Accountability, and Predictability - A Trust-based approach to Adopting Agility

These are the three pillars that I believe are the foundation to creating a successful Agile organization.  So much so that I’ve created an approach called TAP2 Change.

Each pillar supports the other and without developing all three pillars your ability to become an Agile organization will have only marginal success.

But what do we mean by ‘becoming Agile?

The Agile Manifesto was expressly about improving how we developed software, and though it highlights the need for high levels of business and technology engagement, it has a gaping hole in it that has left it hobbled and unable to realize the full benefit of being Agile, which is that the entire organization must change to support the Manifesto.

Being Agile is a state when your organization no longer thinks or acts in the previous way that you work, rather Agile is your new state of operations.  Unfortunately, Agile has been sold as a silver bullet, a product that will solve ALL of your organizations' problems and all you have to do is bring in a cadre of coaches and viola! your organization is Agile.

In any organization, we are always looking for better ways of working, Agile is just a new ‘better’ way of potentially working.  Just like your waterfall days, you will always be attempting to make Agile better.

But what is interesting is that virtually all organizations that grew up with Waterfall have their entire organization optimized to run in Waterfall.  Yet Agile has stayed almost entirely within the domain of Technology. 

You are asking for your organization to deliver more quickly, yet you don’t optimize your organization to support that.  As you start your Agile journey, you must consider the organization holistically, which is what TAP2 Change does.

This is why Agility requires you to build three pillars - Transparency, Accountability, and Predictability. 

These pillars have nothing to do with the frameworks that have grown up to ‘operationalize’ Agile, they can support the pillars if that is your choice, but they are not the entirety of what Agile must be if you are to have long-lasting transformative success.

TAP2 Change is designed to provide you with guidance, not directives, on how you can approach becoming Agile.  At every organization I’ve been at, we talk about how we are different from other organizations, and you are entirely correct and to think there is a single framework that will work as-is is not being realistic.

As a coach, I have had much success in helping organizations become more Agile, yet each one had its unique aspects that required that I tailor what we did to accomplish Agility.  And what worked at one organization may not work in another, being flexible in how you define Agility is the key to success. 

Again it’s not about the frameworks, at best they provide you a veneer or window dressing of ‘doing agile (note the small a) if Agile is a mindset then right now our mindsets are centered around Scrum, SAFe, LeSS, DAD, the list goes on. 

Though I will be writing in more depth on what each Pillar is all about at a high level here are the three pillars you need to develop as part of becoming Agile:

• Transparency –

  • This starts at the top, with leadership providing a clear understanding to people why becoming an Agile organization is important, what are the threats to us if we don’t become Agile, what are some of the expected changes that need to happen to support Agile (both organizationally and personally).

  • Conveying how can everyone in the organization both participate and also succeed in this new operational paradigm is another transparent layer of successful Agility.

  • Creating a clear Agility Mission and Vision and making it transparent will create the north start for everyone as they begin to ask the important question, how can I contribute to our collective success.

• Accountability –

  • Here is where we start to see the real aspects of the operational side of Agile.  And again it starts at the top.  Leadership can’t what I call a ‘fund it and forget it’ approach to this adoption, they too must change how they lead, manage and think about their organization. 

  • As a leader you are accountable for the success of Agility, you can’t outsource change to outside consultants (we can help but we aren’t the real change agents despite what everyone may think).

  • Planning and delivery comprise a large part of Accountability, which touches every part of the organization and top to bottom.  You can’t be Agile if the only thing that changes is that you deliver your waterfall projects in 2-3 week sprints.  Your organization must change everything from Ideation, Intake, Planning, Funding, Operations, and Staffing to support organizational Agility. Absolutely nothing is untouched by Agility if you are doing this right.

  • Empowering people at the lowest levels of the organization leads to high levels of accountability, building trust is the single most important part of the accountability pillar.

• Predictability –

  • This is the most controversial pillar of the three because Agilists see predictability as a means to continue to have projects that are fixed scope and time.  Yes, this happens in many Agile organizations, this is not what I mean by being predictable.

  • It is important that we not ignore every organization's need to deliver predictable results, whether they are a public or private entity.  Leaders are the public face of our organization and when they provide feedback or guidance on how or where the organization is going, investors and customers alike, are listening.

  • Predictability is the final pillar of TAP2 Change and the real focus of this is to optimize our Product Development teams to deliver consistently,  What this means operationally is that in an Agile organization there are no fixed scope/date projects.  Rather there is a Product Roadmap that provides visibility into small incremental improvements to that which we are working on, be it a brand new product or an existing one. 

  • Leadership with a high level of engagement can see progress (transparency) and know that their teams are being accountable (accountability) for delivering incremental value consistently (predictability).

One of the most important aspects of Agile is that it changes your entire organization, whether you want it to or not, eventually, the pain of living in the multiverse of Waterfall and Agile, will become too painful.  You will more than likely in this scenario go back to Waterfall, as the path of least resistance.

Because Agile is an organizational change, you must build trust with everyone involved.  And you must provide transparency to everyone in your organization regarding what, why, and how Agile will change their work.  Without this, you will not be able to convince people to change and Belief Perseverance (which we often mislabel as resistance) will be what keeps you from achieving your goal of moving you to Agile.