You Need Processes and Tools
Even in an environment where you have a single, ideal, co-located cross-functional team, I believe you’re going to need processes and tools. The more complex and distributed your organization, the more processes and tools you’re going to need. Doesn’t sound very agile does it? Well, get over it. You’re going to need processes and tools to enable individuals and interactions. If you can’t sit in your chair and make direct eye contact with everyone on your team, you need more processes and tools. Hell, even if you can see everyone, you’ll still need processes and tools. What is Scrum? A process framework. What is a team board? A communications tool.
I’m not dismissing the Agile Manifesto. I do prefer individual and interactions over processes and tools. I’m just trying to establish some context. Most of us don’t work in that ideal agile world. Rather, we have to operate within a series of non-ideal organizational constraints. Most people are sold on the idea of Agile. The values and principles resonate with us. But my job (and LeadingAgile) is to understand the goals of an organization and help them reach them. We start by laying the foundation for an agile enterprise by forming teams and installing a Lean/Kanban based governance model, but maintaining focus on longer term planning, risk management, and dependency management.
Before laying the foundation, I look at their current organizational structure, I look at their current governance (processes) and I look at their current metrics to see how good that structure and governance is working out for them.
Future State with Process and Tools
Whatever the future state looks like, I expect two things to help get us there.
1. We need to provide clarity by making process policies explicit.
2. We need to demonstrate incremental improvements by using tools.
Do you agree with me? Maybe you disagree with me. I’d love to read your feedback.
I tend to agree – I do like to have the bumpers set as wide as the organization will allow so that the teams involved have as much space as they can get to make decisions within. Some areas will be more narrow (other constraints etc.) and others will be very very wide, but the wider the better in my opinion.
Process always gets a bad rap. In many people’s mind process = bureaucracy. But consider, these are typically the same folks who think Agile is faster and takes no planning.
As a process owner we do our best to provide a framework of guidelines and practices than keep folks aligned but do not stifle creativity or execution. It’s a tough balancing act but so necessary in our very large enterprise.
Same with tools. We standardize to keep teams literally on the same page. How effective would it be to have our product, technology, IT and Network teams all using different Agile tools?
With so many different departments we are all about compromise. Getting an ‘I can live with it’ is a huge win.