Who is this article for?

All software development professionals will find interest in this article, but managers, CIOs and software architects will find the greatest interest.

Can Big Organizations Rapidly Change?

Think about the last big company you worked for.  Did it move fast?  Change overnight?  Did anything get done ‘quickly’?  Weren’t there gobs of jokes about the ‘bureacracy’.  Big companies run slow.  When they need to move fast they put people outside the organization or buy smaller companies.  Change is just not a priority inside a company like this unless it is facing financial issues and agile presents a significant challenge to the orthodoxy and bureacracy of such a beast. But is that a reason to not attempt agile in a large corporation?  No.  But it is a reason to have a different strategy for a change adoption.

Hybridization of Agile:  Pragmagile

Yes….but you have to be pragmatic.  What I mean is that you’ll need to realize that this bureacracy and the people in it were bequeathed their titles for a reason.  They’re successful, to a certain extent, because they know how to get things done despite all the red tape and foot dragging.  As an agilist, these people are not your enemies despite their gantt charts and stakeholder evaluation matrices.  They’re your allies, your tools to be upwardly managed.

So considering this I’ve compiled a list of tactics that I think may be helpful for any agilist hoping to succeed in a large professionally heterogeneous company.   Here they are….let me know if you agree?

1. Follow the principles of The Pragmatic Manifesto.   Key among these… is embracing everyone…not just the software development team.  See everyone as having value and being able to participate and contribute to your software development process.  Be pragmagile.

2.  Walk it, don’t talk it.  Show your company agile works.   Don’t go around preaching it and extoling its virtues when you haven’t even delivered one project yet.  You might even want to avoid the word ‘agile’ altogether and just say this is how I like to work:  meet every two weeks, go over any changes, hedge the risk that we don’t understand, and adjust project course as needed.

3.  Help your project sponsor help you.   Your project sponsor in a large corporation is likely a veteran of the company.  Don’t discount this as ‘stuck in the old  ways’.  They know stuff you don’t and they can help you stay in good graces with all the red tape barrons.   Keep a solid, open and agreeable relationship with your project sponsor.

4.  Give a little, get a little.  Another way of saying this…….don’t be dogmatic.  If someone doesn’t like some aspect of your agile approach don’t automatically write them off.  They may have good reasons for their objection, and by showing your concern and willingness to adjust…..you’re demonstrating a core tenant of agility.    If stand-ups are hard for people with back issues, then try a 15 minute conf call.   If the customer just can’t meet every two weeks, then try every month or on a more lucid schedule.  But above all…….be flexible.

5.  Focus on the goal.  Delivery of your project/product is what you’re after.  Not agile adoption by your company.  Maybe you’ll get this as a side effect, but honestly…….you probably weren’t hired to evangelize the enterprise. Furthermore…you can’t do it on your own.  Put your accounting hat on and think hard-ball.  Git-her-done.

6.  Seek to understand the culture and the history behind it.   Maybe your company doesn’t move fast on this software project because your building something that its enormously complex and could kill someone if not done right.  There may be very good reasons for stifling rules and countless reviews/approvals.  Work with the grain of the wood…not against it.

7.  Stop assuming everyone wants to be agile.   Worse yet, stop assuming everyone knows what it is.  They may have heard about it and chalked it up to no  more than a new process.  But those of us who’ve lived it know that the real change is cultural.  It’s a tough shift and it won’t happen overnight.  Be patient with those around you.  They’re trying to learn and you’re there to help them along.  Be prepared for the guy who says “Agile sucks and here’s why…”.  He may have valid reasons for his opinion and discounting him will only deepen his view.

8.  Figure out the commitment level up front.  I wrote about this in another article:  Are You Committed?   But, essentially the team is supposed to commit to the iteration at hand.  But….what does that really mean?  Commitment is one word with many different interpretations.  Don’t assume you know how much the team is willing to commit and don’t assume that the companies HR policies and benefits jive with the agile philosophy.

Summary

That’s it.  I know I probably should have run it up to 10 ( don’t all good lists round up to 10? ), but I’m not going to throw down fluff just to reach a number.   It’s been my experience that if you make agile work in an organization people will just naturally ask you:  what’s your secret?  Why do your projects work out while other projects fail?  If you get to this point then I guess it’s ok to preach a little bit, but step off the soap-box when you feel your head getting bigger.   😉