Friday, August 24, 2012
Change Management vs Process Evolution
We hear a lot about “managing transitions” in the knowledge worker
management and consulting space. In the Agile community, Agile transitions are
the bread-and-butter revenue generators for many consulting firms. I’ve been
on record since as early as 2005 stating that I don’t believe in this
Change management is the discipline of managing change in organizations.
Changes to processes or changes in organizational structure the discipline
used to bring some control and governance to these activities is called change
management. There is a large body of literature on change management. I have a
small stack of books lying in my office on the topic of change management
within the software and IT industry.
It doesn’t matter whether the change is to an Agile method, or older
methods such as RUP, or via models such as CMMI, or using Lean, Six Sigma or
Theory of Constraints, change is sold and managed the same way…
There is an initial assessment or appraisal to document the current
processes or organizational structure. There is then some proposed future
state envisaged, for example, in Lean, by value-stream mapping, identifying
wasteful activities and designing them out. 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. The assumption is that the problems with the current
process can be fully identified using models and a grand design envisaged for
a new utopian future. This would work, were it not for the fact that elements
of knowledge work and knowledge work environments exist in the complex
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
When writing my first book, I came to realize that Eli Goldratt’s Five
Focusing Steps, offered an evolutionary approach to change, where the
identification and management of bottlenecks offered both the fitness criteria and the model to guide the evolutionary mutations. I couldn’t have expressed
it that way in 2002 - I wrongly used the term “incremental” - but the essence
was that small changes were made and the successive changes could not be
predicted far in advance - perhaps only the next 2 or 3 steps at best. An
entire transition could not be envisaged.
It was frustrating for me to learn that the Theory of Constraints community
had largely abandoned the Five Focusing Steps as an approach. Perhaps it didn’t facilitate consulting & managing transitions at clients in the early 1990s?
Equally, knowledge of and experience with Five Focusing Steps was not valued as a means
for acquiring social status within the tribe, to build status you had to be a practitioner, master or expert in the Thinking Processes.
The Thinking Processes is a managed change approach with a defined outcome
called the Future Reality Tree (FRT). So my interest in TOC and its community
faded about the time that the Agile community was beginning to get into gear
and attempt larger scale Agile transitions - managed change transitions to a
defined Agile utopian future state. It seemed wrong to me.
I continued the pursuit of an evolutionary approach. It seemed
more appropriate and more likely to succeed. As I now know, complex domain
problems require an evolutionary approach. In fact it goes further,
organizations operating in a complex space need to develop an evolutionary
capability in order to show resilience and robustness in the face of emerging
circumstances from their complex environment. Evolutionary capability it seems
is essential to thrive in the complex domain of knowledge work.
The Kanban Method has emerged as my approach to process evolution. Kanban
offers firms the capability of evolutionary change.
Similarly, Lean Startup has emerged as Eric Ries’ approach to business
With Kanban we use fitness criteria such as “is the work flowing?” “are we
serving customer demand adequately?” “are we managing business risk
appropriately?” “is there alignment between strategic plans, and go-to-market
strategy and the work that is happening on the shop floor?” as the fitness
criteria for evaluating our current process and determing how we might guide
mutations to produce a fitter evolution of our process.
With Lean Startup the fitness criteria are more directly market related
such as “are people buying what we thought they would buy?” “are they using
our product or service as we intended?” “are the customers the ones we
expected or is there an unexpected takeup from a group we didn’t predict?” and
so on. The concept of validating business assumptions, in Lean Startup, is the
process of applying a fitness criteria in an evolutionary sense.
The Kanban Method and Lean Startup are modern 21st Century approaches that
offer an evolutionary approach to solving problems in the complex domain.
Managed change with its defined target solutions and transition plans is a
20th Century approach best suited to complicated domain problems. It is
little wonder then that its effectiveness is limited and results are
The Kanban Method is the Agile approach to process change.
Agile transitions are anything but Agile!
The final chapter of Lessons in Agile Management is dedicated to Transition and I will feature an early blog post railing against the managed change initiative on this blog when it comes time to highlight chapter 16.
Posted by david on 08/24 at 05:21 PM
Thursday, August 23, 2012
A Taste of Lessons #7: Recognizing Tribal Behavior
I dedicate two chapters in Lessons in Agile Management to tribal behavior in the workplace and how to harness it. Chapter 7 collects articles relating stories of such behavior and providing advice on how recognize tribes and their behavior within the work environment. Here I present both the contemporary chapter introduction and an article published on Monday, May 17th, 2004 relating a story from the summer of 1999…
Introduction to Chapter 7
The history of the Agile movement, and the entry of Lean and Kanban into the same
workplaces, is a story of tribes. That’s not surprising, because tribalism is about
people—about relationships, affiliation, motivation, loyalty, and leadership. Introducing
a new methodology in the workplace inevitably leads to the challenge of managing tribes.
Agile encompasses flavors such as Feature-Driven Development (FDD), eXtreme
Programming (XP), Crystal Clear, and Scrum. For years, affinity groups associated with
such methods squabbled among themselves, while together squaring up to the common
enemy from the past—traditional software engineering methods and heavily planned,
commitment-based, phase-gate project management and governance frameworks. Recently,
some members of these Agile tribes have chosen to go to war against the Lean and Kanban
communities. This tribal behavior is entirely predictable. The actions of leaders in the Agile
community can be easily explained when viewed through a tribal lens.
In 2004, I described Ray Immelman’s Great Boss, Dead Boss (Stewart Philip International,
2003) as the most important book I would read all year. It had a profound effect on my work
and on my approach, several years later, to building the Kanban community. Understanding
tribes and the wider field of sociology is now a vital element for someone who seeks to be
a successful change agent, consultant, advisor, coach, or methodologist.
Understanding and respecting people isn’t merely about recognizing the field of
psychology as critical. It is important that we recognize that being human means that we
are herd animals and that tribal behavior is core to our very humanity. Leading, managing,
and inspiring knowledge workers cannot be done effectively without an understanding
of the tribal nature of humans.
Another Tale of Belonging
Another tale of belonging dates back to the summer I was working in
Dublin, Ireland. It was 1999—a great time to be alive. There was the economic
bubble. It was a great time to be in Ireland. The ’90s had been good to the
country. The combination of a pro-business tax regime, demographics that
were producing a large number of young graduates, inward investment, and the
spoils from years of EU handouts were turning Dublin into a boomtown. It was
impossible to get service in a restaurant because all the would-be waiters were
working as web developers.
I was working at a company still known as Trinity Commerce, though it
was already part of Telecom Eireann, which was due to be sold off by the Irish
government in an IPO. This was where Brían O’Byrne and I first created the
state machine execution engine for the user interface layer of the architecture
that was inspired by Ian Horrocks in his book Constructing the User Interfacewith Statecharts (Addison-Wesley, 1999). This architectural innovation is truly
at the root of this story.
Earlier in the summer, I had analyzed the scope of the project using Peter
Coad’s domain-modeling and feature-analysis methods and sized it as 153 business
logic features. The business logic was being written in PL/SQL for Oracle
8 by a team of Oracle consultants and contractors. I had no control over that
technical and architectural choice. Naturally, I would have preferred to develop
the business logic in Java and use a simple persistence layer tool to store data in
the database. Nevertheless, we ran the project as an FDD project. A team of seven
people spent 11 weeks building the business logic. They were very professional.
Everything got designed, tested, and reviewed. And the quality was very high—
only five bugs in total. Meanwhile, the customer had refused to de-scope some of
the challenging, non-functional user interface requirements. Their specification
was for a GUI (fat client) app and it would not run in a browser. We pleaded with
them, but they insisted that it must work in 3.x web browsers. Their requirements
were effectively mutually exclusive, but logic did not prevail. They refused to
budge. In the end, we were forced to build the state machine engine to track
the state of the user interface for each user session. This caused a delay in the
development of the user interface layer of the system—a long delay. It took 12
weeks to build the first state machine engine. However, the advantage, if there
was one, was that we had a complete user interface design and a full statechart
model before we started coding the actual application interface.
We were in a position where the project wasn’t yet late. The business logic
was complete, but almost no user interface code existed except for the infrastructure
of the statechart engine. We had nothing to show anyone.
Remember, it was the bubble! You couldn’t get served in a restaurant, and
hiring developers was difficult. To fill the skills gap, the principals of the company
had visited a local college and hired five fresh graduates. We had three of
them on our team. Today, these people are probably all experienced professionals,
but in those days they were as green as the grass rustling in the fields near
our office in Sandyford Industrial Estate, in the suburbs of Dublin. So we were
frighteningly close to being late and half the development team was straight out
In order to make significant progress, we agreed that we would work a weekend.
Hey, I was a contractor, I got paid by the hour! I agreed to buy the pizza out
of my own pocket as a gesture to the team. There were seven team members in
all, including the two guys who coded the framework. In addition, Brian Murray,
one of the business logic team, agreed to come in to deal with any issues we
might find in their code.
Brian soon got very bored with his weekend. After all, the business logic
was bulletproof and the user interface had been fully designed with statecharts.
Every single call we needed from the user interface to the business logic already
existed and it all worked. Brian had little to do but wander around and gaze
out of the window. Luckily, he is gifted in a typically Irish way and kept us all
amused with jokes and idle chit-chat.
The application was being deployed in Oracle Application Server, which
predated EJB 1.0. It was a whole different product in those days. One peculiarity
was that it had only a single global logging queue, and we relied heavily on logging
instrumentation for debug information. We had seven people writing View
and Controller classes—each one of them with a piece of the statechart model to
code. In order to test, a developer had to obtain a “lock” on the app server so that
no one else would run their code and corrupt the log file. The team all sat together
in a U-shaped desk space in a corner of the office. Each member was about
four feet from the next. The “lock” was obtained by asking, “Can I clear the log
file?” and then waiting for an acknowledgement from the other six members
of the team. By mid-afternoon on Saturday, this call had shortened to a shout:
“Clear the logs?” Everyone’s head is down at their keyboard, coding, and every
few minutes, any conversation among them was interrupted with that cry: “Clear
the logs?” Indeed, every few minutes a new feature was being tested. The velocity
of the team was tangible and directly measurable by the rate of cries of “Clear the
logs?” Team morale was high. Everyone knew progress was being made. They
could hear it. They could see it every time they ran a test and checked that log
file for the outcome. In such a structured framework, it was easy to make rapid,
accurate, bug free progress. It was good to be alive. It was good to be in Ireland
in the bubble. And it was good to be on the user interface development team of
the EIBS project that sunny, long summer weekend in Dublin.
On the following morning, Brian was wandering around the office building
bored beyond belief and feeling decidedly spare. Thanks to the wonderful quality
of the code he and his colleagues had written, he had nothing to do, so he felt
left out and abandoned. He really had nothing to do and he couldn’t help us. He
was a PL/SQL programmer. The user interface was written in Java. There was
nothing he could do. He took to raising his arms and shouting, “Clear the logs!”
“Clear the logs!” After a while, we called him over and made him an honorary
member of the user interface team. He was now officially allowed to cry, “Clear
the logs!” whenever he liked. He was one of us. He belonged!
The EIBS cost in excess of two million Irish pounds—about two million US dollars
at the time. It was the biggest project Trinity Commerce had ever undertaken.
It was their baptism into the telecom industry. It was completed on time
and on budget and it included all the exceptionally challenging non-functional
requirements that had added significant technical risk. It was defect free. For
many who worked on it, it remains one of their fondest memories of that time
and of their early careers. Brian Murray is now a process engineer and coach working
in Ireland. He remains a friend and still follows my work closely.
Posted by david on 08/23 at 04:43 PM
Tuesday, August 21, 2012
A Taste of Lessons #6: Goldratt & His Theory of Constraints
Today, I’d like to present an extract from chapter 5 of Lessons in Agile Management. On June 24, 2004, Eli Goldratt gave one of his Viable Vision Tour seminars in Seattle. I picked up a number of little insights from some of his more subtle comments. This is the second of them, first published on June 29th, 2004…
Lessons Learned from Eli #2: Resistance to Change
At his Viable Vision seminar, in Seattle, Eli Goldratt described some
of the reasons why people resist change, and what it is about the culture of an
organization that creates an environment that molds such people. I realized that
he was talking about what Jerry Weinberg has described as Level 1 and Level 2
organizations—the hero developer level and the hero manager level. The hero is
cast in the role of firefighter, and he is the hero because he delivers. He delivers
by putting out fires. As a result, he is rewarded for putting out fires and he is
praised and admired by his colleagues as a champion firefighter. The more fires,
the better practiced he becomes at putting them out and the more admired he
becomes for putting them out. As a result, he measures his self-esteem by his
prowess at putting out fires.
Hence, the hero firefighter learns to thrive on chaos. Chaos is the norm
in the organization and the hero is the master of chaos—the one who parts the
seas and delivers the team from the perils of chaos and non-conformant quality.
A hero does not want to move to a state of control because his or her selfesteem
will drop when she or he is no longer praised for being a hero. An organization
running in a state of control no longer needs heroes!
So there is a conflict. The organization wants to be under control and to
deliver predictably, but some staff members thrive on chaos and their status in
the organization depends on it.
How might we resolve this conflict? The senior management must start to
reward people for behavior that is congruent with controlled performance, and
they must build self-esteem around that behavior. The heroes must be coached and assisted to adapt to a new pattern of behavior—one that anticipates and
absorbs uncertainty rather than one that heroically reacts to it.
As a further reflection on this story, I encountered such a situation in 2007 - the
hero group project manager who thrived on chaos and firefighting. Like Goldratt,
I’d always believed that changes should be made in ways such that all team
members would be able to come along for the ride; that job losses were an unacceptable
cost of change. Encountering the queen of firefighting, who had spent
a 30-year career in this mold, I came to realize that perhaps Jim Collins had it
right - you have to decide who you want on the bus. As a result, some people have
to be asked to leave. Although leaders can set an expectation for a new culture
and new social norms, not everyone will like it. Coaching may prove fruitless with
such people, and meanwhile, their behavior may deteriorate. In 2007, the group
project manager started to light fires just so people would see her putting them
out. She became the organizational arsonist. She had to go!
Posted by david on 08/21 at 09:10 AM
Monday, August 20, 2012
Kanban’s Galapagos Island
This is the first of a series of posts on evolutionary capability and the notion of social and process evolution.
I found Tim Harford’s book, Adapt, hugely validating of what we’ve been doing with Kanban. Harford writes for the Financial Times and The Economist. Essentially a writer on economics, he’s been influenced by work by people like John Kay, the English economist who suggested that oblique rather than direct approaches to business make for better profits and long term success, in his book Obliquity.
Harford suggests that in order to deal with complexity and an uncertain future, we must take an experimental approach to our businesses and our processes. We must be willing to try things and fail. When something works, we should amplify it and when it doesn’t discard it quickly and try something else. One of his core ideas is that for new concepts or memes to thrive, they need isolation. He refers to this as the Galapagos Islands effect. The adaptations from evolution that Darwin observed in the Galapagos were possible because the islands were so remote.
It occurred to me while reading Adapt that a number of somewhat accidental choices and decisions had served to isolate Kanban and its community and in effect create a Galapagos island where the meme could thrive and evolve. The first of these events was to create the Kanbandev Yahoo! group and to encourage a community of enthusiasts. This provided an online meeting place for the affinity group, or tribe, to develop its ideas. In 2008, it was suggested we get together face-to-face and the Lean & Kanban 2009 conference in Miami was conceived. For the first time, the emerging Kanban tribe came together to share its experiences and develop a narrative. Out of that meeting came the idea to form the Limited WIP Society as an online place to share experiences and to find like-minded people. That in turn spawned local groups meeting in cities such as London, Stockholm and Hamburg. There are now around 30 of these groups all over the world. The largest are in Australia - Sydney and Melbourne. Remarkable given that there has never been a Lean Kanban conference in Australasia and I’ve only taught a single class - the advanced 3-day masterclass - in the region.
These community meeting places both virtual and physical, both local, regional and global, have served to create a bubble inside which the Kanban meme can thrive and evolve separate from any undue influence from the Agile (or other) communities. As Harford might suggest to us, had Kanban simply been served as a track or theme within Agile community events, it is likely that cross-breeding with Agile methods would have watered it down and stunted its growth.
Kanban without Isolation
Without protection, from the Agile community. within its own Galapagos island, Kanban would have come under stronger attack. It wouldn’t have been allowed to emerge as it truly is - an approach to change, an evolutionary approach designed to work upon existing processes and morph them into something fitter for their environment and entirely tailored to suit the specific situation. Instead, Kanban would have become yet another Agile method - one with deferred commitment, de-coupled cadences, no iterations, no planning, no estimating - essentially a new approach to project management.
What would have happened next is that the tribal immune system would have set to work on it. Attacking the novelty and the practices that were not considered to be Agile. The fitness criteria for the survival of Kanban within the Agile community would have created a filter that discouraged and eliminated practices that were not considered part of the tribal rituals and accepted behavioral practices. The de-coupled cadences would have disappeared in favor of iterations. The deferred commitment concept that discourages planning and estimation would have gone too. Operations reviews would be gone. Retrospectives at a team level on the same cadence as the deliveries would replace it but the inter-workflow benefit of an ops review would be lost. The kaizen events that happen after a daily standup meeting would probably be lost too - because the Agile norm is conformance to a defined process, and to reflect on performance only at scheduled retrospectives. Further, some sections of the community reinforce conformance to the defined process via a tribal need to label those who don’t conform fully as either less worthy or completely untouchable. If you want social status you must conform to the way everyone else is doing it.
So what would we be left with had we not accidentally isolated Kanban? It seems the use of card walls was already an accepted Agile practice in 2007. Kanban gave this practice greater depth and it gave it a catchy name. Kanban made the use of card walls “sticky” (as Chip and Dan Heath might suggest in Made to Stick). So perhaps it is not a surprise that as far as the Agile Alliance is concerned, Kanban Board is an Agile practice. Within the Agile community Kanban gets reduced to a visualization technique.
Benefits of Isolation
Through the happy coincidence of isolating Kanban from existing software development industry communities, we were able to develop our own. As anyone who has attended the series of conferences we’ve run over the past 3 years can attest, this community is diverse, open-minded, experimental, and is constantly looking to synthesize ideas from outside. Dissenters are actively encouraged. We’ve had John Seddon tell us “Lean drives me potty” and Benjamin Mitchell suggest Kanban might be a fad and to actively criticize the ability of Kanban to work as it is advertized as a mechanism to catalyze evolutionary change. We’ve had Hakan Forss challenge some of the core ideas in depth of implementation. Dissent has helped us to evolve and dissenters have, in some cases, been rewarded with greater profile in the community, and prominent influence, such as chairing a track, or speaking opportunities at conferences.
My personal experience from other communities has been that ideas that challenge the established tribal norms and dissenting opinions are shunned and unwelcome. If you want a speaking spot at the event you’d better be telling people what they want to hear!
Social isolation is a way to encourage a meme to thrive and evolve. You can create social isolation by encouraging the development of a community - an affinity group, or tribe - that shares an enthusiasm for the idea. The community must have meeting places both virtual and physical. When the community meets it must be able to share its stories in a safe environment. The leaders of the community must encourage and nurture diversity, dissent, and allow variants and mutations to emerge. In doing so, the idea will become stronger. It will evolve and thrive.
By doing all these things with Kanban, we’ve created a worldwide movement that is providing real benefits to people, teams, organizations and large-scale businesses. Had we not done so, even though it was accidental, it is likely Kanban would be a mere footnote in the legacy of the Agile community - a visualization technique for Agile methods. So many possibilities would have been missed and so much value left unrealized.
Posted by david on 08/20 at 08:27 PM
Saturday, August 18, 2012
A Taste of Lessons #5: Chapter Buffers
Today I am choosing to highlight another aspect of my new book Lessons in Agile Management. The book features 16 chapters on themes such as Leadership, Management, Theory of Constraints, Human Resources, Lean, Agile and Transitions. However, some of the most popular articles on the Agile Management blog over the years did not readily fit into these themes and were not directly relative to the narrative of the book as a whole. It would, however, have been a pity to omit them altogether. The answer was to insert these popular articles as buffers between chapters. In total there are 17 of them. Today I’ve chosen to highlight the buffer between chapters 4 and 5. Originally published on Thursday, February 8th, 2007, this article was a late addition to the book. It did not appear in the galley copies we published in May. It was included in the final manuscript only after my visit to Brazil in July. The question of respect came up during class and simultaneously on Twitter. I often find I am challenged publicly by people with no Kanban experience but lots of opinions about it. I try to be courteous with these people, up to some limit, but I do not show their opinion respect. My views on respect are perhaps controversial in the humanist Agile community. This article explains why…
Some more thoughts from my trip around central Europe: I was watching Bill Amelio on CNN. Bill has the wonderful job or merging the former IBM PC Company (one of my former employers) with Lenovo. When questioned about how to get the two sides to play together, he mentioned respect as a key behavior that people needed to bring to meetings, “you have got to be willing to compromise,and if you are able to do that on a regular basis, and respectwho each person is and respect their intentions. . . .” I hear this “respect” word a lot in the workplace and in the Agile community. “If only people would respect each other we’d all get along better.” “I think your people don’t respect mine enough.” For example, the Agile development team doesn’t show respect to the unreformed PMs or vice-versa . . . and so it goes.
Spending some time in the Tirol reminded me of the problem with all of this. Respect isn’t offered or given, it is earned! In business and management literature we are too often confusing courtesy with respect. Courtesy is something I find offered to the tourists of the Tirol by the locals ungrudgingly, and always with a smile. (No wonder —more than 90 percent of their economy depends on revenues from tourists.) However, you earn the respect of the locals, for example, by taking the cable car to the top of the mountain and skiing all the way to the bottom in time to catch the same car again less than 15 minutes later, or by biking up a series of switchback turns to a peak normally reached by tourists only via a gondola or chair lift, or by hiking up a valley tourists rarely visit and sleeping out a few nights in
alpine huts and not coming down below the snow line for a week. Once you’ve earned this respect, you see courtesy for what it is.
So, if you feel you’ve got colleagues who aren’t showing enough respect, ask yourself this: Are my colleagues being courteous? Do they listen and give of their time reasonably? If they are—and you still feel that they don’t respect you - you need to look in the mirror. What would it take to earn their respect?
Posted by david on 08/18 at 08:56 PM