I cringe whenever I hear an executive or a manager say something like, “Yeah, we got some development teams doing that agile thing.” Which is usually followed by something like, “I don’t know what the impact is, but we have a directive to have more teams doing agile.”
There are so many problems with those two statements my head usually starts spinning…
“What exactly do you mean, you are doing agile?”
“Why are only the developers participating?”
“What metrics are you using to verify improvement?”
“Who made the directive and how are they helping the organization succeed?”
“Did you provide any training or coaching?”
“Did you hire any agile consultants with actual experience doing agile transformations?”
“What problems are you trying to solve?”
“How often do the teams produce working software?”
“What practices and processes are you using that make you agile?”
And so on and so on.
The most important thing you need to accept for an agile transformation to be successful is this – agile is not something you do, it is something you are. Let me repeat that. Agile is not something you do, it is something you are. Actually, in many cases, agile ends up being something you are not. But let’s stay positive.
What makes you agile? In order to answer this, let’s take a look at:
- What is agile?
- What makes an individual agile?
- What makes a team agile?
- What makes an organization agile?
What is Agile?
Agile is set of values and principles. These have already been defined somewhere, haven’t they? Ah, yes, any good agile blog should have at least one reference to the “Agile Manifesto”, so here goes… You can read the “Agile Manifesto” and its:
By the way, I’m wondering why they don’t have a better webpage yet? Seriously, it’s been over 11 years! But it really is good stuff and these statements are pretty widely accepted by agilistos. Of course, there is always room for continuous improvement, right? For example, I have seen some great updates made by http://disciplinedagiledelivery.com/.
Be forewarned though, just reading these values does not inherently make you agile – it can only make you agile aware. True agility can be achieved by embracing these values in the software disciplines and methods you practice. Heck, I even find myself applying agile principles outside the IT world and in my personal life, but that sounds like another blog post for another day.
What is Scrum?
Agile is not any one specific software methodology or process. Scrum is currently the most commonly adopted agile methodology for agile transformations. This is primarily because it is very straightforward, focuses on project management, and there is a plethora of “experts” available. We won’t even get into the joke that is the ScrumMaster certification test. The problem is many teams try to do Scrum without understanding the underlying core agile values behind Scrum. They don’t realize the discipline that is actually required. Inevitably, these teams are unable to adapt to changing conditions or scale to more than one team. And then we are forced to invent terms like water-scrum-fall, scrum-but, and fr-agile to describe the mess they’ve made.
What is Lean?
It seems like speaking to organizations about Lean can be easier to comprehend than agile. Lean never pretends to be a silver bullet process. For those unfamiliar with Lean, pause a moment and check out wikipedia. As is often the case, wikipedia provides a fair enough introduction at http://en.wikipedia.org/wiki/Lean_software_development.
Lean is a set of principles –
- Eliminate Waste
- Amplify Learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- See the whole
These principles can easily translate into goals for a team or an organization. And the best thing about goals is even if you never reach your goals, you can still make significant improvements trying to attain them. Agile and lean are very complementary, so don’t worry about having to be only agile or just lean. Be lean. Be agile. It sounds sort of like a prescription for IT yoga, doesn’t it?
What Makes an Individual Agile? Experience counts!
When someone allegedly reputable tells you they can teach you Scrum in 15 minutes, what they mean is they can teach you the Scrum roles, ceremonies, vocabulary, and timelines in 15 minutes. And they probably can. However, it should come as no surprise there is much more to being a ScrumMaster than memorizing a few practices. Scrum is not taught in the pages of a book. A solid book with deep experience reports is a great place to start, but reading can only get you so far. (Geek comment alert.) Reading about Scrum is like adding more cores to a machine to get performance improvements running an application not designed for multi-threading. Scrum is really only understood and mastered through actual Scrum implementations with actual people and projects with actual goals and deadlines. This goes for more than just Scrum too. Be careful selecting your agile coaches and mentors and make sure they have the appropriate experience. This should not be too much to ask. Agile is already mainstream and as mobile development explodes with very short feedback and delivery loops, agile will be pressed even more into action.
What Makes a Team Agile?
It is pretty easy to see whether a team is agile or not. Agile zealots will argue their beliefs religiously and righteously declare, “You’re not agile!” Well, often they are correct. There is a whole pile of agile practices common to agile teams and you can find a good number of them here. It is also pretty easy to spot agile anti-patterns. As a developer with IBM in the early 2000’s, I can describe in detail many of those anti-patterns. (oooh another good blog topic). I can also understand why the zealots get so defensive. They have invested in building methodologies and when projects fail, they want to make sure the blame is on the people, not the process itself. “Who made you a process expert?” And the truth is, maybe they are indeed not software delivery process experts. But, shouldn’t the goal be to grow the agile community and help those teams understand how to embrace core agile values?
What Makes an Organization Agile?
I have hinted at this previously, but let me state it explicitly. Agile is not solely about the development team, it is about the organization. The testers need to work hand in hand with developers. The architects need to come down from the ivory tower and join the teams. The business analysts need to stay involved and collaborate with development. Discussions and demonstrations need to be ongoing and repeated. Project managers need to relinquish command and control practices. Executives have to adopt new metrics and change organizational structures. Traditional role boundaries start to bleed together and disappear. This is what makes agile transformation much more difficult than deploying agile from inception at a small startup. Organizations and people are resistant to change. Or so it is said. In actuality, change is unavoidable, and even more so, change is welcomed all the time. What organizations are really afraid is losing control. How do we keep control during an agile transformation? That sounds like another good blog post and may even make use of an agile swear word – governance.
What Makes You Agile?
How would you answer that question? For me it is not about the ceremonies or practices, but rather the underlying core values and principles. Agile is a maniacal focus on responding to change, collaboration, quality, working solutions, providing value, and broadening skill sets.
Go. Be lean. Be agile. Just don’t be fr-agile.