So you want to be more Agile?

Posted 2012-07-14
Written by Matt Frost
Category code

I have this budding frustration when it comes to agile.  It's not with the methodology itself, I quite like a lot of the tenets of the agile methodology.  More and more however, I get the sense that making the announcement, "Hey we're agile" is how most people think they get there.  This coupled with the idea of "selling agile" frustrates me to no end.

Changing the way you operate takes a ton of work.  The idea that becoming "agile" is a quick re-examination of tools, or a couple quick process changes is misguided and will lead to frustration, confusion and probably the breakdown of you team, both mentally and in the literal sense.  So if you're going to commit to being agile, there's some things you probably want to know about what it's going to take.  I believe that it is worth it, but I also believe it's difficult to implement it correctly.

When you go from siloed lawlessness to a formal process, your team probably isn't going to stay intact.  I'm not trying to be cryptic, you'll probably end up having to get rid of people.  It's not inherent to the process necessarily, but every team seems to have at least one person who doesn't/won't/can't change the way they work.  If you're really going to stand behind the line in the manifesto that favors people and interactions over process, you have to get rid of the people that don't compliment the team well.  It sucks, it's no fun; but I'm being idealistic here as well.  If team members aren't going to be willing to make the necessary changes, you've got to get rid of them for the sake of the rest of your team.   Nothing, nothing, nothing will sabotage your team like an uncooperative team member.

You've paid your dues, made it all the way to the top and are the head of your department. First of all, congratulations!  Now, get out of the way while we work.  Seriously, the role of project manager these days isn't as glamorous as it used to be.  The role of the project manager is to ensure that your team has the information and tools that they need to complete the work, that's really it.  If more information is needed from the client, you call them and get it and pass it on to your team. It's not your responsibility to check on each individual team member to make sure that they're being 100% utilized at all times, leave that to team accountability and go the route of the previous paragraph. The determination for whether a project manager is successful solely lies in their ability to get information to their team as efficiently as possible.  This also means you should understand what the team is doing and some of the technical lingo they use, if they have to translate your request; you're not helping them be efficient.

I was told process was a bad word in Agile, simply not true.  Favor people and interactions over processes, by all means!  But if you don't have certain processes in place, you're going to end up where you started.  Most people don't want to be told how to work, now there are reasonable exceptions to this adage; this is what you should build processes around.  Developer A has always worked directly on the server with a text editor and an FTP client. You implement a version control system and means to stop that person from working directly on the server; now you have a process of how you get code to production environments and it's totally reasonable.  If Developer B has always worked in NetBeans IDE and you make a company wide policy that everyone must work in Zend Studio; you've crossed the lines of reason.  Processes allow you to ensure that code is created, tested, deployed, and maintained the same way each time. If you have good processes in place you can limit the damage a rogue developer would normally inflict.  You need processes, but if you can't provide a rock solid reason for one; you're better off re-thinking it and probably scrapping it.

Working software over documentation, makes sense; spend more time ensuring the product is delivered correctly.  Documentation, both internal and external, is important; this line in the manifesto is simply stating that comprehensive documentation isn't worth the paper it's printed on if the software doesn't work.  That's all it's really saying.  It's not saying don't provide documentation.  Internal documentation would include unit tests, code comments, project wikis and blogs; while external documentation would be a bit more casually worded in PDF, blog, or wiki format.  If the person you are writing the software for doesn't know how to use it, you haven't provided working software to them.  Providing working software with appropriate amount of meaningful documentation is a challenge, but it's a necessary requirement.

When Agile is "sold", we don't like to point out the fact that it's typically going to cost them more money.  It does, and if you really implement the XP side of the agile development processes, it becomes more pronounced.  We're told to favor customer collaboration over contract negotiations, see here's the tricky part.  If you work in the consulting field, where people are paying you to develop software for them you have to obtain their business.  I've yet to come across a client who hasn't asked, "how much is this going to cost?"  In order to get their business, you have to either give them a number they like or explain to them why the number they don't like is worth it.  So now whether the client understands the agile component of the development, there's a number attached to it.  If you exceed the number beyond a reasonable amount, they've been betrayed by you.  This is where the project managers have to understand the project, they have to be able to communicate that, yes while we're flexible to changing the scope in this area, it is going to affect the price/timeline/iteration.  If you aren't communicating this already, you should start now.  The conversations suck, but the "you put us through the ringer" conversations seem to be less fun.  So while you certainly don't want to write a contract up for every little change, it's important to document scope changes and have regular conversations.  If you can communicate clearly what the effect of the change will have on everything else, you empower the client to make their own financial decision.

Responding to change over following a plan, the only thing this really says to me, is code defensively. A lot of times this simply an issue of code quality and nothing more nothing less.  Unfortunately, a lot of teams don't take the time to have design conversations or they aren't equipped with developers capable of having that conversation. Developers need to know how to write flexible, reusable code and there needs to be time built into the project to have those discussions.  There's always a plan, so don't fool yourself into thinking you can avoid committing to requirements or that requirements aren't a plan.  If you write stiff, inflexible code because you're just following what the requirements say; you're going to get bitten hard. Encourage design conversations, regular code reviews, and an agreed upon coding standard; create an environment conducive to learning.  You'll be happier, your clients will be happier, and chances are you'll get to work with some of that flexibility as your clients continue to give you more work.

There's a lot here, and there is much more that could be said too.  A lot of teams can't commit to making all these changes, and you know what that's not always bad. Simply stated, agile isn't the only way to do things and depending on your client needs, team structure, and company culture; it may be an unwise venture for you.  I'm a huge proponent of using the right tool for the job, and I subscribe to the same idea when it comes to project methodology.  It isn't about this label over that label, it's about giving your team the tools they need to work efficiently and do great things.  There are some concepts of the agile methodology that you may just toss out all together and that's fine.  The idea isn't that you 'become more agile', it's that you become more efficient.  I've touched on the concepts in the Agile manifesto, as well as some concepts that I've experienced along the way, I'm hoping it's been helpful to you.  Please feel free to comment or tweet at me and let me know what you think.



There are no comments

Posting comments after has been disabled.