“Classical strategic planning is based upon the assumption of a slowly changing future. This assumption is wrong.”

Noah Rahford 

We currently witness the beginning of a new era. It has been given various names, as nobody is yet able to predict its nature. It’s been called the conceptual age, information is not enough anymore. Relationships become more important, where “knowledge stacks are replaced by knowledge flows”. Abundance, connections and choice change the game: “Mass is dead. Here comes weird.” 

It’s a paradigm shift. We haven't yet figured out where it will lead our kind, as we can not predict the future. Two things are clear about the outcome:

It will be emergent and powered by software.

Which might make it worthwhile to look at business the way software developers do, and how that view changed over the last few decades. I’ll draw a line from software development to business transformations in general, and where these should lead us.

What’s Special About Software Development?

“It’s tough to make predictions, especially about the future.”

Yogi Berra, Baseball Catcher 

When companies started to develop software, they wanted to automate work that had been done manually before. The method they employed seemed straightforward: analyse the problem, model a solution, automate that model. But wait: More often than not, users of these systems started to claim changes. We found that users wanted to use the software we had written for purposes that we had not expected. This created a reinforcing loop: Today, most innovations in software solve previously non-existing problems—making predictions harder and harder.

Nonetheless, we tried harder to “design” the future. But no matter how much effort we put into better predicting the future, we did not find the silver bullet that made our intended future happen. We refined scientific management but only came up with busier people, instead of better solutions. We found out the hard way that in a complex domain, best practices are not appropriate anymore.

Where Agile Came From

Then some people tried a different approach: experimentation combined with empirical process control. This approach succeeded and evolved into a mindset we call Agile. Agile is a set of values and principles based on complexity thinking. As software became more complex, we adapted our practices until they evolved into Agile. Instead of trying to anticipate the future we wish would come, we work with quick feedback cycles to frame actions as safe-to-fail experiments and validate our learning. This way we can frequently check if we developed something of value. This approach did not only work well with the software we created, but also for the organisational changes it inspired in companies adopting Agile.

Transformation

Applying this experience in the field, over the years, the agile community learned useful lessons about organisational change. How a classical, hierarchical structure can be transformed into a fluid, innovative system. Such an enterprise will “operate balanced at the knife-edge of maximum effectiveness, on the optimal cusp between orderly working and chaotic collapse.”

Most businesses today struggle with change. Most strategies that made businesses successful do not work anymore today, or might not work anymore in the future. The complexity that hit software development in the 80s and 90s hits nearly all industries today. I think we should learn from agile examples.

Betterness

Yet what should we transform into? We do not yet know where the paradigm shift will lead us. Do we need to know? I do not think so, for two reasons:

Making your organisation adaptive to change will make it resilient to whatever the future holds. And: there is a purpose which will be valid for any kind of future: We should make this world a better place. If you think that’s not your business, consider the alternative: do you want your organisation to make things worse?

An economist phrased it this way: “I call this positive paradigm betterness; in contrast with business, it’s not about being busier and busier (to what end?) but about becoming better. I believe it’s the next step in the evolution of prosperity and that its foundational principle is living lives that matter in human terms. [...] So let’s roll up our sleeves and reimagine prosperity for the twenty-first century.”

This is our purpose. Let’s change the world.

Sources of Inspiration

Thank you Umair Haque, Andrea Provaglio, Bob Marshall, Dave Snowden and many others to inspire me with ideas that went into this post. Special Thanks to Paolo Perrotta for reviewing and editing it with me!

I am sure many people are already registered, but if you have not, The Early Bird pricing is $125!!!  Through February 16th.

The Agile Cooperative will have a table again – Stop by and say hello!  If you are going to be in from out of town – let me know!

Register at http://milehighagile2012.agiledenver.org/

On a related note:  Michael Spayd and Lyssa Adkins will be teaching Coaching Agile Teams in Boulder, Colorado on April 4th and 5th.  An excellent class on agile coaching and coaching in general.  You can view a description of the course on their website, agilecoachinginstitute.com… or just register!

More than two years after I originally published it, “Patterns for Splitting User Stories” remains one of the most visited posts on my blog. Splitting user stories continues to be one of the areas where the teams I work with most often need coaching.

To support the teams I coach, I’ve created a flow chart that goes through the questions I’ll ask when I’m helping a team split their stories. I was going to keep this resource for my coaching clients, but I’ve decided to share it here for free. Click the thumbnail below to download the full-size PDF version.

Let me know in the comments if you find this useful. If you can share them, I’d love to see examples of how you’ve used it, what the stories looked like before and after splitting.

Related posts:

1. Another Story Splitting Pattern (Maybe)
2. Patterns for Splitting User Stories
3. Free Agile Product Management Seminar – Nov 11, Denver

• What to show at the end of the timebox?
• How to set the length of the timebox?

Interestingly, these questions, although raised by the audience, apparently were not hot enough to actually get discussed... (the topic Agile Beyond Software is much broader than this post, I’m just covering what was discussed tonight—a touch on the surface...)

Hardware

It turned out, that the person suggesting the topic actually had a challenge integrating hardware and software teams... Which then lead to a heated discussion about how quickly hardware can be developed, manufactured, and integrated with a new version of the software—which, in the case of these Scrum teams, happens to be potentially shippable every two weeks.

As in many similar discussions I have observed in recent years, it is quite interesting to note how little most software developers know about hardware development. Many of us take it for granted that hardware development cannot match the pace of software. While this might be true for the case of the best software teams, able to update a software system every few minutes using continuous integration, for the common pace of biweekly software delivery this is nothing more than a false assumption. My colleague Ralf Kruse suggested to compare this with software teams new to agile development, who also tend to be sceptical about the possibility to ship working software every two weeks. With software systems, we now have quite a large number of examples which are publicly available on the web that show this is actually possible, even for large-scale enterprise systems.

Examples of hardware development integrating new versions every two weeks might be harder to find, yet they are available if look for them. WIKISPEED is a fine example of a 100 miles per gallon car developed using Scrum, iterating the entire car every seven days.

We know many more examples from our personal work experience, like ECUs for cars, satellite communication and other complex systems including hardware using a frequent integration pace.

Challenge Your Assumptions

How does that work? Or, to get at the underlying assumptions, why do we think this is difficult? In my experience, it usually burns down to organisational issues: contracts with hardware suppliers who “can’t” deliver more often than every 2 months, hardware departments who need “for ever” to develop a new prototype... This is the status quo for most organisations. But does it need to be that way? Toyota has proven in the automotive industry how long-term partnerships with trusted parties avoid long contract negotiations for every single piece you need. Instead, the partnership enables a learning environment for both sides to challenge the status quo and find new ways that might work better. This might even be easier inside an organisation where the parties involved actually would not need a contract at all to work together...

We need to challenge our assumptions and identify our real options. How can we prove we are moving in the right direction at the pace that our competitive situation demands today if we don’t challenge the organisational dysfunctions that we developed in another century? Agile has a purpose. We need to make this world a better place, so we should stop increasing busyness in business, and start thinking about Betterness instead. 

Realizing that mastering Agile software development is more than just learning techniques, I am rebranding and changing the name of my company to (drum roll, please)…

To Be Agile

This new name (and website) reflects a new commitment to helping our community, not just do the Agile practices, but to be Agile with everything we do!

I hope you like the new website: http://ToBeAgile.com. I’ve moved all of my blog posts and other resources to it and will continue to update it with new resources and information. I will redirect visitors from the Techniques of Design website to the corresponding pages on the To Be Agile website. Please update your bookmark and contact information for me:

Website: http://ToBeAgile.com
Email: info@ToBeAgile.com

Thank you!
David Bernstein, To Be Agile

Unfortunately the article is only available in German, but maybe google translate will help :-)

Marion

Business Analysis Training Series

We just announced our Business Analysis Boot Camp, in Denver Colorado on April 11th, 12th and 13th!

If you are interested in learning more about the course, you can read the full description or register – or contact us if you have questions!

Some of the highlights include:

• Smart business analysis – we walk-through, with examples and exercises, an approach to business analysis that you can apply immediately when you get back to your organization.
• Hands-on exercises!  We focus on practical examples and exercises to facilitate learning!
• Lean business analysis – business analysis is not about developing a big document – it’s about delivering value to customers.  We look at ways to deliver more value for customers, while balancing the specific needs of your organization.
• Coaching and follow-up calls are INCLUDED.  We know from talking to customers that new questions and ideas arise when people take new ideas back to the reality of their jobs.  To address this need, we are including follow-up learning circle calls and private coaching sessions for each attendee!
• Agile business analysis and Scrum – Agile and Scrum are certainly popular right now!  We go beyond the basics and buzzwords and dig into details to talk about what agile is really about and why agile concepts are so popular. No prior knowledge of agile or Scrum is required – but expect to leave with a solid understanding of the foundations of agile – so you can talk about how agile affects analysis knowledgeably!
• Traditional, waterfall, agile, hybrid – Our course is not about picking one of these options, but it is about being as smart and lean as you can in your organization.  Focus on the customer – using the smartest approaches you can!

If you have questions, let us know – or learn more and register!

Business Analysis Training Series

Use cases are a popular analysis tool and are often used as a form of requirements.  Use cases provide a context or wrapper for features (potential requirements) customers need or want.  Use cases package a set of features and can be used with situational examples of real business scenarios.  There are a number of levels and types of use cases and because projects and organizations vary – your use case approach needs to adapt to meet your specific needs. We talk about these concepts and how your use case approach should limit waste and focus delivering valuable results.

Our course focuses on understanding and learning about use cases by working with them.  Attendees will develop, revise, expand, and update use cases in a variety of situations.

We will cover the fundamentals of use cases as well as more advanced topics.  So if you are new to use cases, looking for a better way to deal with features and requirements, or have experience with use cases, you will find valuable information in the concepts and information we present.  We cover the value of use cases regardless of your approach (traditional, agile, waterfall, rolling wave, hybrid, etc.) and explain how your use case approach has to vary with your project and organizational needs. We include a discussion and review of agile use cases and regardless of whether you are using an agile approach or not, these concepts can be used to improve your results. You can read more about use cases at Wikipedia.

Our use case analysis and modeling class is a hands-on course that engages attendees with practical exercises to learn about, understand, and practice developing and improving use cases.

Learning does not end when the class does!

We understand learning is an ongoing process.  We believe in relentless learning and improvement.  Many people leave a training class and then run into questions when they are back at their organizations implementing new ideas!  Our training package includes:

• Training class: Team and individual hands-on exercises to learn through experience.
• Learning Circle: Follow-up calls to review progress, build your network, and learn.
• Coaching: Two half-hour private coaching sessions are included and can be used to discuss and review your questions about the class materials, business analysis concepts in general, agile or other related topics.

Learn more about the course: Use Case Analysis & Modeling

If you have questions or comments please let us know!

                      Dave Sharrock after the agile42 Internal Coach Camp

We want to make Dave’s prediction a reality with the Agile with a Purpose blast (projects don’t hit, right?). We want you to know why we’re doing it.

Prepare to be astonished!

Some Background

Stephen Parry (@leanvoices) said at the ALE2011 conference that he would like to see agile/lean practitioners joining forces, using their distributed open social network to amplify their knowledge of how Agile works and how it should not be used ("to do the wrong things righter" was his lovely phrase).

Last week, we discovered @thinkers50 (the world’s top 50 business thinkers). What struck us was:

1. Why don't more of us know more of them?
2. Maybe we should start talking to them?
3. We should raise the awareness of the agile business thinking.

Agile might still be a small niche which apparently is not yet recognised by the “serious” business thinkers’ community. There seem to be people out there who are rethinking management and business for the 21st century, and we are not connected to them although collaboration between us could produce great results.

We think that by focusing on our community we are missing some of the right people. 

Let’s send the right message!

Our Goal

• Create something that can't be overheard and will be remembered
  and
• Prove that the Anarchy with a Purpose model of organisation works again (ALE2011). 

How we do it

We co-create in our distributed team and humbly let greatness emerge.

We want to be nimble, quick, and effective. 

2012 will not know what's hit it. Thanks Dave!

We already gathered over a dozen people by private invite. In order of commitment:

Can You Join?

Sure! Ping us on Twitter and we’ll add you to a list of volunteers. Team members can pull you in to pair on some work. The first (and currently the only planned) iteration will last two weeks and will start soon, so you might want to be quick.

How to Follow

The Twitter hashtag is #AWAP. What outcome do you expect from this crowd joining their passion for two weeks?

Atul Gawande is a surgeon and author who has written some excellent books and New Yorker articles reflecting on the state of modern medicine. Recently, his writing has gone beyond medicine in interesting ways. As he looks for lessons for medicine from other disciplines, he ends up with things to teach both medical professionals and skilled knowledge workers more generally. His book The Checklist Manifesto manages to be a riveting 224 pages on what ought to be one of the least interesting topics possible: the checklist.

So I was intrigued to see a link to a New Yorker article from Dr. Gawande on my own specialty, coaching. It’s as good as I might have hoped. Noticing that his own performance as a surgeon seems to have plateaued, he wonders whether a brief experience with a tennis coach might apply to surgery:

One July day a couple of years ago, when I was at a medical meeting in Nantucket, I had an afternoon free and went looking for someone to hit with. I found a local tennis club and asked if there was anyone who wanted to play. There wasn’t. I saw that there was a ball machine, and I asked the club pro if I could use it to practice ground strokes. He told me that it was for members only. But I could pay for a lesson and hit with him.

He was in his early twenties, a recent graduate who’d played on his college team. We hit back and forth for a while. He went easy on me at first, and then started running me around. I served a few points, and the tennis coach in him came out. You know, he said, you could get more power from your serve.

I was dubious. My serve had always been the best part of my game. But I listened. He had me pay attention to my feet as I served, and I gradually recognized that my legs weren’t really underneath me when I swung my racquet up into the air. My right leg dragged a few inches behind my body, reducing my power. With a few minutes of tinkering, he’d added at least ten miles an hour to my serve. I was serving harder than I ever had in my life.

Not long afterward, I watched Rafael Nadal play a tournament match on the Tennis Channel. The camera flashed to his coach, and the obvious struck me as interesting: even Rafael Nadal has a coach. Nearly every élite tennis player in the world does. Professional athletes use coaches to make sure they are as good as they can be.

But doctors don’t. I’d paid to have a kid just out of college look at my serve. So why did I find it inconceivable to pay someone to come into my operating room and coach me on my surgical technique?

The rest of the article wanders through a history of coaching; interesting examples from sports, music, and education; and describes his own experience engaging a coach. He concludes,

There was a moment in sports when employing a coach was unimaginable—and then came a time when not doing so was unimaginable. We care about results in sports, and if we care half as much about results in schools and in hospitals we may reach the same conclusion.

I value coaching enough to spend my own money on it. I’ve hired a mountain bike coach, Lee McCormack, to help me prepare for this summer’s Trestle All Mountain Enduro race. It’ll be my first downhill race. I don’t expect to win, but I want to get a result I can be happy about and enjoy the experience.

I used to do cross-country mountain bike races, and I have a pretty good idea how to train for an event. I have Lee’s books. I could probably do this on my own. But I know from my own experience as a software development coach how much faster a good coach can help you improve.

Lee McCormack on his backyard pump track

After just two hours of coaching—working on things I would have said I already knew how to do—I could see a marked improvement in my skills. And I had a nice list of things to practice on my own.

This brings me back around to software development. Our world today runs on software. But most software teams struggle to deliver anywhere near as quickly and reliably as they could. A software profession living up to its potential would transform the world. So, to paraphrase Gawande: If we care half as much about results in software development as we do in sports, how is it imaginable that so few teams engage a coach? How is it imaginable that so many teams with access to coaching fail to make the most of it?

What about your team? Do you have a coach? If so, do you make the most of the coaching you have available to you?

Related posts:

1. Refactoring Things Other Than Software
2. How to Invest Less and Make More From Your Software Projects
3. UI Sketches for Distributed Teams