As a software development blogger, I often write about ways for teams to adopt agile practices or be more agile. There is no single way to be agile. There are many. There is no best way to be agile. There are multiple. What can your team do?
Ultimately, software development teams must establish rules and procedures that work for them. They have to be able to embrace the development process and make it their own. If they can’t do that, they won’t succeed.
Here’s a true story about revising a business process.
Recently, I was involved in a series of meetings where we reviewed an established business process and discussed ways to improve it. There’s always room for improvement, right? There certainly was in this case.
It quickly became apparent that there was a fundamental problem. The business stakeholders and the process implementors were in conflict. They had different priorities and interests.
The highest priority for the stakeholders was maximizing revenue. The highest priority for the process implementors was customer care. I could argue that you can’t have one without the other but that should be obvious. Two things became crystal clear:
- If the financial objectives of the stakeholders couldn’t be met, the business initiative would be cancelled and the process implementors would be out of work.
- If the implementors couldn’t provide the level of customer care that they were committed to, discontent would prevail and employee turnover would be high.
What’s the solution? The needs of both the stakeholders AND the implementors MUST be satisfied — whatever it takes. Thankfully, I was able to offer a solution that appealed to everyone.
Focusing on what people need makes a difference.
The same type of problem occurs in software development teams. Management wants the software delivered in less time, with better quality, at lower cost — no surprises there. The software developers want to solve problems, write good software, and avoid administrative impediments — no surprises there either.
Management needs the development process to be controlled and transparent. The team needs the development process to be lightweight and non-intrusive. The needs of both sides MUST be met and they CAN be met if everyone is willing to negotiate and compromise.
Conversely, if the needs of either side aren’t met, quality will suffer, costs will increase, and morale will decline. So, what can your team do?
The software development process must be openly discussed with all parties having a vested interest in it — developers, testers, stakeholders, end users, and managers. Everyone needs to buy in to the approach. Everyone needs to understand their roles and responsibilities.
I’d rather sacrifice some process agility in the interest of engaging the key players rather than argue for a more agile approach that alienates some of them. Here’s my recommendation:
- Start small. Don’t try to change too much at once.
- Move fast. When you obtain agreement on a change, take immediate action.
- Demonstrate success. Make noise. Get the word out regarding improvements.
- Keep evolving. Build on success and keep changing the process.
- Keep succeeding. Focus on low-risk changes and a continuous improvement mentality.