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 “transition” approach.

Managed Change

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 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.

Evolutionary Change

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.

Evolutionary Capability

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 model evolution.

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.

Conclusions

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 lackluster.

The Kanban Method is the Agile approach to process change. Agile transitions are anything but Agile!

PS:

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.

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 of college.

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!

Contemporary Commentary

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.

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.

Contemporary Commentary

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!

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.

Adaptability

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.

Isolating Kanban

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!

Conclusions

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.

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…

R.E.S.P.E.C.T

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?