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.

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.

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.

The Neuroscience of Agile

Over the past year, my interest in neuroscience has grown and one of the interesting things that have come out of my learning is that the brain, as it turns out, spends quite a bit of energy thinking (subconsciously) about what might happen in the next moments in time. 

Historically it had been thought that the brain reacted to stimuli and then formulated a response (think fight or flight).  But the brain is much more active in its planning whether or not we will need that type of response. Our brain is constantly evaluating what we are doing at the moment and trying to predict what our response will need to be in the upcoming moments.

That implies that our brains are tuned to short-range planning, so it should not be surprising that humans are not all that good at predicting what will happen further in the future. 

That’s not to say our brain doesn’t look at what has transpired historically and provides us an ability to guess what the future of something might be, but ultimately we simply aren’t wired for success in long-term predictive planning.

So given our brain is good at predicting what will happen in the very near term, I find it interesting that software development processes evolved over the years to encourage long-term planning, asking people to say today what they will do 6 months from now, especially given all of the unknown variables that exist in complex software development work.

At best we are guessing about what we will need to do 6 months into a 12-month project.  The brain simply isn’t set up for the successful long-range planning that Waterfall requires because we can’t anticipate what might happen as it is too far out into the future.

I suppose all of the Waterfall gates and approvals are designed to provide us some level of comfort or false confidence against the unknowns we accept as a risk to our projects.

Software development is a complex thing, you are asking people to develop in or on top of a complex environment where everything can’t be known upfront and the human brain no matter how much you try to plan for the future, really must be focused mostly on the more current aspects of their project, eg - what am I doing today and tomorrow and at most next week.  Sound familiar?  Short incremental development cycles followed with an inspect and adapt check-in?

So if our brains have developed to be very good at short-term planning why would we not want to adopt Agile as a way to deliver our software development efforts?

Agile aligns to a natural strength, short-term planning with fast feedback loops, which provide us an ability to react and respond to what we are seeing and learning. 

Those fast feedback loops inform everyone as to what just happened and what is about to happen so that if needed, we can react and change our course.  Our brains are set up for this type of behavior. Asking us to plan tasks months in advance is asking for failure on multiple levels, be it productivity, quality, context, or value.

As you either consider adopting Agile or making your current effort more successful, spend a good amount of time redesigning your planning process top to bottom, to support a short-term planning cycle.  You will find everyone more supportive (and happy) of working this way and you will see more value being delivered.

To learn how you can be better at Agile contact me at Michael@soundagile.com

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. 

Why Your Organization Needs an Agilitst as Your Coach

I’ve been working through some things in my recent engagements, one where I worked with some awesome coaches and another where coaches were not deeply experienced with Agile.

The differences in the success of implementation were fairly stark, with one having highly engaged coaches working collaboratively to refine the challenges with the organization’s framework, making thoughtful changes that moved the organization forward while keeping the intent and outcomes in place.

The other was disjointed and fragmented with the focus on the framework being right and attempting to fit the framework into the organization over the other way around. The coaches in this situation were rigid in their belief that the framework is implemented as defined by the framework, which is a circularly blind logic that completely leaves out the organization in the approach.

This got me thinking about Agile and how I view it based upon almost 20 years of working in Agile, primarily as someone involved in developing and delivering software products and more recently in the past 7 years as an Enterprise coach.

From my perspective, I see 3 aspects of what many think of when they hear the word Agile.

1. Agile Manifesto — This is the base for the Agile movement across the world. It laid the foundation for how we want to approach working via its 4 Values and 12 Principles. Within these, we find the foundations for how we want to work which has resulted in the development of a myriad of frameworks designed to take the Manifesto and ‘operationalize’ it for people to work within.

2. Agile Frameworks — These come in all flavors and often have ardent followers who often believe that the Framework rules everything we do. Where the Manifesto was not prescriptive the frameworks often are or are implemented from that perspective. This rigidity of implementation stems I think primarily from the certification factories that have been turning out certified Scrum Master, Product Owners, Release Train Engineers, so on and so on….

The danger with the certification process is that implies to unsuspecting hiring companies that these people have some deep understanding of ‘x’ framework and this couldn’t be further from the truth.

Worse many coaches in our industry have gone out and paid for a bunch of certifications yet have zero experience working in Agile and can not provide any supportive coaching regarding implementation of the framework due to this glaring knowledge gap.

Unfortunately, the demand for Agile coaches to support Agile Transformations is high and continues that way, in order to hire coaches organizations will check the box for certifications and move forward, with often disastrous results.

A critical danger that organizations who want to move to Agile face are that if you get it wrong by hiring people with no Agile experience you are not likely to be successful resulting in leadership blaming Agile but in reality, it is the people hired to help you be Agile who are at fault. You often have one shot at gaining confidence in Agile.

3. Agilist — These are the more rare individual in the Agile world, those who have both worked in Agile in often many different roles and then have gone on to coaching. My background includes having been a Scrum Master (before certifications were a thing), Product Owner, Tester, Agile Evangelist within the organization to leading a Transformation organization.

It is these real-world experiences that you want your coach to have as they take the approach of understanding your organization and then applying the appropriate approach for that moment in time.

Agilsts are not tied to a specific framework and we look at them as things we can leverage as part of the overarching goal of helping the entire organization become Agile, not just adopt Scrum, which is focused solely at the development team level.

I often describe my approach as that of being a chef with lots of spices (frameworks) and picking the parts of each that make the most sense for where the organization is at. Trying to implement SAFe into a free-spirited startup will likely fail, but if you hire SAFe certified coaches they will come in and implement SAFe. Their hammer is SAFe and every organization looks like a nail to them.

Agilsts question everything and seek new ways of working that provide the right context and direction for the organization to be successful.

If you are thinking about starting an Agile Transformation these are things you need to consider. Seek Agile coaches who can provide real-world examples of how they both challenged the organization in their thinking and helped them see new ways of working that lead to successful outcomes.

Coaches who are Agilists will often have the certifications as they open doors for us, but they are not the driver of how we think of how an organization can become truly Agile. Simply selecting a Framework and adopting that gets you only so far in the goal of changing the organization to a new normal.

Agile Your Way

My experience with Agile stretches back almost 20 years when a healthcare organization I worked for asked me to take on a new product development effort that was languishing. When meeting with the developers they asked me if I’d support them doing the project in Scrum. Not being familiar with it I did some reading and came back and said I’d do it.

And this was how many of us started in Agile, people taking the leap and then figuring it out. Funny thing, during this time there were no coaches.

Instead, we were forced to work with each other to figure out what our ‘Agile’ was going to look like. And here’s the thing, there is no ONE way to do Agile. You did what worked and if it worked then you were Agile enough and kept changing when needed.

Coaching came later and with it the industry that we have now. Lost in all of the talk involving frameworks has been the concept that each organization is different and what Agile will become for them needs to adjust or adapt to the organization and not vice versa.

Instead, Agile Transformations rely almost entirely on the implementation of specific frameworks and then telling the organization they have to adapt to what the framework expects. The frameworks assume that your organization perfectly fits into their framework and no company I’ve worked for yet has that been the case. 

You have to apply the framework based upon the intended outcomes the framework seeks and not implement it ‘out of the box’ in my experience.

Don’t get me wrong I’ve been involved with many organizations where we have implemented something out of the box and it’s not that we can’t deliver value, but the inherent imbalance of where the organization is at and what the framework expects keeps us from reaching higher levels of matutity.

Another reality not talked about much, is that is possible to be successful in managing a transformation on your own. Two of the most successful Agile organizations I’ve worked in (not as a coach) were led by the people in the organization, we just started and got to work asking a simple question – Is what we are doing Agile? If not what needs to change? 

Was it easy? No, but what change is? Could we have used some help? Sure, but we couldn’t afford a multi-million dollar transformation led by coaches.

It was these experiences in mind that I helped create the Agile Learning Journey, a complete package of E-learning content, developed based upon my years of experience in working in Agile. 

Agile Learning Journey provides coaching for your leadership down to the teams that will be working in Agile but does so in a way that points you lays a foundation of knowledge that would have been helpful all those years ago when I started working in Agile.

In addition to the reach experience you will find in our learning modules, we also provide you with boot camp training material, templates, and a myriad of other support elements to help you launch your Transformation successfully.

We can help you move to an Agile operating model at a fraction of the cost of bringing on full-time coaches, who often have little of that real-world experience I’ve developed over the years.

This is an important distinction because coaches who haven’t been involved in working in Agile will in the end tell you how the framework is supposed to work, but have little real experience making it work. 

This is where my experience brings life to our product. I’ve worked through the challenges of how to align change to action for people and organizations.

If you are interested in learning more please visit us at agileprocoaching.com or connect with me directly at michael@agileprocoaching.com. 

Organizational Zones of Antagonism

Recently my family and I were watching a worldwide bio-diversity seminar online and during one of the segments on Lichen’s (yes it was fascinating) the presenter talked about how Lichens grow and they formed what she called Zones of Antagonism as they looked for more food which allowed them to grow bigger.

The Zone of Antagonism formed a barrier around their space and would ward off any encroachment from another competing Lichen organism for their food source.

This concept immediately got me thinking about how organizations often operate with zones of antagonism as well.  We see and deal with them all of the time though we often refer to it as the politics of an organization.

People, due to the siloed design of their organizations' processes, often form what might look like zones of antagonism around their functional area.  These manifest themselves in many ways but are often revealed when an organization goes through any type of change management, such as an Agile Transformation.

Change forms a threat to the status quo, to the power bases built up with the current structure of the organization.  Power influences outcomes and outcomes drive behaviors.  Tell me how someone is incented and we can tell you how you are likely to behave.

We reward success, but which also means that there is a loser.  Much like the Lichen looking to compete for food, people often look to influence or consolidate power as much as they can when working within an organization.  We have been taught that to move up in an organization implies high levels of authority, influence, and compensation, so these are the drivers for what we see when we pull on the levers of change.

What we as change agents might refer to as resistance might also be called zones of antagonism instead.  It’s not that people are resisting as much as they are protecting against either something they know to be a real threat to their current state or something they fear due to a high level of unknowns.

As an Agile coach, we need to put ourselves in the place of the individuals we are coaching and ask if the organization has made clear the vision of why Agile is the way to go and what the organization and the people within it will get out of supporting the move to it?

If leadership for an organization has not made clear the game plan for engaging in change, Agile or otherwise, then people, much like Lichen will respond by establishing their zones of antagonism as a way to delay, thwart or even kill the transformation overall. 

We know resistance to change is real, however before condemning the resistance seek to understand it first.  It’s this step that starts the real work to remove the zones of antagonism in an organization that will cause the value you seek.

Too often as coaches, we are transactionally hired to come in and teach Scrum, SAFe, or any of the other myriad of frameworks used to ‘implement’ Agile. 

The problem is that the frameworks won’t make you Agile, only the mindset of change combined with the vehicle (frameworks) can move you from simply going through the motions and ‘Doing Agile’ to the place we want to be of ‘Being Agile’, where operate in a new normal.

TAP2 Change - Building an Agile Organization via the Pillars of Transparency, Accountability and Predictability

I’ve been involved with Agile for almost 15 years in all manner of roles and organizations. Some of the Agile efforts I’ve been involved with could be counted as a success, some not so much. 

The organizations that I’ve been involved with, which had successful transformations, had a few key behaviors they exhibited, which included:

1.     A willingness to be vulnerable regarding what wasn’t right about how the organization. These organizations weren't afraid to discuss what wasn't working and make decisions about what needed to be done at the Leadership level.

2.     Active engagement from the organization’s leadership and a willingness to experiment and fail along the way towards mature and effective agile processes.

3.     An ability to provide people and teams the space to become self-organizing and empowered to define how best to work within in the context of being Agile.

As I've moved through the Agile experience I've identified a way to approach an 'Agile Transformation' from a different perspective. Too often our focus is only on the frameworks that have grown up to support the implementation of Agile, such as Scrum, Kanban, SAFe, xP and a myriad of others. These frameworks focus on how teams operate and are concerned mostly about the flow of work to teams. This is only part of the equation.

Based upon my experiences I've created a framework that is holistically focused on changing the entire organization not just the software development capability.

I call the approach TAP2 Change

TAP2 Change focuses on developing three key pillars necessary for a successful Agile transformation:

1.     Transparency

2.     Accountability

3.     Predictability

Transparency –

This pillar is about defining many of the missing pieces of most Agile Transformations, most importantly identifying why the organization wants to move too Agile.

Agile shines a light on all of your organization’s inefficiencies and asks one simple question – What you are going to do about it? 

Something we don’t tell organizations trying to be Agile is that Agile doesn’t fix anything, it’s not a framework, or a process, so it can't 'deliver' anything for you. What it is, is a mindset which asks you to challenge your current belief structures held within your organization and then start the process of re-envisioning your organization.

Transparency starts at the top where we challenge Leadership to:

1.     Define a clear vision and strategy conveying to the organization why you want to do this and what you expect to have as an outcome as you transition to Agile. Tell people the important part of change - ‘What’s In It For Me’

2.     Reassess how they view their value streams or develop them if they don’t exist. This will challenge long-held beliefs about what is valuable to the organization and will result in a brand new way of thinking about your business.

3.     Redefine your products and capabilities within the context of your value streams. This again will challenge beliefs about where your organizational value resides. 

4.     Engage people from all levels of the organization as you build out your Agile Transformation strategy, ivory tower approaches need not apply. Agile is a ground game that needs input from everyone in the organization so it doesn’t appear that this is being something done to them but with them.

5.     Completely change the way you look at how you finance your software development projects, moving from Project to Team-based funding.

Your Transparency Pillar will be the most difficult and will take the most time because if you can’t be transparent about what outcomes you are seeking and the ways that your organization must change to get them, then you will not realize the full value of going Agile.

Instead, you’ll be like the myriad of organizations who reach the state of Doing Agile and never move past this state or worse regress when leadership declares they are Agile and stops supporting it.

Accountability –

Accountability is an important element in any Agile Transformation however much of our efforts in rolling out Agile to the organization avoid organizational and team accountability.

When we talk about Accountability we are talking about several elements:

1.     Organizational Accountability – Leadership is accountable for defining an Agile Transformation strategy and roadmap and ensuring that they both communicate and regularly update the organization on how they are doing. Leadership is also accountable for ensuring that they support the change and don’t simply fund the initiative and forget about their part in this significant culture change that they must lead.

2.     Team Accountability – As Product Development teams begin operating in whatever framework that they will be using, they are accountable to the organization to engage positively and seek to continually grow in the maturity and capability of that framework. Too often Leadership views Agile as a way for software development teams to not be accountable for their work and show progress in delivering on important features and functionality. This is not the case, but how we view accountability is not about hitting fixed dates and scope but rather being accountable with respect to our Transparency so that Leadership is informed with facts about how we are progressing and can then more clearly understand the issues with attempting to create features in a highly complex environment.

Leadership is accountable to teams to be engaged in assessing what value we they are delivering and making fact based decisions on what is needed not what was wanted.

Predictability –

Predictability is ultimately what Leaders are looking for, they have to make commitments to customers and shareholders with respect to value that they expect to deliver. Not all organizations have the luxury to continually develop and deliver new features and enhancements such as Amazon or Google can, the reasons are many but they are real.

This pillar however, just as with the Accountability Pillar, is not about a team marching towards a fixed date/fixed scope effort. Rather Predictability is about understanding the capacity of individual teams and the entire organization and identifying the minimal amount of work that will deliver the most value in the shortest time.

We view Predictability not within the context of scope but with cadence, be it story points, # of stories, or whatever metric you use to identify how much work can be completed within a specified amount of time.

To ignore our need to show progress, even if the progress shows that we are hitting challenges, provides important fast feedback to Leadership so that they can make informed decisions and manage expectations of customers earlier than waterfall would ever allow.

You can build out one or more of the Pillars, but it is the strength of all three that will provide you with a strong foundation for building a successful Agile Transformation.

To learn more about our process you can reach me at michael@soundagile.com or go to www.soundagile.com

Also - Coming Soon - Look for my book - TAP2 Change Building an Agile Organization via the Pillars of Transparency, Accountability, and Predictability.

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.

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.

Currency for Change – Transformation Needs and Roadblocks

change-1-1563676-640x480

Business leaders, those who run our organizations, continually look for strategies that deliver growth, synergy, profit and increased market share, to name a few.  They are judged and compensated based upon their ability to deliver results around financial or operational focal points.  Those leaders who manage a publicly traded company take on the added burden of providing predictable quarterly results year after year in order ensure a stable and growing stock price.

Many times new strategies require changes to your organization.  When attempting transformative organizational change, our focus is on changing the way that an organization operates at an organic level.  However our Leadership is rarely focused at this level, rather their focus is on the expected benefits of the desired change. They often fail to address the real organic element necessary for change, which are the very people who help manage and run their organization.  People will determine the final success or failure of any particular change management effort.

Change, the type that transforms an organization is often done so out of perceived need or stress event, such as new competitor or competitive products or disruptive technology.  Though the stress/threat may be very real to the survival of the organization.  Though the threat may be real the people working for the organization may not necessarily be motivated by changing how they work in order to respond to the perceived threat.  The reasons for this can be:

• We may not be connected to the threat in a real way, we don’t see how the threat impacts our job.

• We may not agree that the threat is real.

• We may not agree with or believe that the requested changes are the right approach or strategy.

• We simply may not care.

We are ultimately are creatures of habit, what worked in the past should work for us in the future, we come to expect outcomes based upon these past experiences.

Our natural world provides us with examples of how change is handled when stress is applied.  In nature change is a natural state and happens without negotiation, let me repeat that:

Change happens without negotiation.

Trees don’t talk to hills to see if they are ok that more trees are grown, the change happens naturally based upon the need of the environment not the want of the trees.  Organic change happens in reaction to a stress event and then the system responds by initiating change that provides the appropriate reaction in order to bring the system back into a steady state.  In this example there is no currency for change between actors in the system as the system operates in a manner which brings the system back into a static or healthy state without applying change management techniques to encourage adoption of the change.

Large human systems are unlike our natural counterpart on multiple levels, primarily due to the people who are the actors of the system.  Natural systems form a comprehensive whole were all of the sub systems work in synergy on a grand scale.  Human systems however don’t share this synergistic behavior and as such operate independently of each other and the stress of one organization may not have any association or perceived dependency with another organization.

When human organizations inject change into their system in response to a perceived threat they trigger a broad set of activities at impact people in that system.  Change in both our natural world and our organizational world has the primary goal of keeping the system healthy and strong, but whereas the natural system accepts change without negotiation the human system involves potentially significant negotiation which has the negative effect of diluting the positive impacts the desired changes are expected to deliver.

Why is this?  Much of it surrounds not taking the time to communicate WHY the change is necessary and understanding the currency of our organization to accept the change.

What is Currency for Change?  It is the perceived value that an individual will derive by participating in change.

Human systems require people to participate in change.  However in order to get them to fully engage in the change process we need to communicate WIIFME or What’s In It For ME?

Change requires that the people in your organization do some of the following:

1. Learn new things (software, processes, tools, etc..)

2. Take on new roles (Project Manager to Scrum Master)

3. Report to new people

4. Change the way that they manage

5. Change the way that the project manage

6. Change the way that you plan

7. Change the way they are compensated

Currency then is what an organization is willing to ‘pay’ people in their currency in order get them to actively engage in change.  Currency is individual and ultimately relates to how an individual perceives their place, influence and power within the organization, this will drive what their specific currency will be.

Currency for change relates closely with the motivational needs of employees.  For example, though we may understand why we need to exercise and eat better for a longer life we may not be motivated sufficiently to do this consistently long term unless we identify the real currency we require to make the necessary changes.

There are many different needs based theories that can help define individual currency for change:

1. Maslows’ hierarchy of needs:

   1. Physiological

   2. Safety

   3. Social

   4. Esteem

   5. Self-Actualization

   6. ERG Theory:

      1. Existence

      2. Relatedness

      3. Growth

      4. Acquired Needs Theory

         1. Need for Achievement

         2. Need for Affiliation

         3. Need for Power

         4. Three-Factor Theory for Employee Motivation

            1. Equity/Fairness

            2. Achievement

            3. Camaraderie

Parsing these different theories we come up with a few general themes:

1. People need to feel safe

2. People need to feel achievement

3. People need to be acknowledged

4. People need to feel connected to others

5. People need to learn or challenged

When we begin to craft a change management plan for our organization we need to engage in conversation that explores the currency of the people who will be engaged in the change.

When beginning the process of change we must clearly identify the Why as part of understanding and leveraging an individuals’ currency for change.  If you can’t clearly identify the why people need to change you won’t be able to develop the What and the How in order to sufficiently engage people at their motivational level which we translate into currency.

Understanding what people require in order to be incented to change, translates into currency because change doesn’t come without investment and that relates to WIIFE, what am I going to receive if I change?  And unfortunately simply staying employed may not be enough, especially with highly skilled and sought after knowledge workers, you must engage them in a much different manner and their currency won’t be continued employment or more money (typically).

What does currency look like?

1. Enagagement–

   1. Allow more control and input with respect to the change to your entire organization, don’t make it a one way street with no negotiation. Unlike our natural world where change happens without negotiation, people in your organization are the source of successful change management.

   2. Benefit – It’s doubtful that your change management team has thought of everything that is required to make the change successful. Engaging your organization to participate in building the strategic direction of the change will create strong ownership of the change.

   3. Needs Met –

      1. Need for Affiliation

      2. Social

      3. Esteem

      4. Camaraderie

1. Failure –

   1. We must understand that when we change our organization, the model by which we manage our organization also changes. Leaders and managers who have been successful in the organization are now faced with potentially dramatic changes with respect how they will manage and how they are perceived as successful.  Their very power base is threatened.  Encouraging a culture of failure as part of your change management efforts is essential for successful change.  Failure is not the goal, rather the mechanism that we use to encourage learning, because at its heart change is about learning and we all learn differently and we have different currency with respect to how we learn.

      1. Needs Met:

         1. Need to learn or be challenged.

         2. Safety

         3. Recognition –

            1. There are people in your organization who have vast experience and domain knowledge which has been vital to the success of the organization. Though these people may be the most resistant to change, they can conversely be your biggest proponents for change if approached the correct way.  These individuals often want more recognition than material things such as more money.  They fall more along the needs matrix identified by Maslow, they are looking more for Social and Physiological needs to be met but also need to feel safe during the change.

               1. Needs Met:

                  1. Safety

                  2. Acknowledgement

As you think of taking on transformational change you need to start the conversation around the needs and currencies of the people who are going to make your change management successful.

Change is hard and when not engaged properly is destined to under deliver or worse fail completely.