Trustworthiness... Then Trust

Trust is an import part of what makes agile really work. It is so important, we are intentional about creating the opportunity for that trust to emerge within the team. We are intentional about creating a planning, delivery, and feedback cadence that helps trust form between the team and the business. Trust is a fundamental precondition to how we write requirements, how we estimate, and how we assess progress. Without trust, agile isn't really very agile.

But what do you do if you are in an organization where trust is really low? What if you are working in an organization with a long history of distrust between the development team and the business... an organization where the business has unrealistic expectations and a perception that development never gets anything done. You might decide to adopt agile, but that history isn't going to go away overnight. In this case, is it fair to ask the business to trust the team?

One of the biggest complaints I hear from new agile teams, is that the business does not trust them to deliver. They are convinced that all their problems would go away if the business would just trust them to do their jobs. These teams want the business to trust them first. The problem is that the business has no history of getting what they want. They have no history of software being delivered on time. They have no history of getting the quality they need to be successful with their customers.

If you were the business, would you trust you to deliver?

What teams don't realize is that they aren't safe to be trusted. The business is on the hook for delivering value to their customers. They are on the hook for revenue and market share. With no foundation of trust to build on, asking them to trust is like asking them to take their hands off the wheel of the car. They are responsible for getting from point A to point B and want some degree of assurance that they are going to get there. Trusting the team feels like an irresponsible loss of control.

If you are a team that wants to be trusted, I would suggest that you stop asking the business to trust you. When you frame the problem this way, it makes you powerless to do anything about it. Either the business changes or you can't be successful... the problem is beyond your ability to influence. What you need to do is become trustworthy. Becoming trustworthy is something that you have power to do something about. If you are trustworthy long enough, you will earn the trust of the business and won't have to ask for it.

Subscribe to Leading Agile

Subordinating the Scrum Team

Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.

Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.

Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.

Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.

We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.

Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.

I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.

When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.

While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.

It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.

Subscribe to Leading Agile

COHAA: The Path to Agility

If you happen to be in the Columbus, OH area on May 27th... you should really come see me speak at the COHAA Path to Agility conference. I'm doing a variant of my Agile PMP talk... exploring a little bit around the intersection of traditional and agile project management.

This is one of those great one day events that are low cost, full of great speakers, and give you a great opportunity to network with some really smart people in your community. Every time I do one of these one day events, the value delivered is always so much greater than the cost!

Ken Schwaber is doing the keynote... that should be enough right there, but it doesn't stop. We've got Patrick Wilson-Welsh, Steve Harmon, Tim Wingfield, Michael Mah, Daryl Kulak, and one of my all time favorites... Isreal Gat. And that is probably only half the speakers that will be there to educate and entertain.

So... do yourself a favor, head over to the conference website, and figure out a way to be there. See you on the 27th!

Subscribe to Leading Agile

Interesting Post... 5/10/2010 through 5/16/2010

It's been a little while since my last Sunday morning installment of 'Interesting Post...' I don't usually like to fill my blog up with summary articles like this... so when I'm not writing real content, I don't tend to want to do these.

Also, I've gotten to where I don't really trust TwitterFeed a whole heck of a lot. TwitterFeed is what monitors my Google Share feed and turns them into tweets. It just doesn't seem to be as reliable as it once was. Some day when I have some time, I'll either figure out what I've done wrong, or I'll find another service.

As for now... enjoy this round of tweets from the week.

Arrogant http://bit.ly/dvceBv

APLN Board Update http://bit.ly/c9L3Ey

Agile and regulatory compliance http://bit.ly/cXRaFD

You heard me but are you listening [video] http://bit.ly/bIx9je

All you need to know... http://bit.ly/cbChgL

Toward An Event Driven Scrum Process http://bit.ly/caztRX

Agile and Lean Product Development – Yesteryear, Today and into the Future http://bit.ly/cEB9F0

Academic TDD links http://bit.ly/cxZdYy

3 Legs to Running an Agile Transition http://bit.ly/aWGH63

Personal Brands: The Testicle Defense http://bit.ly/9lWEQz

Agile: Chasing a points total http://bit.ly/bxUYBy

What's so good about scrum? http://bit.ly/9yEZkG

How To Harness Influence http://bit.ly/ajVRh1

Agile: It’s a Healthy Lifestyle Choice http://bit.ly/aSEDY0

Approaches to Organizational Change http://bit.ly/cTZvRy

Subscribe to Leading Agile

Ultralight Backpacking and Other Saturday Morning Musings

I've been a pretty big fan of Seth Godin for the past few years. I don't love everything he does, but his latest book Linchpin is excellent, and he's been on a roll the past few weeks putting some great stuff up on his blog.

Last week Seth relayed a story about an ultralight backpacker that was able to get his pack down to 14 pounds... including food. I like to fancy myself a bit of backpacker, and I can tell you... getting a pack down to 14 pounds, including food, is really hard.

When people asked this guy how he was able to pack so light, he would tell them "all you need to know is that it's possible". The point being, that when you stop saying that things can't be done, you figure out how to make them work.

That comment has been haunting me for the past few days.

Think about it... we can't do agile here? All you need to know is that it's possible. Can't get stories small enough to fit into a sprint? All you need to know is that it's possible. Can't get developers and QA to work together? All you need to know is that it's possible.

What else is possible if we stop saying that stuff can't be done?

Subscribe to Leading Agile

There Are No Spherical Chickens!

Just in case you are wondering... I'm not suggesting that our Credit Card Processing team shouldn't do Scrum. I'm not suggesting that they shouldn't improve. What I am suggesting, is that if the organization stops with this one team, they won't get the business benefit from Scrum that they expect. All the value created by the Credit Card Processing team will be obscured by the underperformance of everyone else. Furthermore... you shouldn't be surprised when your Scrum team gets downsized, outsourced, or reorganized... just like everyone else who didn't deliver.

If you don't have the ability to influence the rest of the development organization, it probably won't make any difference if the Credit Card Processing team adopts Scrum. Sure, the team will probably enjoy their work more. Maybe if they get really good at delivery, they can jump in and help out some of the other teams. If the culture is open enough, maybe everyone else sees the benefit of Scrum, and they become the catalyst for more widespread adoption. That just hasn't been my experience with this kind of grass roots hopefulness.

Most large companies I have worked with are full of silos, full of politics, and full of protectionism and fear. Accountability structures don't necessarily reward working well across teams. Incentives are geared toward individual performance first, and team performance second... if at all. Organizational or divisional objectives are so far off people can't directly influence them. We are allowed to build empires that only serve to grow the headcount in our particular group, often at the expense of our ability to work well with those around us.

The thing we most often forget when adopting agile, is the impact that agile needs to have on the culture of our organization... and the impact it needs to have on the fundamental structures that reinforce that culture. So... I have to tell you I am a bit cynical about the whole... give agile a try and everyone will be enamored with it's goodness routine. Most people would rather try to be individually successful in the system they know, than risk being unsuccessful trying something risky and new.

In a complex product, all the pieces and parts have to work together to deliver end business value. If you agree with that fundamental premise... and you are willing to agree that team level adoption does not typically spread (unintentionally) out to the rest of the organization... you are left with two options. You can 1) subordinate your Scrum team to the delivery cadence of the rest of the enterprise... or 2) plan to systematically introduce Scrum everywhere else, and learn how to manage the flow of value across the various Scrum delivery teams.

I am clearly in the camp of option 2.

Before we wrap for the day... I want to go back to why I think this topic is so important. A year or so ago, Ken Schwaber famously said, and I paraphrase: '75% of the organizations using Scrum won't get the benefit that they hope from it". If you care about agile, and you believe in the value that it brings to people and teams, and you have seen it work, that is a really depressing statistic. Our community's response seems to be... get more dogmatic about Scrum. If you aren't doing Scrum by-the-book, that is why you are failing.

I'm sure there is some of that going on, I am sure that there are some people bending Scrum to hide their dysfunction. My take is that this complex product idea strikes more the heart of why the underlying dysfunction exists. Vanilla Scrum does not work for these organizations because the value stream is bigger than a single team. Rather than assume that we live in a world of spherical chickens, I'd like us to explore how agile works, why it fails, and most importantly... what are our options for making things better when we can't wave a magic wand and change our cultures and structures overnight.

So... in the context of our financial services organization, and our Credit Card Processing team in particular... I want to explore a bit more why, in the absence of a broader change initiative, you have to subordinate their performance to the cadence of the rest of the enterprise. After that we'll get into how to scale Scrum from the single team, to multiple teams, to projects and portfolios, and then the enterprise. We'll explore blending approaches, how to leverage Lean and Kanban, and how to deal with multi-tiered values streams. We'll talk about how to break down requirements, deal with architectural challenges, how to do planning and context setting, etc.

I might take me a while... be patient.

Subscribe to Leading Agile

Can I Do Perfect Scrum and Still Fail?

If you're not keeping up... you've got some homework to do. My last post called "What Do I Mean by a Complex Product" is required reading before you read this post. If you've got a minute, go read that post and then come back to this one... thanks! - Mike

Okay, so let's explore our Credit Card Processing team a little more. They are in a large organization that is delivering large, complex products. They know that the traditional way of planning and building software isn't really working. The big up front requirements analysis and the the big up front design is really slowing the organization down. It routinely takes 18 months or more to bring any new product offering to market. This company is at risk of having smaller, faster competitors take their market share. This team wants to do something about it.

They've heard quite a bit about Agile and Scrum and like the idea of getting to hyper-productivity in just a few iterations. Let's say that this team moves mountains and gets everything they need to be successful... they get the team through agile bootcamp and bring in a coach... they get a top-notch product owner, identify a scrum master, they build the ideal cross functional team, they do all the right XP practices, they do iteration planning, daily standup meetings, demos, and retrospectives.

This is a team that would make Ken and Jeff proud. No Scrum-but here.

The product owner does a great job working with all the stakeholders... both her external customers and the other product managers in the organization. She balances the needs of her market with the needs of the other products that are dependent on her product to be successful. She crafts a backlog that is full of the right features, in the right order, to get everyone all the features they need when they need them. The team starts building... and starts getting really good at delivering done-done software every two weeks.

Just as it should be... right?

We'll... yes and no. The PO for the Credit Card Processing team is probably doing a great job satisfying the needs of her Credit Card Processing customers... that is a good thing. It also sounds like she is doing a great job meeting the needs of her internal stakeholders. But what about that new Payment Processing product that the business is counting on for a significant part of next year's revenue? How has Scrum impacted the overall flow of value for the entire company? The short answer is... it hasn't.

Clearly, this Scrum team has done it's part. I'm not even suggesting that this is a Scrum problem. But, if the Payment Processing initiative fails, where does that leave our Scrum team? It leaves them in the same boat as everyone else... downsized, outsourced, and reorganized.

But Mike you say... what else can I do? The only part of the system I own is the Credit Card Processing engine. I'm doing the absolute best I can with what the people and resources I have been given... I have been successful to the best of my ability. You know what... you're right... you have been successful to the best of your ability. That is what is so frustrating with localized Scrum implementations, it just doesn't matter how good you do Scrum. How well your team adopts agile doesn't matter... how well you adopt Scrum doesn't matter... at the end of the day, all that matters is the value the business get's from your efforts.

In this case, they didn't get the ultimate benefit and the Scrum team suffered. Here is what you have to keep in mind... if the system is bigger that your Scrum team... if the enterprise value stream requires more teams that just yours to deliver... you need to take that into consideration as you adopt scrum. Getting good at team based agile is NOT ENOUGH when it comes to adopting agile in the enterprise... it is NOT ENOUGH when you are part of larger, more complex products. All the pieces have to work together.

We'll unpack this more over the next few posts... for now, let me know what you think.

Subscribe to Leading Agile

What Do I Mean by a Complex Product?

I've been rambling on for the past few years about agile in larger, more complex enterprises. Quite often in that discussion, I'll get asked to show a real life example of what I mean when I refer to a larger, more complex product. I think there are quite a few folks in our industry that have not worked on products of this scale, so I think it is a fair question. This post is going to explore this a bit.

A large, complex product is one where many products are integrated into some larger product that has some distinct value proposition. The core products are products in and of themselves, with teams and product owners and revenue projections and customers. The integrated products also have teams, and product owners, revenue projections, and customers.

The resulting matrix looks something like this:

In this case, we have several integration products... online banking, phone banking, payment processing, and remittance processing. These products leverage payment services, risk services, business intelligence, and corporate financials.

I want to reiterate... both the products identified in the rows AND the products identified in the columns have teams, product owners, revenue projections, and customers. As a company, I sell both dimensions to different customer bases and different markets.

Let's make this look a little more physical than just a matrix in an Excel spreadsheet...

... and here lies the nut of the issue with the feature team vs. component team debate. Agile tells us that we have to build a cross functional team that is made up of individuals from each of the blue boxes and maybe some folks from the orange boxes. They become a team and deliver cross-functional features... but from who's perspective? Which dimension are we accounting for? We need to account for both.

Just to give you some insight as to the environment... the technologies involved here included Java and .NET and Cobol; Web Services and Enterprise Data Warehousing and ERP systems... not to mention that there is specialized business domain knowledge held by the developers and analysts in each part of the product organization. At the very least it is a bit naive to think that we are going to mash all this up and get hyperproductivity in just a few sprints.

I am all for disruptive change... but this is the kind of disruption that results in nothing getting delivered.

So what I am saying when I talk about organizing around capabilities... or services... or components... is to build agile teams around the sub-products in the organization. You might also form agile teams around the integration the various sub-products. The challenge then becomes how you manage the enterprise portfolio so that all of the teams are in sync and constantly converging to deliver value along both dimensions of the matrix.

The reason that I think most teams don't get the value from Scrum that they expect is that they have narrowed their definition of value to something that they can control.

If I'm part of a Scrum team organized around the Credit Card Payment Processing engine... and I build a lot of great features into my product... but the business really cares about the Phone Banking System... which you are a an integral part, but not the entire thing.... what happens? Your value is not recognized by the business... and THAT is the problem. Many of us say we are systems thinkers... but what system are we thinking about.

We have to care about the flow of value... not features from our part of the product.

Note: These images were created by a good friend of mine, Brian Sondergaard, who blogs (sometimes) over at http://blog.softwarearchitecture.com. He created these pictures for a talk we did together in DC at Agile 2007 around how to use RUP to scale Scrum. The 7 or so people that came really seemed to like it ;-)

Subscribe to Leading Agile

Bye, bye PJ's... Hello Brown Bag Deli

A few months ago, my favorite coffee shop closed. This was the primary place I'd go to write this blog and where I was always the most productive writing the book. The vibe was cool and I had a great view of a nearby park. Needless to say that I was profoundly disappointed when they shut their doors.

For a while the place was empty, but a couple of weeks ago, the new owners tipped their hat and put up a sign. We were getting a place called the Brown Bag Deli. I happened by today and noticed the place was open. I'm now sitting in my favorite corner but in totally different surroundings.

It's kinda surreal, and it's sounds odd, but it feels okay. Kinda like I have my favorite writing place back. Sorry for the diversion, but given this location's role in the life of this blog... I didn't want the moment to go unnoticed.

Subscribe to Leading Agile

What if I'm Not the Constraint?

What if you are a manager that wants to do Scrum? You ask yourself if it's possible to encapsulate the entire value stream into a single Scrum team? What if you learn that the answer is no? What if you think this through even further, and discover that your team is not the constraint? Does it makes sense to even give Scrum a try?

What if give Scrum a try and are wildly successful? Your team becomes hyper-productive and potentially disrupts the overall balance of the system. Is that a good thing or a bad thing? It might be great for your team and their morale... but what about everyone else? Will everyone else benefit from your hyperproductivity... or will it actually slow them down. What did Goldratt teach us about what happens when one part of the system overproduces?

Consider this for a minute... if you are a senior leader looking to transform your organization to Scrum... where should you start? Start by figuring out how you create value, and what teams are constraining value... and pilot Scrum there. That way Scrum will be tied to something that actually helps the overall system get better at creating actual value. It's not overnight transformation, but it is a way to help deliver real value.

If you are a team that wants to do Scrum, understand your upstream processes and downstream processes. Don't produce software any faster than you can receive quality inputs from the upstream groups, or faster than your downstream customers can consume quality outputs. Building software faster than you have requirements, or faster than your software can be consumed is waste. It's might not be hyperproductive, but it is respectful of the overall system.

Ideally you want a blend of both... you want to see bottom up adoption with top down intent. What does this mean? Understand your system... understand how the system creates value... identify the constraints in your value stream... build Scrum teams around the constraints... build on your success at the single-team level to systematically spread Scrum to new teams that are focused on the newfound, value oriented constraint.

With this approach, hyperproductivity can be encouraged while we simultaneously focus on actual end-to-end value being delivered back to the business. I'm all for teams owning the entire value stream... I am all for overnight top-down, bottom-up transformations. I'm also for doing things that make sense and managing risk along the way. I'm not so big on pretending, or hoping for things to be different, without a well designed strategy for getting there.

Subscribe to Leading Agile