Let’s walk through a couple of process improvement scenarios to explore the differences between measuring activities and measuring outcomes. The starting point is a software development team that has decided to improve software quality. Continue reading Measuring continuous improvement
Tag: process improvement
How to avoid the local optimization problem when coaching at the team level
A recent Twitter discussion inspired me to re-think a few things about how to effect meaningful change at the organizational level and the team level. (Funny how Twitter seems to serve that sort of purpose, which may be above and beyond the usage pattern its creators envisioned initially. But I digress.)
During the first few years I worked in the general area of process improvement, I functioned mainly as an “agile” coach at the team level. Through those experiences I tried to understand how each method or practice worked mechanically as well as applying the “agile” values and principles on the cultural dimension, and started to learn how psychology and organizational sociology play into software development practices and delivery methods.
It didn’t take long for me to realize that the way an individual development team goes about its work actually has relatively little impact on the effectiveness of the end-to-end delivery process. I continued to look for the key leverage points in organizations that might yield the greatest positive effect for process improvement. I often found myself venturing far afield from the teams I had been engaged to coach, because time and time again I discovered that the real problems with delivery lay well outside the team’s jurisdiction.
Continue reading How to avoid the local optimization problem when coaching at the team level
Lack of fluency
A recent article by James Shore and Diana Larsen, Your Path through Agile Fluency: A Brief Guide to Success with Agile, has generated some buzz. I have tremendous respect for the authors, as well as for the people I’ve seen posting positive comments about the piece. To be honest, though, I’m having a lot of difficulty buying into it. I don’t want to offend any of those people. On the other hand, they might just dismiss me as stupid and not be offended at all. Either way, here goes.
The gist of the article appears to be that we can effect organizational improvement in a large company by driving change from the level of individual software development teams. The major problem with that idea, in my opinion, is the bottom-up approach. The authors suggest beginning the organizational transformation initiative from a single software development team and then extending the cultural change outward. They also want to tie together the various parts of the organization by reaching out from the team. I suspect this is because their own professional background is in the area of software development, as well as the fact that both of them have enjoyed a measure of success with the approach, at least up to the second "star." But the approach doesn’t address the core structural problems in companies; it only works around them somewhat.
Pros and cons of dedicated teams
One concept that’s been getting a lot of play in recent years is the idea of dedicated teams. In the context of software development and support activities, the concept boils down to this:
- Any single team is assigned to just one development initiative or to the support of just one set of technical assets at a time; and
- Any individual is assigned to just one team at a time.
With this model, you might dedicate Team A to ongoing enhancement and production support of the company’s call center systems. Team A does not do any work to support other business operations or other technical assets, such as contributing to the development of a loan underwriting system, or providing production support for the company’s enterprise service bus. In addition, if Stephan is a member of Team A, he is a full-time member of Team A. He is not assigned 75% to Team A, 15% to Team B, and 10% to Team C.
The dedicated team model is an alternative to a matrixed model of personnel assignment (or “resource allocation,” if you can tolerate speaking of humans as “resources”). With a matrixed model, teams are formed specifically to carry out particular initiatives (typically when the discrete project delivery mode is used), and disbanded at the conclusion of each initiative. Individuals may be assigned to more than one of these temporary teams at the same time, and expected to split their time among multiple initiatives.
Managers who are accustomed to thinking in terms of maximizing individual resource utilization often have difficulty understanding the potential advantages of the dedicated team model. I thought it might be helpful to summarize some of those advantages:
- Avoiding artificial dependencies between projects
- Reducing induced administrative overhead
- Reducing context-switching overhead
- Increasing domain knowledge
- Increasing team cohesion
- Improved visibility and clarity on progress
There are also potential disadvantages to be aware of, such as:
- Stagnation of technical skill sets
- Boredom and its associated morale problems
- Reduced opportunities to learn about other areas of the company’s business, with the risk of developing a narrow perspective on the work
- Missed value from deep specialists
The fall and rise of shadow IT
Years ago, as far back as the mid-1980s if memory serves, IT managers were worried about a phenomenon they called “shadow IT.” The term refers to cases when business managers implement their own departmental IT solutions in response to poor support from their internal IT departments. The phenomenon raised alarms in the minds of IT management. They were losing “control.” Others were treading on “their” territory. Lions and tigers and bears! Oh, my!
I was reminded of this when I saw an announcement of an upcoming webcast entitled, “What’s a CIO to do About the Rise of Shadow IT?” This suggests that many IT managers still don’t get it. So-called “shadow” IT is not a “problem.” It is not an intrusion on anyone’s sacred territory. It is an indicator that something about the status quo is causing people’s needs to go unmet.
The question should not be, “How dare they try to take over our territory?” The question should be, “What are people trying to tell us about their needs?”
Thor’s hammer had a name, so why can’t mine?
Mjölnir.
Thor’s hammer was called Mjölnir. Cool name for a problem-solving device.
Liza Wood commented on a recent post of mine in which I lamented the overuse of the word, "agile," and the ill effects of that overuse. She wrote, in part:
I completely understand why you have become disenchanted with word "Agile", but I am sticking with it for now. For the majority it’s still at least a starting point to have a pragmatic conversation about product development (not just software).
I wonder about that. Is the word really a starting point for pragmatic conversation? Different people have had different experiences with that. My experience has been that people already have some pretty firm ideas about the implications of the word, "agile." A recurring pattern is that a change agent goes into an organization and happily proclaims, "Oh, boy! We’re going Agile!" To his/her surprise, the people in the organization do not react to the proposition joyfully. The word "agile" connotes Happy Things to the change agent. What does it connote to other people? Why are they not happy to hear it?
Ron Jeffries’ classic article, We Tried Baseball and It Didn’t Work, suggests an answer.
Continue reading Thor’s hammer had a name, so why can’t mine?
Give me a lever, and…
An opportunity for improvement came up recently on a coaching engagement that reminded me of the book, Switch: How to Change Things When Change Is Hard, by Chip and Dan Heath. The authors found that in a wide range of circumstances, people had approached very challenging changes in a similar way; basically, by finding the bits that were working well and using them as the basis for further improvement.
Sometimes the bits that are working well don’t look all that great at first glance. One of the stories the authors of Switch share is that of Jerry Sternin, who was charged with improving the nutrition of children in Vietnam. Rather than approaching the problem as a large-scale infrastructure problem, as had been done up to that point with poor results, Sternin went to a single village to learn how children were fed.
He noticed that some children were well nourished. Setting aside those who had Party connections, and therefore access to better food, he investigated how the well-nourished children were fed. He found their mothers mixed additional sources of nutrients into their rice, including wild plants, small shrimp and insects that could be found without cost. To a Westerner like me, mixing insects into my rice sounds rather nasty; but sometimes opportunities don’t come at you waving their arms and shouting, "Hey! I’m an opportunity!"
The machine society and how to cure it
A rigorous scientific experiment
On the morning of April 21, 2012, I submitted a Google search for the term, productivity. The search engine returned “about 244,000,000 results.” For the term, efficiency, it returned “about 362,000,000 results.”
A search for the term happiness returned “about 56,000,000 results.” A search for the term self-actualization returned “about 1,340,000 results.”
The first two terms yielded a total of 606,000,000 results. The second two terms yielded a total of 57,340,000 results. About 91% of the results pertained to productivity and efficiency, while about 9% pertained to happiness and self-actualization.
Which values are more important in modern society? Clearly, productivity and efficiency are more important than happiness or self-actualization. Have I based this conclusion on my highly scientific and rigorous Googling experiment? No. I already knew the answer before I Googled the terms. My conclusion is based on 58 years of life experience as a card-carrying member of modern society. The Google results were not informative, they were merely unsurprising.
It isn’t necessary to conduct a scientific experiment or an academic study to know that we are preoccupied with productivity and efficiency. Management training, process improvement methods, organizational models, and the like all focus predominantly on those two values.
The question, then, is “So what?”
Continue reading The machine society and how to cure it
Sphincter Power, or: How to get a clear definition of done
One day, the organs decided to hold a meeting to determine who should be boss.
The brain said, “I have the capacity for abstract thought, and I also control the autonomic processes of the body. Clearly, I should be boss.”
The heart said, “I pump the blood, taking oxygen to all the parts of the body. Brain, without oxygen you die before anyone else. Clearly, I should be boss.”
The stomach said, “Without me, none of you could function. I process food and convert it into the energy you all require. Heart, without energy you stop pumping. Brain, you consume energy even when the body sleeps. Clearly, I should be boss.”
The sphincter said nothing, and remained closed. After a couple of days, the brain had a headache, the blood was toxic, and the stomach was bloated. The brain, heart, and stomach unanimously declared the sphincter boss.
Continue reading Sphincter Power, or: How to get a clear definition of done