Disciplined Agile

In my experience in running dozens of process tailoring workshops, over several years, with of teams of every shape size and experience level and in different organizations, the most recurring comment is that the workshops “revealed all kinds of options we didn’t even realize were options!”   Although almost always a bit of a hard sell at the outset, I have yet to work with a team unable to quickly grasp and appreciate the value of these activities.

I had to do quite a bit of experimenting in order to get the timing and content of the workshops right – and learned over time that success is also predicated on knowing whom to include when. My first attempts were gruelling, close-to-full day affairs with entire teams in attendance, held at or close to project kickoff. Though transparent and inclusive, to my surprise this approach was actually deemed a waste of their time by many team members, especially those whose contribution would occur primarily in the construction phase. First lesson learned – A technical team lead, architect or senior developer can actually stand in for most of the developers in the early stages. I find it helpful to always bear in mind what George Dinwiddie (http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/) dubbed “the 3 amigos” in determining who needs to attend a process tailoring session. Be it at inception, construction, or even in transition, you need to tailor not only the processes, but also the attendance of the workshop in order to ensure you have the right mix of people, with the right collaborative mindset, to cover issues pertaining to 1) the business problem being addressed  2) the potential technical solutions to that business problem and 3) the processes (both team and organizational) that will enable the work to be carried out.

My second lesson learned pertained to the format and presentation of the process blades themselves. I found that simply working from the published process maps was insufficient, as we ran into onerous issues around how to best record the WoW choices teams were making. I eventually reproduced the entire process blade library in a spreadsheet format, with columns for comments. This seemingly innocuous administrative step quickly ushered in the third lesson learned – the sessions can be used not merely to document an immediate WoW decision, but also to identify future, more “mature” aspirational choices which the team can set as goals over a specified time period.

A fourth lesson learned, and one that was also enabled by using a simple spreadsheet tool, is that it became far easier to Align with Enterprise Direction. By “locking down” enterprise-level process choices across all the blades where applicable, a lot of potentially fruitless (at that point in time) discussion was saved for many a team. No use in discussing test automation strategies to death for instance in divisions still completely relying on manual tests, or at the opposite end of the spectrum, teams endowed with high-performing, well-integrated CI/CD environments. This is a large part of what DA calls self-organization within appropriate governance.

The fifth and final major lesson learned was to never start from a blank slate if at all possible. I would typically show up at a team’s first process tailoring workshop with a pre-filled version from another team facing somewhat similar challenges (the identifying data being scrubbed so they could not identify the previous team). I would then challenge the new team to reflect on the choices and determine whether they made sense for their own context. This also saved time and effort, as there are recurring themes and common challenges within organizations that all teams face.

Here’s an important note on determining participation – Ultimately, the teams themselves are the best arbiters of who should attend the sessions at varying stages of advancement. Allowing this will typically result in a bit of initial over participation, followed by under participation (especially is the pressure is on to get “real” work done!) – the key as facilitator is to coax the team back into balanced participation, and to lobby the organization for the necessary support in freeing people up. The support will become easier and easier to obtain as the benefits of allowing teams to choose their WoW become apparent.

Finally, be prepared for surprises. I once ran through the Program process blade with a team, only to have them come to the realization that … they weren’t really a Program! Which was actually a good thing as it helped avoid introducing a considerable amount of overhead, particularly in the area of program-level KPIs.

The Lean Enterprise genie has been out of the bottle for some time now, but for most organizations he’s still a long way from granting three wishes

The Lean Enterprise … Enterprise Agility … DevOps 2.0 …  BizDevOps … the list of monikers and descriptors for this concept is becoming a lengthy one, but there’s no denying that lean and agile concepts and practices are now mainstream, and pushing to break out of their former boundaries within software development.

Reflecting on this, I came across a very apt description (in, of all things, a conflict simulation design blog) of what seems to be happening in this realm of late:

“Most new ideas, however fresh or spontaneous they may appear at first glance, usually represent an evolutionary synthesis of previous ideas; in other words, when it comes to most things, history really is “preamble”.¹

The idea of bringing business, development and operations people to the same table to act as a tripartite coalition from the very start of product development has been gaining exponential momentum of late. As far as ideas go, it is not an entirely new one of course. Encouraging collaboration from the get-go has long been a hallmark of Agile approaches – in development for example, George Dinwiddie is believed to have coined the term “the three amigos” around 2009² to describe the interplay of developers, testers and business analysts / product owners from an Acceptance Test Driven Development (ATDD) perspective. However, other than describing a tripartite arrangement, the 3 amigos analogy differs from the most recent crop of expressions in that contrarily to say, BizDevOps, it only actually plays on two of the required three planes.

Another oddity that struck me is that one of the first high visibility discussions that I can remember describing the interplay of business, technology and operations actually framed the debate in terms of an antipattern: to wit, a July 2011 Forrester whitepaper which coined the expression “Water-Scrum-Fall”³ as a way of describing the very lack of cross-enterprise collaboration which bedevilled most organizations’ agile efforts.

The need for systems thinking

Unsurprisingly, a silo mentality is the biggest single impediment to achieving true Enterprise agility. Everyone involved in the creation and delivery of business solutions needs to collaborate across the breadth and depth of the organizational structure. Team-level agility in the delivery space alone will not deliver on the promise of the Lean enterprise; nor is DevOps enough. Business, IT and operations all need to break out of their silos and embrace systems thinking.

In both my practice and my teaching, I constantly strive to come up with metaphors that can convey the underlying meaning of concepts in ways that overcome resistance by reframing the issue at hand in a very different manner than what people may be used to. I would now like to share a metaphor that I have recently been using which has shown a lot of promise in terms of getting everyone thinking in terms of the whole system when it comes to the concept of the lean enterprise.

As discussed above, the system in question can be simplified as having three planes:

This however is merely … a triangle, and does nothing to convey the importance of intense collaboration. We need something more evocative.

Something with three parts, yet an indivisible whole. There is actually quite simple that we can use to convey this:

That’s right. True Enterprise agility is neither a sprint, nor a marathon … it’s a Triathlon.

What makes this metaphor work is simply this:

Although a triathlon is made up of three events, it is performed by a single athlete who must excel at all three to win. In this case, the “athlete” is not an individual nor a team, but the whole enterprise.

So, if our organization is reaching a point where it is proficient in delivery, there isn’t much more to be gained by continuing to concentrate all of our improvement efforts in IT alone – the Business side of things must be brought into the game as a full partner. The same goes for operations – even careful, collaborative prioritization backed up by competent delivery will not win the day if ready solutions must then linger for months in pre-production environments. Nothing ground-breaking here, just a fresh way of looking at the issue … no serious triathlete would sign up for the Ironman in Hawaii knowing that she faced daunting challenges in terms of her swimming, or was a less than competitive cyclist. The same must go for our “lean” enterprises. Until we can let go of the silo mentality and learn to act as a single “athlete”, we will continue to be bound by the shallows⁴ of Water-Scrum-Fail.

Endnotes

1. http://mapandcounters.blogspot.ca/2012/04/roads-from-smolensk-spi-dunnigan-and.html
2. http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/
3. Available at https://www.forrester.com/report/WaterScrumFall+Is+The+Reality+Of+Agile+For+Most+Organizations+Today/-/E-RES60109
4. Shakespeare of course. Julius Caesar, Act 4, Scene 3.