Learning Organizations

The Agile Industrial Complex is a lucrative business.

We need to figure out for every organization what might work in the long run, where the company might get to. One size fits all doesn't work.

Why does an organization want to become agile? Twice the work in half the time, right? Thanks, Jeff Sutherland. C-level execs want greater efficiency, more bang for the buck. Deliver more. Deliver Faster. Be more predictable.

Wrong. You want to become agile because you want to learn. You want to be sustainable, by being able to learn faster than your competitors. You want to de-scale the organization, make it flatter, delegate power to those closest to the problems to solve. It's a balance, then, of risk mitigation and improving ROI.

Frameworks like SAFe? don't seem to encourage learning. They don't flatten or descale an organization. Rather they tend to introduce even more processes and roles. Covering your walls with whiteboards and renaming your project managers to scrum masters doesn't make you agile.

So how to encourage learning?

• Short feedback loops should be your primary goal. User testing shouldn't be something limited to UX or business teams. Good engineers want to talk to users too.
• Meaningful retrospectives. Empirical process control is a core tenant of any agile process. People want to address the issues that affect them most.
• Continuous coaching. People want to spend time becoming better at what they do.
• Scrum Masters are mentors, coaches, facilitators, not project managers. Someone that anyone can talk to whenever they are facing a problem with the process. No matter what you call it, you need this role.
• Sense of purpose and ownership. Stakeholders throwing requirements over the fence to the development team doesn't help anyone. The entire team - designers and developers - should be involved from the start. From product discovery through to roadmapping and release planning.
• Non-hostile environment. People should feel safe to address critical issues and give candid feedback.
• Collaboration. Zero-tollerance for political games. No scripted collaboration.
• Transparency. People want information and data at all levels. No information brokers.
• Managers as servant leaders. Switch from someone who knows how to solve every problem to someone who supports the team that is actually solving the problem.
• Trust. Given the right support and the right tools, the team will deliver value.
• Respect. The roles, principles and processes should be followed, no matter what agile framework you're using. All too often the Product Owner role is demoted and made less effective. The product team are the experts.
• No status reports. Senior stakeholders should be encouraged to trust that the team is making progress, encouraged to join the daily status meetings, and should be educated on how to gauge status from a product backlog, how to use the tools available. Status reports are a waste of time that could be spent delivering value or running experiments, especially when sent to a limited audience via email. Most tools can automate reports.
• Empowerment. The team closest to the problem should be the ones empowered to make the decisions required to solve it.
• Job titles. A small, empowered, cross-functional team can have their effectiveness dampened if members within are labelled with seniority. Ideally, organizations are supposed to morph into a team of teams.
• Clear objectives. People want this. A shared vision. A clear strategy. Set priorities. The team should be value-focused, providing value to the customers and creating value for the organization.
• Product Teams, tasked with problems to solve. Not project budgets, tasked with covering payroll and perhaps some ROI. It's a different way of organizing everything.

Transition to a learning organization needs to be both top-down and bottom-up. It has to be a shared goal.