Posted on

Agile BS: The Productization of Agile

There is a preponderance of BS in and around the Agile community right now. Scrum has become productized, and ‘agile enablement’ firms touting that ‘agile is all we do’ are selling one or another variety of snake oil. Boston is a place where this is especially acute.

David Anderson, a guy who wrote a book called Kanban, is calling this out, and he is not alone. He spells it out here:

There is an initial assessment or appraisal…then some proposed future state envisaged…the new future state process is designed and it becomes the target outcome for the transition that is introduced and managed through the change management process.

This is a traditional 20th Century approach to change. It offers the reassurance of a defined outcome, and the outcome is envisaged either using a prescription from a text book, or by utilizing a model and designing a solution. The issue with this is that it assumes the problem exists in the complicated domain…

…It is ironic that the approach to Agile transitions has been a very non- Agile, big design up-front, make and follow a plan, approach. The fact that many Agile transitions are challenged and underperforming (and I’ve been saying this for at least 5 years now) may be that the approach being used is inappropriate to the domain of the problem. What we need is an Agile approach to change – an approach that incorporates feedback loops and evolves as new information emerges.

(See the full blog post here)

Andy Singleton, a friend of mine in Boston who makes great tools for distributed teams, is also on to something also, when he writes:

Pair programming:  Great for vendors, bad for customers.  Pair programming is like those girls that go to the restaurant bathroom together.  What are they doing?  If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time, to steal talent for turnover or new projects.  If you are customer, you pay twice as much and you get churn.

(See the full blog post here.)

These writing from these two gentlemen are pointing to the productization of Agile. It’s a sad state of affairs that appears to be encouraged by the Scrum Alliance and the Agile Alliance.

Organizations need to think for themselves and be responsible for their own learning. Each firm must create a custom solution from practices that are based on solid principles. David Anderson and Andy Singleton are on to something. One size does not fit all.

The productization of Agile is happening now. The message is: one size fits all.

And it’s all BS.

 

 

Posted on

Kanban and Tribal Learning

The book THE CULTURE GAME names 16 patterns of learning and describes a means to socialize them throughout your organization. These are called the Tribal Learning patterns in the book. One of these patterns is [Manage Visually]. The book devotes an entire chapter to this powerful learning device. Kanban is referred to frequently in this chapter.

Kanban is more than a simple manager of visual information. When policies are added to Work Item types via the Class of Service feature, Kanban as described in the book KANBAN by David Anderson becomes a powerful interactive game whose goal is to regulate the flow of work and thereby increase overall throughput. Getting into this in detail is beyond the scope of this post. If you are unfamiliar with Kanban I suggest you buy the Kanban book.

In my book THE CULTURE GAME, I describe interactions, meetings, Scrum, Kanban, and membership in social groups (such as teams) as games. But not the kind of games you may be familiar with.  This post summarizes what I mean. The book lays out a framework for “gaming happiness at work” and provides specific steps for doing so. Once again, these topics are beyond the scope of this post. You can learn more about THE CULTURE GAME book here.

This short post looks at Kanban through the lens of the 16 Tribal Learning patterns found in the THE CULTURE GAME book. Exactly how many of the 16 Tribal Learning practices does Kanban implement? The answer may surprise you.

I have identified no fewer than 12 of the 16 Tribal Learning practices implemented directly by Kanban. Not only that, but 3 of the remaining 4 Tribal Learning practices described in THE CULTURE GAME book are indirectly supported by Kanban!

This means Kanban is a very serious device for generating social learning in your organization. It means you have to look at it closely.

Let’s take a look at the rundown:

 

Tribal Learning Pattern as Described in THE CULTURE GAME book How Kanban Implements the Pattern
Facilitate Your Meetings The periodic Operations Review meeting (described on page 159 in the book Kanban by David Anderson) is a facilitated meeting.
Examine Your Norms Kanban looks at how long things normally take, and calls that ‘cycle time’. This is an explicit examination of actual, normal delivery times
Be Punctual Not applicable, although most teams doing good Kanban value the keeping of commitments, for example commitments to deliver, appointments etc.
Structure Your Interactions Kanban structures interactions with upstream and downstream partners through Policies, Classes of Service, Work Item Types. Internally, the team structures the columns and swim-lanes depicted on the Kanban board.
Announce Your Intent Teams using Kanban announce intent via the Cycle time connected to Classes of Service. Cycle time states the amount of time for delivery to the customer.
Game Your Meetings Kanban has a daily meeting where the ‘Kanban’ game is discussed.
Conduct Frequent Experiments Teams using Kanban experiment with adding columns, swim-lanes and new Classes of Service.
Manage Visually Kanban is many things. It is obviously at least a Visual Management tool, and a very sophisticated one at that.
Inspect Frequently Each day the Kanban team meets in front of the Kanban board, discussing the work, and inspecting it visually.
Get Coached Kanban as defined by the book of the same name does not mandate coaching. In practice however, this is often the case. Teams coached in Kanban use may get benefits more immediately. Here is some proof: a rather authoritative blog post from KANBAN author David Anderson on what Kanban coaches do, and do not do.
Manage Your Boundaries Kanban depicts the beginning and the end of the work flow under consideration. Kanban defines and manages input and output boundaries.
Socialize Books Not applicable, although many Kanban implementations use substantial learning library
Pay Explicit Attention This is ‘the name of the game’ in Kanban. Kanban plays a direct role in manifesting a shared mental model of the work, the work flow, and related subjects.
Open The Space The very act of depicting the work flow explicitly in Kanban tends to open the conversational space about what is true, what is false about important, previously un-discussed topic, for example: work-in-process and related limits
Be Playful Every Kanban board is a custom thing that develops over time. Columns, column names, swim lanes, work items types and more are all up for discussion and experimentation.Users can playfully choose certain stickers (insignia) to mean certain things, etc. Kanban is open to playful experimentation.

 

Summary:

Kanban directly implements 12 of the Tribal Learning patterns. As such, Kanban is a serious device for generating Tribal Learning, that is: social, or group learning…or team learning, in your organization.

Kanban is useful for building a shared mental model of the work and work flow. As such, it is serious culture technology and a culture hacking tool for encouraging team learning and innovation in the current culture of your organization.

Posted on

Agile Enablement: Now in a Spray!

“Agile enablement is all we do” is a phrase used by some firms that sell Agile as a product. The basic idea here is that this one firm with a designed, “proven” approach can solve all your Agile problems– can be your “panacea”– so long as you write a big check.

This is very misleading, since Agile is not a product. Some folks with a very creative sense of humor are bringing this to attention with “Agile In A Can“– in effect, delivering Agile in as a spray-on product. Imagine spraying Agile on your managers, your developers, or your task boards, like deodorant or cologne. You get the idea.

(NOTE: You can follow @AgileInACan on Twitter )

The notion you can write a big check and then get visible, instant Agile going is seriously misguided. Your organization must be committed to learning, UP FRONT, and take responsibility for that learning after a while being guided by an external coach. And in time, by going forward– without that external coach. This is your goal: self-sustained, “free standing” agility.

Some service firms out there are selling the idea that you need a coach present each and every day, 5 days a week, for at least 12 weeks. Otherwise, you may fail !

This is called “embedded agile coaching” or “integrated coaching”. It sets up an nearly-automatic, unhealthy dependency on your “coach”. The implication is, “We are the experts. We have loads of experience, look at our client list. We have the one true way, this is absolutely the right way to do it. You may fail otherwise. We are the experts, and we are here to help you.” Out comes the contract and when you sign it, you lock in legally to pay for five days a week for 12 weeks.

What this does is simple. It sets up the “coach” to be present 8 hours a day, every single day. After a while, it becomes very obvious to you, the customer: the coaching job is definitely not a full-time job, even when coaching 1,2, or 3 teams.

How to get the coach busy doing something? The obvious fix is to make the “coach” the Scrum Master for all the teams right? ….so the coach is “doing something”, and is “earning their keep”. Makes sense right? Not exactly. Now the dysfunction kicks in.

The coach is now the authority, the person your Agile adoption most depends on. What usually happens is, this person takes up the Scrum Master role while not really teaching this skill to others in your organization. This makes the “you will fail without us” theory a self-fulfilling prophecy. If that “coach” leaves, no one really knows how to be the Scrum Master.

This practice of “integrated agile coaching” is really just a gamed scenario for installing a billable person in your shop each and every day for 60 days in a row. At a high bill rate. To generate loads of revenue. That’s it. It’s about revenue generation. For them to keep it going beyond the contract term, you need to stay dependent.

Don’t think so? Consider this report that says many customers are reporting that “agile is a scam to sell services”. Are these practices I am describing fueling this trend?

Did the customers surveyed in this scathing analysis of agile  buy 5-days-per-week, “agile integrated coaching”?

Are you looking to buy some agile coaching? OK. Here is the pattern.

The rigged game presented to you by the  “agile coaching innovation” firm goes something like this:

The Goal: Maximize Revenue Generation

The Rules: The coach is going to set up camp in your shop 5 days a week for 3 months. You the customer must sign a binding contract for “integrated” coaching, which is 5 days a week, for a 3 month minimum (a legally binding, ironclad revenue guarantee. You cannot get out.)

Scoring: The game is scored by the minimum 3-month revenue generation and the ongoing creation of more dependency on the coach from the client. Primary device to do this: be there 5 days a week, and work to occupy/own the Scrum Master role on every team. (NOTE: A good coach will teach others in your organization this role, and vacate the Scrum Master role as soon as possible and without delay !)

Opting-In: You the customer are either in or out based on the 5-days-a-week-for-3-months contract. Did I mention the high bill rate? The insistence on this engagement structure as the terms of engagement tests your willingness to play the dependency game. If you go for the contract, that means you are willing play the dependency game. By signing, you are agreeing to much more than you bargained for…

And dependency IS the name of the game!

Here is a good article on agile coaching, from the Agile Journal. It is from 2009.

Look at what it says:

However a Coach works, and whatever approach they take they the Coach needs to avoid creating a learned dependency.  This happens when the team comes to depend on the Coach.  Coaches need … to withdraw when the time is right and let the team continue.

While many companies will have their own coaches on staff and some will work with teams day-in, day-out for months or even years, there is a lot to be said for…limiting the period of coaching.

Yes, some “agile enablement” service firms selling “integrated Agile coaching” are eager to set you up in their “agile enablement” game, a game that maximizes billing-revenue for them first, and enables Agile for you second.