I was trained up in the way of large and very large corporations, particularly in software management pedagogy.
- Document hierarchies
- Design hierarchies
- Architectural hierarchies
- Process and procedure hierarchies
- Steering committees
- Change Control Boards
- Change and Configuration Management standards
- People hierarchies
- Standards Boards
- Design, Development and Test standards
- Inspection standards
- Project Management expectations
- Product Management expectations
- Matrixed organizational expectations
- Things my mom expected and so on
The real problem had everything to do with the problem of scale and nothing to do with the processes or people themselves.
If we assume that people are generally good and want to do the right thing, and that processes are usually by-products of good people trying to do good things, then how do good people produce well-intentioned process and procedure paradigms that make people hate the journey so badly they want to die?
With scale comes complexity. With complexity comes complex management behaviors. Complex management behaviors beget overhead. Eventually the overhead becomes the project.
Historical solutions for managing scale have required sometimes extreme process and procedure declaration, as well as, micro-management. The bigger the project, the more moving parts. The more moving parts on a project, the more people in leadership are inclined to screw down on the moving parts in the interest of control and information gathering. Screwing down does not increase quality, control costs or guarantee time-based deliverables. In many cases, it precludes it.
People, leaders and team members alike, continue to look for new and better ways to deliver very large, very complex software projects. Understandably so. Agile communicates itself the solution. Is it?
Enterprise Agile matters because the currently published Agile cloud behaviors do not scale. Otherwise stated, today's published materials on Agile, with the current exception of Dean Leffingwell's book Agile Software Requirements, do not adequately answer the questions of, nor scale to existing levels of enterprise organizations accustomed to high-assurance process frameworks. Most of today's published books in the Agile space do indeed teach very important, very critical behavioural concepts, but they do not show us how they all come together into a synthesized set of behaviours that fit into the larger 1000+ person enterprise. One agile team, project or department does not an Agile company make. Until the enterprise itself (including executive management, sales, marketing, support, product and project management) takes on system-level contiguous behaviors centred on continually prioritized objectives and uninterrupted iterative deliverable flow, micro-implementations of agile, though important, will struggle to change the culture of a corporation and may kill itself trying.
If Agilic behaviors are any good at all, it is because of the people. Success happens because of people. And as teams, project, programs and companies scale, so too must our delivery behaviors. Agile behaviors work and there is ample industry data to support it. However, out of the box, it doesn't work at scale no matter how many good people you have in a closet. There is a need for Agile implementations scaled up to large and very-large enterprises addressing, not only the software engineering needs of a large organization, but the operational deliverable culture itself.
How many of your large or very large corporation's project problems are actually technical? More likely, they are sociological, political, culture and operational. How much of your large project budget is attributable to deliverables versus behavioural constructs and associative staff put in place to aid in delivery?
There is a better way. Good people in good enterprises are looking for it. In order for Agile to meet the need, it must scale to meet the demands of good people who will solve their problems one way or another.