Friday, July 23, 2010

Agile myth busting

In my daily work as project manager for IT systems I work with a number of development teams. The current trend in development is looking at more flexible and faster deliveries. The goal is to avoid delivering a product which misses the target as far as the customers needs are concerned. To address this problem a more flexible or agile method is being adopted by a number of software producers. I do not claim to be an expert in the area but the method has a lot of very good techniques and ideas, and if used wisely I believe it would lead to fewer failed software projects. There are however a couple of myths about Agile development being propounded by some developers I have come across:
With agile development there is no need for project managers
With agile development there is no need for any specification before the development (ie coding) starts
Oh dear. Project managers are a dying breed and superfluous to development projects. Written specifications to start with are also of no value, lets get rid of the overheads and start the real work – building the solution!
These ideas seem attractive to some developers no doubt, but to me they sound like a bit of a recipe for disaster. Having heard this I did a bit of research, and was lucky enough to attend a course hosted by Mike Cohn, author of several books on Agile development and I am now proudly “scrum” certified. After this it was onto myth busting.
1 No project manager?
Well this is a truth with some major modifications. Agile suggests two roles in projects: A scrum master and a scrum owner. Some of the work of a project manager is divided between these roles. What Agile suggests is that on some projects the project manager will take the role of scrum master and on others a scrum owner. This is all dependent on the size of the project and the knowledge/interest of the project manager. I my world I spend a lot of time dealing with customer relations, budgets, reporting to internal and external steering committees, program management etc. Agile does not address any of these activities, but is focused on the day to day running of development. Therefore on larger development projects that are run using Agile you still need a project manager role. The name may be different in some cases but the work remains.
2 No written specifications before coding?
Not true at all! Agile lays down very good techniques for specification before and during development. The point of Agile is to not make huge detailed specifications before development gets underway, only to discover that the finished product, even though it fulfills the specification does not fulfill the customer’s needs. Agile therefore describes a method for making a rough written specification to start off with that is refined as development progresses in cooperation with the customer. In this way the method ensures that the delivered product is what the customer really needs, but not necessarily what the customer thought they needed to begin with. This has been wrongly interpreted as there is no need at all to define what the customer needs at the outset. It is defined, but not precisely, therefore enabling flexibility for change during the project.

So, disappointed as some people may be, we’re still going to need project managers and specifications also using Agile.

Myths busted?


Jonathan McCoig is an experienced project manager in different IT areas ranging from banking, finance, logistics to healthcare. He is PMI certified and currently heads a team of project managers..




Posted by

3 comments:

Anonymous said...

As the experiment into Agile at the company where I work cascades into chaos, the Project Manager has taken us into a Waterfall-cum-Agile nightmare where the Agile words are used but Microsoft Project is revered and estimates and schedules from the design document are strictly enforced.

I hope this is not the kind of project manager you insist still belongs in Agile. I think one of the original reasons for getting rid of the title was to reorient the thinking that "management" was not a command-and-control activity, but a facilitation and coordination effort; that Project Owners and Scrum Masters take most of the PM duties but become the servants to the project and the team, not the rulers.

Our own project manager points to the recent inclusion of the "project manager role" in the Agile roles and PMI's recent coziness with Agile, and says that it validates her methods. I don't think it does, but in this organization developers are still on the lower rungs. Nobody will listen to us.

Agile, I fear, has deteriorated into another power trip for the useless, and another impediment to quality. I have known how to do my job for 20 years and have used the principles in Agile for at least that long even though it wasn't called that until recently. All the while, the elite with either PM or EE titles have tried to turn my profession into line-workers.

At this point I pray that "Agile" dies and another buzzword takes its place -- espousing the same tenets and principles that Agile had in the past before it lost them while trying to become acceptable to the elite.

I would appreciate it if you could address what is obviously a very negative view of Agile in general and Project Management in particular. I will remain anonymous for obvious reasons. I put on a very different face at work. I need the job.

I'm sure you're a fine manager. You just don't work in my company.

Anonymous said...

Hello Anonymous!

Firstly, thanks for your comment which absolutely deserves an answer. You make a lot of good points in your comment so it’s difficult to address them all, but as a general comment it looks as if there is a management issue rather than a method issue (whether it’s agile, waterfall or another name).

I agree with you that agile (or any project effort) should be based on teamwork; not command and control or micro management via project management schedules. At the same time we are under time and money constraints to deliver what the customer ordered, so direction, coordination and decision making is needed. My mission whether I’m scrum master, owner, project manager or whatever is to deliver the goods and in my experience I can only do that with a team effort. Our developers and internal product owners (representing the customer) have in-depth knowledge of the system and processes to develop what the customer has asked for and I am therefore very much in their hands during the whole process. A large part of my job is to gather information from the customer, my development team, the product department, written documents etc., structure it, and then follow up the process to delivery. Agile offers a lot of useful techniques for this.

What you point out is perhaps a negative side of a management style to reduce software development to a production line resembling Taylor’s scientific management. At best this just de-motivates developers and at worst means that you’ll miss the target because you didn’t use the knowledge of the team.

Without meaning to sound too arrogant, I’d like to offer some advice to your manager:
• Command and control tactics, where as they may be necessary sometimes, will not motivate your team. They risk denigrating both productivity and the final outcome.
• Don’t try and apply time schedules religiously! There will always be an error margin. Plan with that it mind and make a buffer
• Build the team by consulting them on decisions, and empower them to take responsibility for their own work
• Encourage an open atmosphere where the team can come with suggestions and constructive criticism.
• Don’t be afraid to make mistakes! It’s called gaining experience.

Finally: whether or not I’m a fine manager? I think I would let the people I work with vote on that one.

Jonathan

Anonymous said...

Jonathan,

I appreciate your responses to my many comments. You are absolutely right when you say that the Taylor-driven management processes will demotivate a team. I fear this is one of those examples where the statistics will show us in the percentage where the management says "Agile Failed." But I don't think it's Agile. I think it's something else, too.

There's just so many opinions around about Agile now. You can pick who you want to reference and you'll have someone in the lime-light supporting your opinions. People will do what they want to do, regardless of consequences or evidence to the contrary. So be it.

I will do what I can to put your wonderful observations in front of my manager, but she'll know who did it (probably) so I have to be careful.

I still think it was a strategic error for Agile adherents to embrace the PM role and to cozy up to PMI. Project Management must grow and change, like all roles, to work in the Agile value system. A new name for a new approach (as I originally interpreted Agile/Scrum) would have emphasized the point. Putting the welcome mat out for the project managers, as has recently been done, gave the wrong impression around here, I fear.

At least I have a lot more questions to ask during the next interview. It IS called experience!