Never Waste a Good Crisis

Lasting change. It’s what we want. But steering our organizations in a new direction can be a daunting task—often it’s even challenging to know where to begin.

Looking around your organization you probably see numerous things you’d like to improve. And Agile is sweeping the software industry—and even making inroads into other industries—because it delivers on common pain points like product defects, morale and time to market.

But while its easy to find the things you want to change effecting that change can be challenging—if not seemingly impossible at times.

I see this a lot in my work as a coach and consultant. Real change sometimes seems to have more to do with luck and timing than with the skill of the people working on the project. Good people fail and backslide often.

But, looking a bit deeper, we see this has always been a problem and has nothing to do with Agile specifically.

“The only person who likes change is a wet baby.” —Margaret Mead.

It’s not just a change to Agile that organizations resist. And it’s not just organizations that resist change. It’s us humans that usually prefer the safety and relative comfort of the way things are—no matter how bad—to the scary unknown of the future—no matter how good.

Enter the crisis.

Whatever your politics it’s hard to argue that President Obama’s administration has not been able to push through massive amounts of change. From the $787 billion stimulus plan, to the overhaul of health care, and the reworking of consumer protection laws, the changes have been deep and are potentially far reaching. And they most likely would not have happened without the 2008 financial crisis. Shortly after being appointed Obama’s chief of staff, Rahm Emanuel said “You never want a serious crisis to go to waste.”

And crisis also has a role to play in an Agile transformation. Chad Holdorf who was at the center of the Agile transformation at John Deere’s Intelligent Systems Group a couple years ago has this to say: “We were faced with a hard deadline for shipping a new display in a very short timeframe. It was a do or die situation. We knew then that what we had been doing wasn’t going to work for this effort. We really had no other choice but to go Agile then, and we’re still reaping the benefits now.”

Finding your crisis.

Many crises hit us with so much force that there is no possible question that you are in a crisis. For John Deere it was a 90 day window to get new features to market or else they’d have lost an entire year of sales. For the Obama it was the worst meltdown of financial markets in decades.

But in the rooms of Alcoholics Anonymous—people with perhaps more intimate experience of crisis than anyone else—you’ll hear that you don’t need to wait for the crisis. In AA they say that each person they say can choose their own bottom meaning some people decide to change when they find themselves living on the street, and others when they cause an accident or have a child taken away. But they’ll also tell you that many alcoholics choose to change after relatively minor set backs like being passed over for a promotion or losing a friend. Sure you need to hit bottom but what “bottom” actually means varies from person to person. You, individually, need to find that place in your heart that says “I’m now willing to do the hard work to make a change.”

Your organization—addicted to wasteful practices—is the same as and alcoholic addicted to drink and self-destructive behaviors. And it’s up to you to choose your bottom.

Awareness and acceptance, then action.

It all starts with awareness, and in a group of people this means that a significant number of people—especially those in highly visible positions—need to develop this awareness. In order to choose your bottom you need to first unblinkingly face the present state of things, and make this current state as visible as possible others. And not just superficially, they need to feel it.

The next step is to be honest with yourselves that things really are as bad as they are. No more confirmation bias in your data analysis, no more ignoring the problem or simply hoping it will work itself out. You need to face the reality as a group that things are not OK.

And then it’s time for action. Time to make the changes that your organization needs to improve. Only once people are significantly aware of the problem and are able to look at it rationally and unflinchingly are you really ready to make a change and adopt new practices.

Have you hit bottom? How do you know? How can you measure it so others can see it?

Photo: Some rights reserved by L’Ubuesque Boîte à Savon

Let Them Make Progress

While it’s important to pay competitively, attracting people is about much more than money; RIM, the famed maker of the Blackberry, is losing talent despite having cash to burn. And while a pleasing work environment and flexible schedule can be helpful, those elements alone do not make great teams; Steve Jobs was as notorious for pushing people beyond their mental and emotional limits as he was for attracting top people.

So if it’s not about bonuses or air hockey, what is it about? How do we inspire people to actually want to come to work each day? And how do we empower them to be their best?

It turns out that what talented people want most is to make progress on meaningful work. We know this in our guts—it feels great to look back at the end of the day on completed work, and terrible to spin our wheels. This is true no matter what your salary is and whether lunch was free or not.

Just out of college I worked as a carpenter. Looking back each day at the wall we’d built or the roof I’d shingled was always a meaningful experience. For many years after I considered that job to be the best I’d ever had, and I wasn’t just being overly sentimental; there’s data to back this up. Harvard professor Teresa Amabile and her team confirmed in a study in 2010 that incremental progress towards a meaningful goal was the single greatest predictor – by a wide margin – of satisfaction at work. Meaning not salary or benefits.

And making progress is about working iteratively and producing incremental units of value. Yes it’s a mouth full but it’s a simple concept and you can start working towards it today.

Check out the preview of our new book at Rally and learn how to create an organization that works incrementally and iteratively.

Image by Andrea Bosio

Attracting Rockstars

Every company I talk to is looking for rockstar (or at the very least competent) developers, architects, product managers and QA engineers. And most talented people I know are looking for work environments that don’t suck. So whether you’re searching for a good place to work, or building a team, you’re most likely feeling that there’s a shortage of what you’re after.

This is a supply and demand paradox of epic proportions and it’s only getting worse. Every company today, whether bank or bakery, depends on software—from marketing apps to inventory control systems. This means that everyone is in the software business, and demand for talent and specific skill sets will continue to increase for the foreseeable future.

Because unhappy workers can simply move on to greener pastures, this shortage is particularly troublesome for employers. The great news is that most workplaces do suck, and if you build one that doesn’t, you can become a talent magnet. It’s actually not that hard to stand out.

In the book we’re working on at Rally one of our goals is teaching you how to build the kind of place that rockstars want to work at—which is also the kind of place that encourages people to find their inner rockstar.

Image by -Jeffry-

Agile for Business

In 2008, I fell in love with Agile.

I was working as a product manager at MaestroConference, a startup in Oakland CA, and Agile helped us create not only a product that delighted our customers but also a development methodology that delighted our team. Agile had, in fact, taken us from a team that argued and struggled to a group that collaborated and produced.

I’ve been a manager and designer for most of my career—in newspapers, the web, and software. Most organizations I’ve worked for have experienced challenges, if not open war, between technology and business. At Maestro, I realized that never before had I worked with a technology team so well. I knew something special was happening, and we had Agile to thank for it. It was then that I became a believer.

I decided I needed to share what I’d learned with others like myself: people who care about technology but are not ourselves overly technical. Although Agile is generally perceived as an IT process, I saw so clearly that it could have a massive impact on the business side of companies.

I started blogging, coaching, and sketching out ideas for a book. That was over over three years ago. Today I’m happy to announce the release of the first iteration of Agile for Business, a book I’ve co-written along with my incredible colleagues at Rally Software. This book explains Agile and Agile transformations in the plain business-focused language that we non-technical people need.

Rally coaches have extensive experience in the implementation and deployment of Agile techniques across organizations. The Rally team has added their passion and experience to my original vision—and I couldn’t be more proud of the result.

An important part of Agile is shipping things in a continuous and real-time manner. This is our effort of practicing what we preach. We are releasing the first increment of the book at the Agile 2012 conference to test how you think we’ve done—it’s not a complete copy of the book but enough we hope to whet your appetite.

We invite you to download the PDF now and share your feedback honestly and abundantly.

From everyone at Rally, we sincerely hope you enjoy.

The “Resource” Myth

The reason money is so popular is that it’s a fungible unit of energy. I earn a dollar at work and spend it at a restaurant without any loss in value a long the way. Thus eliminating my need to only patronize restaurants where I can barter Agile coaching for dinner. It’s a good system.

But problems arise when business treat employees the way consumers treat dollars. Does this sound familiar? A manager with the spreadsheet looks at available resources then allocates that resource to projects that needs that resource’s skills. And this is usually done partially across several projects; 50% here 25% there and 15% waaaaaaay over there.

Need to move faster? No worries we’ll just allocate you a few more partial resources and your project will speed up for sure.

This would be great except individuals are not fungible. Not even close.

There is a cost to switching context as each person needs to be brought up to speed and increased numbers require increased overhead coordinating those numbers. And when’s the last time a project manager asked for 50% of your time when that’s what was allocated. Inevitably these lucky resources get asked to do more than they are able in each project and are quickly overwhelmed.

The solution lies in changing how we think about the way people work and adopting a new mindset – a mindset at the core of Agile organizations.

1) Resources are people.
Get used to this. People need to be treated as humans. While I have a kind of moral aversion to using the word “resources” to refer to individuals that’s not the main problem. The problem is that by not acknowledging up front that we are dealing with messy, difficult-to-define people we create a dangerous illusion of control where actually we have none.

2) People work best with other people.
A brief examination of social science, management theory, psychology and even neurobiology will quickly reveal that humans are here to interact with other humans. As a species homo sapiens are hyper social meaning that we function best in groups. Nowhere is this more (and ironically less) true than in the modern corporation.

3) Teams work best when stable.
Changing membership on teams breaks continuity, creates churn and generally disrupts patterns. While pattern disruption can be good for innovation it’s terrible for productivity and morale.

So is it possible to have a fungible unit of production? Actually it is. But we need to change our thinking and the way our organization is structured.

Rather than moving people to projects we need to organize into stable teams and move work to the team NOT the resource to the project.

This requires vision, leadership and discipline. It’s not easy but the payoff is worth it.

How is your business doing?

Extinction and Success

“I think it apt to say that every species is a success until it fails and goes extinct.” Jurgen Appelo in Management 3.0

What does it mean for a software product to be successful?

We of course want our products to be popular and allow us to, in the mantra of the Valley, “retire early and retire often.” But what of products that aren’t? Do we count time spent on them a total loss?

My friend Bryan Franklin says that the goal of a marketer is to find the tracks the freight train of the market is running on, then create a product that gets hit by the train. A colorful way of saying that markets are discovered not created.

But how do we find those tracks? The same way any species finds its niche – iteratively and incrementally. Product market fit – the goal of any product team – is almost always achieved with a combination of trial and error fueled by sudden bursts of brilliance.

Great products therefore are built upon the bones of ancestors. They stand on the shoulders of previous versions and previous products – some of which made little money.

In the same piece Appelo points out that dinosaurs ruled the planet for 160 million years while modern homo sapiens have been around less than 200,000 years. Which species is more successful?

Even products that don’t lead directly to other products can be useful because they lead us to new ideas, new capabilities even new desires.

Today I want you to take a broad view of your product and even business category. Get a sense of the evolutionary story you are a part of. What can your future product learn your current product? What can your future self learn from your current self? And, most importantly, what are you grateful for?

Bob’s Top Agile Reads

“There’s this amazing book by ______ Have you read it? No? OK, I’ll send you a link after class” I repeat this so often in trainings that I sometimes feel like a broken record.

I’m a bit of a bookish nerd and I usually get very excited about whatever I’m reading at the moment (right now that’s Sex at Dawn – which, oddly, has quite a bit to say about Agile, more on that after I finish the book). In this post I want to share with you the resources I find foundational to any Agile transition.

If you are well into a transition or just taking some halting first steps (like reading a blog on the topic) these are essential resources. They are especially well suited to managers and executives and those of you on the product side of the house, though IT and delivery team members will also find them incredibly useful. Let me know what you think!

THE LINKS:

Dan Pink wrote an excellent book on motivation and management called Drive. There’s a 10 minute video that captures the main points on RSAnimate. The book is excellent, however you can get plenty of useful ideas and inspiration from his talks I recommend you start there and then get the book if you want more.

One of my favorite books on Agile and Management is Management 3.0 by Jurgen Appelo. I also highly recommend his blog. Jurgen is thorough and concise – two virtues that seldom cohabitate. He presents a foundation for action that is academic and pragmatic. If you have to start somewhere, start here.

Chad Holdorf the Scaled Agile Coach at John Deere has done some great work on team organization at the enterprise level.

Dean Leffingwell is the author of 4 books on software requirements and Agile at scale (he also worked with Chad at John Deere). He has an excellent (if a tad busy) model for a Scaled Agile Framework – it’s an excellent vision of what’s possible. Read his blog, buy his books (and read them too).

Story Mapping – a methodology developed by Jeff Patton – is an excellent way to visually represent an entire product. It helps avoid some of the pitfalls of a flat backlog and envision clearly what a Minimum Viable Product might be. A PDF of his original 2005 article on the topic is here. And there has been much written on the topic since, Google will show you the way.

Eric Ries has done some excellent work combining Steven Blank‘s work on Customer Development with Agile. He is working to put scientific rigor behind the process of achieving Product-Market Fit. This is crucial to startups of course, but this kind of entrepreneurial thinking is also important in larger organizations and will only get more so in coming years. Start with their respective blogs (linked above), Steve’s foundational book Four Steps to the Epiphany or Eric’s new book The Lean Startup.

And finally one resource I find essential is the book Switch by Chip and Dan Heath. We Agilists are in the business of Transformation and this means we need to have a clear understanding of how change actually occurs in complex human systems. The Heath brothers have broken a very complex set of social science and brain research into a set of simple, usable steps. Their work is especially aplicable if you feel you want to increase your influence but have limited authority. They also do a series of excellent podcasts and pdfs which are free to those who register on their site (also free).

What are your go-to books, blogs and videos for inspiration and information?

––

Photo by: accent on eclectic

The Two-Pizza Rule

Yes “resources” are people and yes, people work best with other people in stable teams. But this means nothing if the teams are too big.

It’s simple math really. A group of 2 people has 1 line of communication – very easy to manage. 3 people have 3 lines and again this is simple. 7 people have 21 lines of communication and the addition of just 3 more people more than doubles the lines to 46. You can see how things can get complicated and while complex is good, complicated means trouble (as with wine and women).

If we want people to work well together we need to keep team size and communication lines within human limits. The rule of thumb is that teams should have 7 members plus or minus 2. This keeps open lines somewhere between 10 (for a 5-person team) and 36 (for a 9 person team).

The trick is to have teams big enough that they benefit from diversity (e.g. complexity) and small enough that they don’t overwhelm the computing capacity of the individuals.

We call this the Two-Pizza Rule. If you have to buy more than two large pizzas to feed your team lunch the team is either too large … or the team members are.

–

Photo By: Subtle Panda

Agile Perfect & The Adjacent Possible

This week I went to Connecticut to deliver an Agile Intro to the IT management team at a new client. During the prep call I asked, as usual, what their desired outcomes for the day are, and was told, “we want a clear picture of Agile Perfect”.

This is a lovely goal on the surface, but contains assumptions that may not be so useful. Let me explain.

Agile is iterative – not only for software releases but also in terms of process and organizational capability. When we transition an existing businesses from waterfall or chaos to a disciplined Agile system we work evolutionarily not with big bang changes. At least not at first.

That is we start with where they are now and look for the highest value next steps – what design thinking and evolutionary biology call the Adjacent Possible. The goal is to create a learning organization that continuously improves not a perfect static system.

Think of the deep past of this planet when single celled organisms were the most complex forms of life. At this time there was potential for all we have now – sunflowers, cats, honey badgers and humans – but they were not yet possible. Biology had to take it’s time and iterate towards increasing complexity until the sunflower was the next potential item on the evolutionary backlog.

And so it is with organizations. Sustainable change happens iteratively and incrementally. While it’s important to have a strong view and discipline around what it means to be Agile it’s not useful in the beginning to spend too much time envisioning an ideal system (though models like Dean Leffingwell’s Scaled Agile Delivery Model are inspiring and challenging to review). It’s far more useful to focus on the next step that is possible for the organization as it is.

The client in Connecticut for instance realized after our session that their next most important step was getting buy-in on Agile principles from the business side. IT is already on board but without support from the product people the transition will likely falter and fail.

While a vision of an Agile Perfect world is desirable there is far more value in focusing energy on the Adjacent Possible. And once achieved, the next horizon of possibility will come into view.

What’s the next step your organization can take? What’s the adjacent possible? What feels out of reach?

–

Photo by: Kyle Rush

Accurate Estimation: An Oxymoron

A developer friend recently asked how to handle it when the business side of the company insists on not only constraining delivery date and scope but also on moving the date up and asking them to “make it so.”

This is a form of disfunction I see often and while there are super visionaries like Steve Jobs who seem to be able to inspire super human action through the clarity of their vision, situations like that are incredibly rare.

Dealing with a situation like this takes courage and tact. I thought you might be interested in my response to him.

– —
Dear _____,

First let me say that the situation you are in is both typical and challenging. And second let me offer that there may not be an easy way out of this. It is an interpersonal/cultural problem more than it is a “how do we estimate better” problem.

We humans are all bad at estimating. Breaking things down into tasks then putting hours to those tasks then adding them up to get an overall project plan and delivery date is very tempting. It gives a very powerful illusion of accuracy but in reality it is far from accurate.

This is because humans tend to underestimate how long something will take to do. This is a statistical reality across industries, teams and individuals. So when we use aggregated task hours for large estimates there is an error amplification effect with the end result that we are usually very very late.

A much more accurate way to go is to group things together with other similar things — small, medium, large etc. Then apply a measure — I prefer story points in a fibonacci sequence — to each group. If we track our historical performance over time in these points we can then look forward in our backlog to estimate a delivery date with a relatively high degree of accuracy.

This kind of estimating though takes time, discipline and a safe environment to develop a mature practice. This is where culture comes in.

You need a safe-to-fail culture to do good work. Show me a culture where failure is not an option and I’ll show you a culture that will never be successful. Until business and IT can agree to share risk around estimates it will be difficult to get anywhere.

The only way to ensure you hit a date is to have the freedom to limit scope. Teams can eventually learn how to increase speed — to a point — but ONLY when they are mature, self-organizing and self-directed. This means that management must respect their estimates and create a space that is safe to experiment and safe to fail.

Your job is therefore not to estimate better but to work with the business and help them to understand your situation and find an ally on the business side to act as Product Owner who will share the job of estimating with IT. Unfortunately this often means setting boundaries, which can be very unpopular.

It’s up to you therefore to assess whether you want to either fight for things to be done right (which may mean losing your job), manage as best you can with small incremental improvements to a tough situation (which can be a form of slow, painful death) or seek opportunities elsewhere.

I wish you all the best in whatever you do,
Bob