Agile adoption in the real world. Not many people can fathom walking up to their manager and saying “I want to completely change everything we do about software development. I want to write almost twice as much code as I currently do with no more functionality. I want to pair program. I want to take away cubicles and make everyone work at conference tables. I want to demo what we’ve done for the business every week.” However, in many companies, proposing that you want to begin developing software using Agile processes sounds exactly like what I said. My intent over the next few posts is to show you a way to introduce the concepts of Agile without having to look like the nut job on the team or move mountains.
I’m sure you’re thinking, “Yeah, right. I’ve read tons of those articles before and they work about as well as something I would buy from Billy Mays.” Everything we will talk about over the coming weeks are things I have seen be effective in a large, Fortune 500 corporations. However, before we dive into the specifics, I wanted to spend this post defining what I said we were going to talk about…agile practices in the real world.
“Agile practices”. That means paired programming and writing on the walls and stuff, right? Wrong. For this blog, agile stands for four main principals (from the Agile Manifesto):
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
This blog will discuss how to implement the above four tenants in a large corporation.
“in the real world”. This means that the CIO has not come down from on high and decreed that agile is the new required practice and all projects shall be agile going forward. This rarely happens (and would make adoption much more easy) so let’s assume it hasn’t happened for you (if it had, you wouldn’t be reading this anyways). No, instead we are going to assume that you, Joe dev or other lower level employee can see where agile can be useful and want to apply it to make your life and your customer’s lives better.
I have gone both routes. I have had buy in from the very top and I’ve had management that disdained the word “agile” much less supported a test project. In both cases, you can be successful with agile. I’ve also seen the same approaches fail horribly because those implementing the process didn’t know the why behind what they were implementing. I will be sure to cover this as well. Please note, implementing practices without knowing why you are implementing them is a recipe for disaster. Any practice you implement should start with “What problem is this change attempting to solve?”.
A word of caution. Change the way I will describe is slow. However, with each step, the next becomes easier. I look forward to sharing my experiences with you. I also look forward to the comments you leave.