If Value is the Problem, What Can I Do About It?

Wednesday I published a post called "Why is Agile so Hard to Sell?". If you haven't checked out the comment thread, you should really take a look. Most of the comments were really supportive and added serious value (no pun intended) to the conversation. One comment caught my attention, not because it was negative, because it said something to the effect of "nice problem statement, now tell us what to do about it". After thinking about it, I wanted to elevate my response to more than a few lines in the blog comments.

One of the tough things about writing a blog is that you really only have 500-1000 words to make a point. Blog posts are better if they are short and get right down to business. For me, that often means that my posts don't stand alone. Sometimes I get an idea in my head and I'll noodle around on it for 5-10 separate articles. Often these will start off as an intentional series, sometimes they just end up that way.

As I look back over my writing the past few years, my content related posts tend to fall into one of two different categories.

Sometimes I am writing to help clarify a problem. Understanding that we have a problem is often half the battle. This last post on selling agile fell into that category. I am not convinced that on the whole, we all are on the same page regarding what value means and how to map team value to enterprise value. I see too many folks applying simple process to complex problems and doing some goofy stuff along the way. I am trying to figure out how to clearly communicate that something just isn't right.

Sometimes I am writing to help clarify a solution. It's not uncommon when I start out writing a series of posts, that I don't know 100% where I am going. I may have a general idea where the solutions space lives, but I am thinking it through and exploring language around how to solve it. Sometimes I know exactly how I think a problem should be solved and I am using Leading Agile, and your feedback, to help me figure out how to communicate the idea. Ideas have to be simple and resonate with the community for them to be effective.

So to answer the commenter's question directly... the solution to the value problem lies in how we go about our agile transformation. It lies in the scope of what we are able to impact. It lies in how we think about roles, and process, and artifacts... in how we give guidance to our teams and what we train them to do. It lies in project management and portfolio management. It lies in Lean, and Kanban, and Theory of Constraints. It lies in thinking less about keeping people and teams busy and more on getting products out the door. It lies in doing less instead of crowding out our highest priorities.

Many of my posts over the past year have dabbled in this space. The book that Dennis and I are writing is going to be all about applying what we know and directed right at the solution to this problem. The challenge is that the solution doesn't fit into 500 words or less... not even 1000. We are hoping to fit it into around 140,000. We have the tools at our disposal to make this work. We have the knowledge of how to focus an organization on it's highest priorities. We know how to make investments that are going to really matter. We can talk about incremental adoption and value based agile transformation and put together a roadmap for making this all happen.

So... you have several options:

1. Go back and re-read Leading Agile to see how we are thinking about this.
2. Wait for the book... where this will all be in one place... eventually.
3. Stay tuned to Leading Agile where we'll continue to explore both the problem space and solution space around this value issue

And, just so you know... this is really what the folks at Pillar and I do for a living. If you are interested in having someone help you jumpstart this process... give me a call. I'd be happy to have a phone conversation with you, we could setup a Q&A or a webinar, or come onsite to talk about the issues you are struggling with. We can help you identify some very tactical next steps that will bring attention to this problem... and how we can work together to fix it.

My team and I have some availability over the next few months, so if you are interested in talking, let me know.

Subscribe to Leading Agile

Why is Agile so Hard to Sell?

What I find incredibly interesting is why defining value is so hard. Agile proponents have been beating the value drum since the very beginning. Put the customer in the room... understand their needs... build what ever they want... deliver software in small increments... get constant feedback... converge on the optimal solution... deliver value early and often. Agile is all about delivering value. Why wouldn't a management team embrace a set of methodologies so focused on giving them what they need the most?

Here is my take...

Agile is (in large part) a reaction to misapplied waterfall development and naive application of project management principles in ways that are inconsistent with how software actually gets built. It was is a reaction to dehumanizing, process and artifact driven management approaches... processes that assumed with enough procedures, we could somehow commoditize the practice of software engineering. We wanted to take the uncertainty out of a craft that is really a blend of engineering and art. Our desire was to make everything predictable and repeatable.

We were trying to treat people like machines that could be infinitely sliced across tasks, tasks that with the right level of process and planning, with the right level of project management and oversight, would somehow magically roll up into working software that our customers would want to buy. Guys like Jefferies, Cockburn, Schwaber, and Sutherland were beginning to realize that successful projects were really the result of high-performing, committed individuals, working together in small teams, all directed toward shared outcomes.

XP, Crystal, and Scrum were born through the realization that these small empowered teams delivered the best outcomes and were the most successful over time. As these agile approaches were beginning to emerge, they all shared this disposition toward small teams, close customer interaction, and frequent delivery of value. The funny thing is that if you talk with most folks working for small companies... this is kind of what they do naturally. Folks are not assigned to a single role... you have a team of high-performing individuals working together for the sake of their collective survival. Big companies seem to have messed this up... but I digress.

Fast forward 10 or 15 years...

Now we have pockets of agile within large organizations... sometimes we might even have agile across entire large enterprises. We are exploring agile methods and trying to see if they can deliver on the small team promise... but in the large. The main difference with these larger organizations is that value isn't the same as it is in a small team or a small company. There is not a direct correlation between team performance and business outcomes... there is not a direct connection between what the team delivers and what we can sell to our customers. It takes the output of too many small teams coming together to deliver anything of value.

Agile methodologies have typically treated the team like a black box. We give them a prioritized product backlog as an input and we get valuable working software as an output. But now... we have to coordinate the output of several teams... maybe even dozens of teams... into some sort of coordinated deliverable. We are having to deal with getting tens or hundreds of people working together in a coordinated fashion. When that is our context... the message of teamwork and collaboration... close relationships between the team and the customer doesn't resonate. The only way many of these organizations can get any sense of comfort... any sense they that they are responsibly managing their part of the business... is to ask their teams to commit to the big up front plan

As an organization, we know that we need to deliver value as fast as possible. We know that we need to be able to respond to change. We know that we need to deliver with more predictability and with higher quality. We have an intuitive sense that what we are doing isn't working. We want to get benefits that agile talks about. We suspect that something like Scrum or XP can help... but we can't figure out how to apply the small team concepts to our particular business problems. That's why you get the classic "agile will never work here " comments. There is an inherent disconnect between the team level guidance agile methodologies talk about and the bigger concerns your senior executives are struggling with.

There is a gap between value at the team level and value at the enterprise level.

At the end of the day, our community needs to develop guidance that helps our executives get the benefits of agile but focuses on real, enterprise class value delivery... value defined in terms of real results and real business outcomes. So, why is agile a tough sell? We are asking our leaders to trust a process that focuses on team based outcomes but doesn't give them a credible way to articulate how the development organization is going to deliver on the more complex objectives of the business.

Subscribe to Leading Agile

Who Cares About Value?

Part of our problem discussing value is that value is a pretty elusive concept. What is valuable to me might not be valuable to you. It is easy to blur the line between what might be considered a valuable contribution and something that actually adds value to some desirable business outcome. Value can be created at many levels within the organization. You have to ask if the value you are creating can be easily translated into something meaningful to the business stakeholders. In other words, can we get the value you are creating within the organization, out of the organization?

Think about this… if you are an internal IT organization, your customers are your internal business stakeholders. The hardware and software solutions you build are enabling business processes that are valuable to the operations of your company. The value created is in the well-executed business process… not the hardware or the software you built. At the end of the day… the well-executed business process is the ultimate value proposition.

If you are a product delivery organization, your customers are the people that buy your software. Your software is only valuable to them to the extent that it enables their business processes. Value for the product delivery organization lies in its ability to build the right product, with sufficient quality, and getting it in the hands of paying customers faster than its competition. Value for the product company is derived from your customer’s willingness to pay for a product that helps them create value within their organizations. Your value proposition is not identical to that of your customer… and at the end of the day… you are one degree removed from where real value is created.

Let’s say for a moment that you are a product manager for that product delivery organization. Your goal is to get software out the door that you think your customers will use. Value is created when you define the right features and are able to engage the organization to get the features implemented into the software solution. Sure, those features have to sell, but the focus is on getting them built into the solution. Delivered end-to-end features equals value into the product. Here your value equation is two degrees removed from the real creation of value. Your software feature has to be sold to a customer and then used to actually enable the right business outcome.

What if you are a product owner working with a single team within a multi-team product delivery organization? Your customer might be that product manager trying to get an end-to-end feature out the door. Your job is to add a new feature into some major sub-component in a large systems architecture. You own that product, but it actually takes several products working in unison to deliver an actual slice of working software across the overall enterprise systems architecture. You are providing services back to the larger enterprise class system. Value to you is created when that service feature is delivered back to the project and you are now three degrees removed from the business enabling value proposition. Your service has to be integrated into the product feature, which then has to be sold, which then can be used to enable a business process.

Let’s keep going… consider for a moment that you are a technical team lead. Your customer is the product owner that defined your backlog and is trying to get enterprise services out to the Product Management team to deliver on the project outcome. Value to you is defined as some increment of working software (a user story) that enables some given transaction within the system to execute. Maybe we are accepting a data value through a system interface, transforming the data based on other system inputs, writing that transaction to the database, and giving the user feedback the operation completed successfully. Here you are four degrees removed from the business value equation. Your user story has to be combined with other user stories to enable the component feature, component features that have to be integrated into a larger value feature, sold to a customer, and then used to enable some desirable business outcome.

What if I am a developer on that team? My customer is my product owner, but it is also my team. My definition of value might be a unit-tested increment of code. If I am a tester on that team, my definition of value might be a passed test case. If I am a technical writer, my definition of value might be updated system documentation or tech manual. At this point, I am at least five degrees removed from actual business value. My work has to be integrated into the user story, which has to be integrated with other user stories at the component level, components which have to be integrated at the value feature level, which have to be sold, which have to then be used to enable our customers business processes.

So… no wonder that value is so difficult to talk about. Value is not only domain sensitive, it is context sensitive… it is role sensitive. It is sensitive to where you live in the overall development lifecycle. We have to either drastically reduce the number of hops between developer activity and the actual real business enabling value proposition OR we have to learn how to align all this lower level activity to support business outcomes that might be up to five degrees removed from the people doing the work. So next time you tell someone that agile focuses on business value… at what level of business value and how many degrees removed are you from what your customer actually cares about?

I think we have trouble selling agile because we are not talking about value at the same level our customers care about value.

Subscribe to Leading Agile

Is Quality an Absolute?

Last week I did a post called "The Hard Reality". I made the point that anything you build... any document you create... that doesn't result in revenue for the business... is wasting time and money. Personally, unless you build software as a hobby... I am not sure how you can argue with that.

We build software so we can sell software.

One of my readers made a comment that my post was one sided. Peter's point was that we shouldn't subordinate quality, performance, time to market... and any other number of other software metrics... for the sake of making money. Okay... sure... but who says you have to build crap?

My point was that there are lots of teams building great software... teams that think they are doing great work... teams with great culture... defect free code... and terrific velocity... that are still not making any money. If you build crap... I doubt anyone will buy it. On the other hand... what good is high-quality software if no one uses it?

Value is about building a product of sufficient quality that people want to use.

At the end of the day... value is determined by the people who buy our products. Personally... I don't believe there is an absolute here. We have to balance the time, cost, scope, and quality constraints to get products to market so people will give us money to keep going. At the end of the day, selling software is a prerequisite for being paid to build software.

Subscribe to Leading Agile

Comparing Value and Velocity

Is there a difference between the value a team delivers and their velocity? Said another way... if I increase the velocity of the team... aren't I getting more value from them over time? Like so many things we talk about here... the answer really depends on your context.

You might be inclined to make the argument that velocity is really just a measure of how many story points the team can complete in a given iteration. There is no explicit dealing with value... only relative size. But... if the Product Owner is prioritizing the backlog... and asking the team to deliver the highest value features first... isn't there an implicit correlation between value and velocity?

My take is that there is a correlation between value and velocity at the team level... it is when we get beyond the team that relationship starts to break down.

Think about this scenario... let's say them team is cranking out feature after feature... adding great stuff to the product... their velocity stabilized a few sprints back and is getting better and better every iteration. The company has a great product but a terrible sales team and even worse marketing. While the product is technically superior to their competition... how valuable is it if no one buys it?

You might make the case that all those really cool features ended up having very little value to the market. Great velocity... not so much value.

Here is another scenario for you... let's say you have four teams that have to work together to deliver a new product suite to the market. Teams A, B, and C have fantastic velocity but team D just hasn't been able to get their stuff together. Team D ultimately delays the release... and the overall product is late to market. In the meantime... the competition just released the latest version of their product and yours doesn't do so well.

How much did the velocity of teams A, B, and C help the overall value of your product? Again... great velocity... not so much value.

Okay... last one. Let's say you have 7 component teams that have to deliver features into several major architectural sub-components. All the teams are rockin'... they have met all their high level milestones... they know where they need to take their part of the project. One of the teams realizes a significant risk and their velocity tanks. The rest of the teams keep going... they are building great stuff... stuff that certainly has to be built someday... but again... that one team causes us to delay the release.

Most of the teams were doing great... one team not so great... where did all the value go?

Lean tends to take a broader look at value delivery across the entire value stream... across the enterprise... Scrum by it's very nature tends to look only at the delivery team. So... at the single team level... you can make a great case that there is a correlation between velocity and value. It's an implicit link, but it is there. When you start looking outside the team... across the entire value stream... that is where the correlation between value and velocity starts to break down.

When the Lean folks say that Scrum focuses on velocity and Lean focuses on value... as I see it... this is the reason why.

Subscribe to Leading Agile

Delivering Value

Last week I was out on a client visit to do a couple days of product training. The customer was not only new to VersionOne but also new to Agile. The idea for the engagement was to blend product training with some targeted methodology training to see if we could get them jumpstarted and on their way.

It became pretty obvious by the middle of the first day that our original training plan was not going to suit their needs. While I was prepared to deliver exactly what they asked for, the training would not have delivered the value that they expected.

Had we followed the original training plan, I would have left the customer unable to effectively use our software.

Coming from a traditional project background, I am a firm believer that some degree of up front planning is essential. The problems start when we are so confident in our plans that we stop listening. When we stop listening, we stop learning. When we are unable to learn, we are unable to adapt.

I met with the customer and shared with them my observations. We discussed an alternative approach for our second day and agreed to take the training in a different direction. We came up with a new plan that better met their needs and put them in a much better position to be successful.

Did changing course introduce some risk? Absolutely. Change always introduces some risk and following the original agreement would have been the safer approach. By taking that risk we were able to generate greater value for both the customer and ultimately for VersionOne.

At the end of the day, isn't that what it is really all about?

Subscribe to this blog Subscribe to Leading Agile