Are You a Software Development Extremist?

Some of us tend toward extremism. It manifests itself in many ways in both our personal and professional lives. It could appear in the clothes we buy, the cars we drive, the way we work, or the way we look. In many situations, we’re not even aware that we’re extremists.

In software development, there are (at least) two extremes you should avoid.

One extreme is being rigid and inflexible regarding requirements, work plans, schedules, documentation, etc. Everything must be predefined and locked down. A change management (a.k.a. change prevention) process is used to see to it that nothing changes unless several managers agree to the change in writing.

The opposite extreme is letting every aspect of the project float. Nothing is locked down. Anything can change anytime. No single individual is ultimately in charge or accountable. The team wants to be left alone and succeeds or fails as a unit.

Do either of these extremes seem reasonable to you? If so, I’d love to hear from you so that I might better understand why you feel that way. I believe that the vast majority of us prefer to stay away from the extremes and seek out a balanced approach instead.

Because the focus of this blog is agile software development, I’ll direct my thoughts there. I see many definitions of agile development (in the form of Scrum, Kanban, Lean and XP) across the Internet.

Here are a few extreme misconceptions.

1. Agile development lacks controls and commitments — it’s chaotic. No it’s not. It’s fluid. Agile teams commit to deadlines, budgets and quality levels. Software features are allowed to float.
2. Being agile means eliminating project managers, business analysts, and system architects. No it doesn’t. Big projects still need senior people to guide the teams.
3. Agile teams don’t write specifications or documentation. Not true. They don’t waste time writing needless or redundant documents. They write documentation that matters.
4. You need an omnipotent Product Owner to be agile. No, Product Owners don’t need the ability to walk on water. They need to be skilled in solving a mix of technical and business problems.
5. The team has to be co-located to be agile. Just not true. With the right tools and the right management support, distributed teams can be just as agile as any other.
6. The project status board has to be a dedicated whiteboard with sticky notes. Actually, electronic status boards are fine. You simply need to invest in the right equipment and software.
7. Agile development does not work in regulated industries. Wrong. It takes discipline and structure to do agile development well. Those are also the qualities needed by regulated industries.
8. Agile developers are cowboys (or cowgirls). They just want to crank out code all day on their own terms. Nope. Anyone wanting to be a lone ranger should start their own company. Agile developers need to be multidisciplined and team oriented.
9. Agile development can’t be scaled. It’s for small teams. Agile development can be scaled though it’s hard to do well. The key is to start small and scale up using retrospectives as the continuous improvement tool.
10. Software architecture and user experience design are ignored by agile development teams. Ridiculous. Software architecture and UX can be improved through agile techniques. Start simple and add complexity as the software evolves.

Oh, and here’s a bonus extreme misconception for you to ponder.

• You can make your prescriptive (a.k.a. waterfall) approach to software development just like agile development by including a few agile best practices. NOT!