I want to thank the Washington DC PMI chapter for the opportunity to present the topic, “Scaling Agile within the Federal Government” last Wednesday, 27 September 2017. A diverse group of program management professionals attended and shared valuable insights about their own experiences with Agile adoption within the Federal government. You may download thepresentation below. You can read the chapter’s announcement of my presentation here. The chapter hosts many interesting speaking events throughout the year, a number of which I will be attending. I highly recommend participating as an attendee or speaker whether you hold a PMI certification or not.
A look back at a 1986 Harvard Business Review article provides insight into the roots of Agile and its application.
No, there isn’t a typo in the title. 🙂 The title of this blog entry was taken (borrowed?) from a very interesting article published in the Harvard Business Review from January 1986. Scaled Agile Inc. (the developers of SAFe) references it to make a number of points concerning how to best structure Agile teams. In particular, Scaled Agile Inc. references the article’s assertion that:
The “relay race” approach to product development [i.e., Waterfall] conflicts with the need for speed and flexibility.
That a holistic or “rugby” approach [a la Agile] where, “a team tries to go the distance as a unit, passing the ball back and forth” better serves highly competitive environments.
The things that strike me about this article are:
It was published in January 1986. A good 15 years before the Agile Manifesto was published.
All of the examples are product development efforts outside the software development realm: Xerox copiers, HP printers, Honda cars, Canon cameras.
The fact that they likened the process to Rugby (a foreshadowing of Agile-Scrum).
Fostering of “Self-transcendence” – Similar to the concept of Ba: an old Lean term brought to new relevance in Agile-Scrum and SAFe circles.
Emphasis on “Cross-fertilization,” known in Agile as “Cross Functional Teams.”
The article’s concept of “Overlapping development phases” roughly translates into the Agile idea that SDLC phases (planning, analysis, design, implementation, and maintenance) should not be separate phases at all but should, instead, be performed concurrently within a specified time-box (iteration/sprint), on a small scope of work, with overall system scope accruing incrementally and iteratively.
The recognition that for all of this to work, we need management to change away from linear and static product development thinking.
The recognition that, “A different kind of learning is needed.” By this they mean engineers need to have both deep skills and broad understanding to be effective in cross-functional teams that execute in less structured environments: “T-shaped skills.”
I recommend organizational leaders and managers read the article to gain perspective on the thinking that led to Agile, so they may better understand how to adopt it within their respective organizations. Engineers of all disciplines and current Agilists will also benefit from a better understanding of how real cross-functional, self-organized teams are formed and behave.
I consider myself an Agilist. I have been working within the Agile software development realm in different capacities/roles since 2008 and I whole-hardheartedly believe in the potential of Agile and Lean to dramatically improve, not just software/systems development, but also organizations that sponsor IT capabilities development. I believe that the success and ongoing effectiveness of any Agile implementation depends on closely hewing to the Agile Manifesto and the 12 Principles of Agile Software.
Now that I have firmly declared my commitment to Agile principles, I differentiate myself from those whom I refer to as “Agilistas.” In my definition of the term, an Agilista is someone who takes a binary, black or white view of what is and is not “Agile.” Believing that deviations from Agile practices they have learned and practiced cannot be Agile, some Agilistas stifle change and innovation in the Agile domain.
Others are strict literalists who treat published Agile best practices as instruction manuals that must be followed, to the letter, in every situation, regardless of the realities/constraints imposed on/by projects and organizations. They wish to ignore or change factors external to software/system development concerns to fit their “pure” Agile implementation.
Still others confuse attempts to enforce engineering discipline and address complexity in large-scale software/system development efforts with establishing burdensome and unnecessary processes and documentation (i.e., bureaucracy).
Many Agilistas decry “Agile frameworks” and “Agile transformations,” feeling that methodologies that go beyond the established canon of team-level Agile practices and techniques are inherently anti-Agile. In their minds, “proper” application of the canon, in the “proper” spirit, with coordination across teams via Scrum-of-Scrums (in the case of Agile-Scrum) is all that is required and desirable.
Too often, this desire to keep Agile simple and pure leads to exhortations that others “think” and “be” more Agile, without proposing how to do that in the face of technical, programmatic, compliance, and fiscal realities that constrain and shape all non-trivial system development efforts.
I am sympathetic to the frustration that leads to this brand of reactionary thinking. For a couple of decades, Agilists have had to witness and, sometimes, take part in failed Agile implementations misinformed by Waterfall software/system development prejudices and undermined by an unwillingness on the part of organizational leadership and stakeholders to embrace what I call Agile Zen:
The primary role of management is to empower those who actually deliver value to the customer and to create work environments and customer relationships within which these “value providers” are able to succeed and flourish.
No amount of Agile process mechanics, training, management tools, DevOps tooling, etc. will bring the benefits of Agile to organizations that ignore this maxim. Unfortunately, often it is not just ignored; it is outright rejected by leadership incapable of shifting towards a “servant leadership” orientation. Adoption of an Agile software/system development approach within an enterprise requires alignment between the work performed by Agile software teams and the program and portfolio level organizations that form and sustain them. In other words, Agile development becomes a forcing function for change throughout the enterprise.
This is why I am excited about SAFe. It is a framework for scaling Agile practices to the scale of hundreds of teams while adhering to Agile principles, enforcing engineering rigor through systems thinking, and ensuring long-term continuous improvement and ROI through the application of Lean principles. It includes and fosters approaches to Agile program management and governance based on Agile principles and addresses real-life enterprise/organizational concerns without sacrificing those principles. The future of Agile is in Agile scaling. I hope the Agilistas will embrace it.
Loading...
Reload document 
Open in new tab 
