Large enterprises have lots of rules — do this, don’t do that, ad nauseum. Thus, it’s no surprise that software development teams in large enterprises are forced to follow lots of rules — document this, approve that, wait for something else.
Then, along come the agilists promising a better way. You can build software systems without all those rules. The work will be done better, faster and cheaper. What’s not to like?
Of course, the defenders of the current organizational structures will resist. They’ll say you can’t build complex software systems in the midst of chaos! There have to be controls, rules, checkpoints, approvals, hand-offs, etc.
As usual, both sides have valid points. Too many controls and excessive oversight increase waste and lengthen time to market. However, eliminating all controls and oversight creates confusion and increases rework. True agile development is about finding the proper balance for your situation.
You need to flow with the rules.
When you review the Agile Manifesto or the Scrum Guide, you won’t find lots of rules. There are mostly principles and guidelines. That’s not a mistake. It’s intentional.
Enterprise software development is a highly complex undertaking. It’s a unique mix of computer and human engineering. Some aspects of it can be governed by rules but other parts need room to flow.
You have three choices:
Option 1: Keep all of the existing corporate rules and controls. Fit agile software development into the existing corporate structures.
Let me be clear. This is a terrible idea! Why bother changing anything? If your goal is to protect what already exists, forget agile development. I don’t want you claiming to be agile and giving the rest of us a bad reputation. Let it be.
Option 2: Toss all the existing rules and controls. Start writing code and see how it goes.
Good luck with that! While working software is the most important measure of progress, getting the software to work requires at least a few control mechanisms. We want agility not chaos. Furthermore, senior managers need some guidance on what will be delivered and when. After all, they are running a business that funds your paycheck!
Option 3: Start simple. Minimize complexity. Add rules and structure as the team matures.
That’s agile! Do a few things well. Add more in time. Assemble the right team, manage the backlogs, meet every day, review each sprint, conduct retrospectives, and agree on a solid “definition of done”. That’s enough to get you started.
Is agile development easier than waterfall development? No! Is it better, faster or cheaper? Better? Yes! Faster? Not initially but it can be if you get good at it. Cheaper? Software development and support costs as well as value to the business are notoriously complex. Your mileage may vary.