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.
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.
I would add a Learning Environment.
The team has to improve its engineering skills, the domain knowledge and much more.
See what we do: http://www.planetgeek.ch/2010/11/23/learn-as-a-team/
I like it Urs. That will dovetail into a point I plan to make a little later on. Thanks for the comment.
I’ve been thinking about your bullet #3, single voice of the business, where you say “This cannot be shifted to the team…”
I tried very hard to make a short post in response. But I just couldn’t get it /short/. Due to length, I posted it on my blog:
Andrew, I replied to your post on your blog.
What does it mean shared accountability? I understand shared responsibility and I do not understand shared accountability. Accountability cannot be shared. Never. Am I right or not?
Here is how I look at at…
Responsibility is something the team has to take. Accountability is something that is imposed on the team.
I want the team to have shared Responsibility, but regardless… I am still going to hold them Accountable. I want them to be accountable for delivering what they say they are going to deliver, sprint to sprint. I will also hold them accountable for getting better over time.
I’m not sure I’ve got the final say on the language here… but do you get my meaning? How else might we communicate this?
This might be a long explanation before a question.
I am a business analyst for over 20 years, I was a software engineer for the first 15 years. iSeries / As400.
I designed relational databases, designed insurance systems, and insurance products, and did every type of project.
Decommissioning, green fields, data conversions, system migrations, etc.
I worked in teams with developers that knew exactly how to decide and design, define, build, test, and implement the most effective, efficient designs and code.
The system was designed as a framework with well-designed system structures.
A lot of people laugh at As400’s. This insurance system was used by very big players, Zurich, Hiscox, Travelers, Legal & General, etc.
Our projects went in with zero defects 95% of the time.
The point I want to make is the developers were very good, and understood what good efficient, and effective design is. The code was written once, and the developers we worked with, we trusted to deliver working, defect-free code. The designs hardly ever needed to be refactored, they were designed to be fully scalable. After investigating the code, the developer could estate in days how long the change would take. All the developers tested their own code, they were responsible if it went wrong they had to fix it (ie: responsible) if it caused massive damage yes they were blamed for their code. That made them vigilant and tested their code from every angle. Every developer wants to deliver quality code and understood the logic of code and systems, hence zero defects. The business trusted what we delivered every time.
Today I see developers who want the Gherkin code (Given, EWhen, Then) produced by the Business analyst. The developers then copy the Given, when, then acceptance criteria into cucumber (code tester) and run the tests until it goes green. They do not look at the User story (requirement) only the Given, When, Then acceptance criteria. then estimate in “points”. The testers write test cases with test steps. The tester’s evidence is just screenshot after screenshot of every screen they go through (*manual tests).
If the developers (10 years they have been developing) have not investigated the code; 1. how do they know what to change? 2. How do they know what the “points” are? (rhetorical)
Then when they delete 160,000 live customer records, they supposedly fix the code, it is retested (same tester) and passed. The code goes live and deletes another 40,000 customers.
This is not applying the Agile principles of good design and engineering, quality code, defect-free etc.
The main question:
If people cause system failure by being lazy or incompetent like this (developers and testers); What do you need to do to correct this problem?