Enterprise Agile Transformation Reality Check: The limits of “cookie cutter” enterprise agile transformations

Accomplishing a lasting enterprise agile transformation requires more than some budget, superficial PMO support, some certified scrum masters and lukewarm executive sponsors.

Lasting agile transformations are an enterprise culture change, where all key leaders, stakeholders and organizations must be open to genuine introspection and collaborate in a flexible manner. If the organization is not prepared to leave their respective comfort zones and embrace agile values and principles, a different set of software development practices will likely produce minimal desired productivity, creativity and cross functional alignment results.

Agile transformation work is indeed a four letter word, and an effective and long lasting agile transformation requires genuine leadership, engagement, grit, openness and energy. When organizational leaders (business, product management and software development) and team members bring these assets to the table, amazing results, shifts and empowerment can occur!

Agile design and development principles meet enterprise IT infrastructure: The irresistible force meets the immovable object!

From enterprise data warehouses to OLAP cubes to Cassandra and mongo dB analytics platforms, we are not in Kansas anymore. Agile teams and practices are being pushed and prodded and pleaded and threatened by business units with unrealistic time to market needs, CIOs with enterprise class legacy system obsolescence and frustrated and overwhelmed architecture VPs – how do we apply agile principles and practices to these super-sized work efforts?

Do 2 week iterations apply to our work, or can we make them longer?  How much documentation is appropriate for this class of work?  How do we create vertically slices stories that can be implemented in iteration?  How do we test these technical or infrastructure stories?  How do you express infrastructure work as business user stories, and how should the narrative be written? How can we support iterative product development and still design our platforms and services for high availability, scalability, maintainability and reasonable TCO (total cost of ownership)?  The questions never stop, and these challenges are real and these folks need help; and they need it now!

Product management leaders and executives want to understand how agile methods integrate with traditional UCD, UX, Ideation and Discovery work.

QA leaders want to understand the agile approach to automated unit testing, manual and automated functional testing, integration testing, stress and load testing and user acceptance testing.  And how do all these levels of testing work together, what should be completed in a specific iteration, and who owns what anyway?

The life of an enterprise agile coach or agile program manager is never boring, and it is rarely simple.  In the coming weeks this blog will explore practical thoughts and solutions to address these “upper division” agile topics and challenges.

Cheers and Happy Monday,

Paul

Self managed teams vs. command and control style project management

One of the most powerful, challenging and subtle principles of the Scrum process is the notion of self managed teams.   It does not take the experience of too many scrum projects, programs, organizations, etc. before it becomes clear that this change is nothing short of a true paradigm shift!
In larger organizations, the well developed command and control management structure and culture does not prepare new scrum teams with the awareness, skills and confidence to easily adapt to working on self managed teams.   On the contrary, many of the cultural mores go against the principles, skills and techniques required when adopting self managed teams.  One concept that is often problematic is the notion that the team (and therefore all of the Scrum team members) is responsible and accountable for the results of each Sprint.  In many organizations, accountability is more likely to be avoided or ambiguously shared then fully and clearly embraced.

Therefore once the basic scrum process, ceremonies, etc. has been learned by the team, then the more subtle capabilities required by Scrum such as self management begin to become more visible and noticeable.

Common sense dictates that if organizations and scrum teams want to enjoy the potential order of magnitude productivity improvements of the Scrum process they need to migrate from the command and control style project management (PM becomes a constraint to the productivity of the team) to the self management style where many team members can share in the planning, facilitation, follow through, etc. for the team.  In this case much more work can be planned and completed by the team when it is not single threaded through a traditional technical PM.

Fortunately, newly forming Scrum teams that have effective leadership and facilitation will be able to adapt to the principles of self management, shared leadership, etc.  Some simple techniques to help the team understand and develop these skill can include rotating daily stand up facilitation, requesting that various team members share in the defining and updating of work tasks, and  where every possible rotate roles within the team, etc.

In addition to removing the single threaded constraint an even more powerful benefit is that once the team begins to master the self management principles and behaviors, the scrum team can better align itself and ride the energy and inspiration of a number of team members instead of always requiring the PM to lead and drive in this regard. The end result of this transformation (yes, I mean transformation) is significant and much more sustainable over the long team (Less individual burn out).

Cheers,
PR