In the last post we discussed selling agile development to customers, product owners and management. Today we’ll address the ins and outs of selling agile to your team.
Teams who are new to agile project management have unique objections, along with questions around how to manage IT support functions or other non-development related tasks that developers have to do. Here are some of the most frequent issues and questions:
Yikes! Too many meetings!
Often, developers end up going to agile meetings in addition to meetings required by the old waterfall processes. Of course, that doesn’t leave much time to get actual development work done. Which meetings are not required by your agile approach? Are you getting anything out of them? If not, you probably don’t have to be there.
Some people are worried that daily standups will become hour-long status meetings, and that can feel like micromanagement. But standups are intended to be no longer than 15 minutes, and if they drag on endlessly, you’re doing it wrong. Elect a timekeeper or a scrummaster to help keep everyone on track.
How do we work with non-agile parts of the organization?
There are a few different ways to approach this, including the “agile sandwich,” which uses waterfall practices up front, agile development iterations in the middle, and a production-readiness iteration at the end for documentation and architectural review. if you have to work with a non-agile development team, it can be incredibly difficult – build in extra time to do workarounds and mockups to help the waterfall team keep up.
If we don’t do detailed planning, our architecture will fail!
Contrary to popular belief, agile software development does involve preparing detailed architectural vision. But it’s usually at a higher level, and it’s not implemented all at one time. Agile builds in slices instead of layers, so a little bit of everything is included in the complete, working feature. Build an architectural runway 1-2 iterations ahead, and leave the infrastructure in place for the next section.
We can’t do agile, we’re not colocated.
You can do it, and do it well, but it takes a little extra effort. You will need some agile tools, good documentation, and outstanding communication. You may also want to do periodic checks to be sure people aren’t sliding back into waterfall without realizing it.
The unspoken reasons nobody wants to mention
I’m afraid of change. I might lose my job. I’ll have to actually talk to people. I’ll have to learn a new tool. I’m afraid of conflict. I’ll get fired if it doesn’t work out…and a hundred more. These issues need to be addressed, and it will be a little different with every team. Acknowledging these unspoken issues, having up-front conversations with your team and listening to their concerns is a major step in overcoming them.
Talking with teams about agile doesn’t have to be difficult. Selling agile is often best accomplished by not selling. Instead of polishing a sales pitch, it’s more about building trust. Be a living example, host brown-bag lunches, invite others to join you at local agile events, and socialize instead of evangelizing. There are a number of online resources to help you provide more information on the benefits of agile. If all else fails, hiring an external agile consultant to work with your team can be extremely beneficial in some situations.
Ultimately, you will need to listen — really listen — to the issues presented, and address them without using jargon. Overcoming resistance involves effectively answering the question, “What’s in it for me?”
For detailed insight into all of these concepts, you may want to check out Michele Sliger’s Selling Agile webcast. Michele has a passion for helping those in traditional software development environments cross the bridge to agility, and this webcast shares her wealth of personal experience and expertise in an approachable and knowledgeable way.
The post Selling Agile, Part 2: How to Get Buy-in from Your Team appeared first on VersionOne Blog.