12 Keys to Success with Agile

We are having a snow day in Atlanta.  Snowmageddon they call it. Literally, everything is shutting down. We don’t do salt trucks and we don’t have snow plows, and we sure as hell don’t have any experience actually driving on snow. I guess it’s safer this way, and while I am enjoying the unexpected day off, it’s going to be a challenge figuring out how to reschedule my time, if this goes on for more than a day or two.

UPDATE: Client just pulled the plug on tomorrow as of this writing.  Doh!

So… I’m sitting here in my office attending a few remote daily stand-ups, attending a few conference calls, and getting ready for some upcoming training days. I’m also trying to get some writing done on the book. Last year proved to be really hostile toward writing and creativity, but I am expecting good things to come from 2011. That means that I’m going to blog around some of the stuff noodling around in my head.

Good sense would probably say… write a few blog posts and spread them out over time. That would be good sense, but it’s not the way I roll. I write it and I want it out for feedback ASAP. I look at my writing like a developer might think about writing software… any ideas that aren’t deployed to a customer risk decay. I have to publish before I change my mind. Given that, I’ve got four chapters running around in my head, and I want to blog about them so you guys can consider and comment

Patterns to Success With Agile

I’ll plan on taking a deeper dive in each chapter and each topic as the days and weeks progress, but for now… I want to break down some of the ideas that I think really makes Agile work. Kind of like a “Mike & Dennis’ 12 Keys to Success With Agile” if you will. I’m fundamentally convinced that there is no set of practices you can adopt that are going to make you successful. Every rule we teach is made to be broken.

That said, there are some patterns I see over and over that are fundamental to a successful Agile adoption, or a large scale enterprise Agile Transformation. Here are the ones I think are most important and why.  I plan to take a deeper dive into each one individually over the next few days… who knows… maybe I might do some of them today ;-)  And it’s looking like I’ll probably be working on some of them tomorrow too!

1. Cross-Functional Teams

Teams aren’t the only way to be agile, but I have a hard time thinking about building an agile enterprise without them. Unless the individual can deliver an increment of business value all by themselves, you need a team of people that have everything they need to deliver, and can be empowered and held accountable for delivering the outcomes the business needs to be successful.

2. Empowered Team Members

One of the problems with traditional software project management, is that we focus too much on activity (more on that later). By having a cross-functional team, we can worry less about the activities the team is working on, and more on the business outcomes the are charged to help create. When we focus on business outcomes, we are free to empower the people on the team to solve problems, and we don’t have to worry about managing their activities.

3. Single Voice of the Business

Many of the prescriptions of Scrum and XP are designed to abstract the complexities of the business from the team and give them a single point of contact for prioritization and guidance.  We don’t necessarily need a Product Owner, I don’t necessarily need sprint planning meetings, but we do need the business to make the tradeoff and prioritization decisions that need to me made. This cannot be shifted to the team, as it often is in many larger organizations.

4. Shared Accountability

This means that we have to create a culture where no one gets to only be accountable for their part. We have to have shared ownership for business outcomes. At the team level, this means that developers, testers, and analysts all work together to build an increment of working software. In more complex product organizations, this means that we need to all look out for the entire delivery and do what it takes to help everyone, on every delivery team, successfully deliver the product together.

5. Servant Leadership

Leadership, and even management, is essential for any successful agile implementation. The challenge is to be able to create systems that hold leaders accountable, but accountable for making sure that the teams have what they need to be successful. That might be resources or people… it might be vision or direction… it might be championing them to senior leadership. The role of leadership and management is to serve the team… without that fundamental mindset, most of the other things we’ll try won’t hang together very well.

6. Continuous Flow of Value

However we do it, we need to make sure that the organization is delivering value on a regular cadence. This means that not only the team is delivering working software on a regular basis, but that any of the other teams required to deliver the product are delivering value as well. It means that all the work product, of all the teams required to deliver value, are delivering value, and their work products are coordinated and synchronized. If agile is applied to only a part of the overall delivery process, you won’t see those successes translated into better business results.

7. Value over Activity

Closely related to item 6… if all we do is use agile as another way of tracking activity, we are going to fail. Value to one team might look like activity to another. Sorting through what is actual value creation is an essential step to making agile work in any meaningful way.

8. Attention to Technical Excellence

This comes down to what does it mean to ‘deliver value’. When we deliver value, that implies that it is the value our customer expected. Attention to technical excellence allows us to write code we are reasonably sure is free of defects, that we are minimizing the amount of technical debt we are carrying over time, and that we are building quality and reliability and scaleability in from the very beginning. Attention to technical excellence actually makes us more predictable over time because we have a clear measurable way to define what done means, and a verification mechanism for making sure we got there.

9. Rapid Risk Reduction

If we are only focusing on business value, we are missing an essential part of the equation. Key to the messaging behind agile is that, at some point in time, we need to understand what we are going to get for the time and cost the business is willing to allocate to the product. That means that we have to sequence our delivery taking risk into consideration. The teams that can quantify, manage, and elimate risk the fastest are going to be the more successful teams over time.

10. Early Feedback and Adaptation

It doesn’t matter how fast or effectively we are building software if we aren’t building the right product… or we are building a product that our customers don’t want to use. It is essential that we construct a means of getting product in front of our customers early and often, and have the opportunity to take what we learn and factor it into the plan.

11. Total Openness and Transparency

There is no hiding in agile. People can’t hide. Progress can’t hide. Metrics can’t hide. Poor quality can’t hide. Risk can’t hide. Impediments can’t hide. At the end of the day all agile can really do is show you the problems your organization has building software. At the end of the day it is up to you to fix them. Without total openness and transparency, we cannot take what we are learning and do anything about it. We have to have the mechanism in place to see what’s going on.

12. Trust

Agile without trust is something else besides agile. We have to create an environment and a culture where we can rediscover how to trust each other. We need to be able to count on each other to do what we say we are going to do, how we said we would do it, and when we said it would get done. Trust has to exist at the interpersonal level, within the team, and across teams. Failure to trust is a primary reason that we have such a hard time letting go of so much of the traditional control strategies many of us have put in place to try and be successful.

You’ll notice that nothing in this list specified a ScrumMaster or a Product Owner. I didn’t say anything about TDD or BDD or acceptance test driven development or even pair programming. I didn’t say that we had to do daily standup meetings or retrospectives either. Any or all of those might be helpful, and they might help you deliver against any of the 12 points I mentioned… but I don’t believe any of them are essential to being agile, becoming agile, or staying agile.

What do you think… is there anything you would add to the list? Any you would combine or leave off? I’d love to hear your feedback.