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
Category: Uncategorized
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.
A recipe for software development
Garlic is widely considered to offer significant health benefits. It’s also a delicious and versatile ingredient in foods. Would tomato-based pasta sauce be pasta sauce at all if you omitted garlic? (Ignore American-style fast-food pasta sauce for the moment. Canadians, before you smirk, I have just two words for you: Pizza-Pizza.)
Chocolate, as well, brings a variety of health benefits. It, too, is delicious and a versatile ingredient in foods. What would a chocolate bar be if you omitted the chocolate? (Ignore "white chocolate" for the moment. Come to think of it, just ignore "white chocolate" altogether.)
Logically, then, it follows that chocolate-covered garlic cloves must surely be among the healthiest and most delicious foods one could hope for.
But why stop there? Glass is a wonderful material that adds much to our modern way of life. There is even a form of biocompatible glass that helps broken bones heal. Clearly, glass is good for the body.
Logically, then, it follows that chocolate-covered garlic cloves with tiny shards of glass embedded in them must surely be a super health food as well as a fabulously delicious snack. What an amazing rainbow of flavors and textures in the mouth! Ah, the sultry contralto notes of the chocolate, the lingering bite of the garlic, the metallic tang of the blood. And all of that still but a prelude to the inevitable conclusion.
The same logic applies to the task of selecting tools and methods for developing application software. I recall one project in particular that illustrates this approach quite well. The company wanted to maximize their chances of delivering a high-quality, well-aligned, usable product in a reasonable time. They went in search of the Best Practices Ever for delivering software, and identified three Good Ideas. Then came the flash of insight that set the stage for success: Combining all three Good Ideas on the same project could only result in three times the Goodness!
Well, in theory, anyway. In the immortal words of American philosopher Lawrence Peter Berra, "In theory there is no difference between theory and practice. In practice there is."
Some thoughts on metrics
I’ve found it helpful to keep a few fundamentals in mind when choosing and using metrics, and I want to share those in this post. Maybe you will find some of this useful.
My personal agile journey
This is a sort of trip report. I started on a journey in 2002, and in the ensuing 10 years traversed a lot of territory, met many interesting people, and learned a great deal. The journey certainly changed me. Whether the change is for the better is still an open question. I’m talking about my journey with, alongside, around, and sometimes against the grain of the "agile" movement.
With the Agile 2012 conference just around the corner, I thought this might be an appropriate time for a personal retrospective. I’ve presented at the last five consecutive Agile conferences, and found them to be enriching experiences. This year’s event takes place about 2 miles from my former home near Dallas, Texas. It would be great to see the old familiar places and visit old friends in the area. It would be great, as well, to show some of the friends I’ve made on my "agile" journey around the town.
I won’t be there.
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
It’s a question of its context
I read an article in Harvard Business Review today entitled “I won’t hire people who use poor grammar,” by Kyle Wiens. Wiens assesses job candidates, in part, on the basis of their use of English grammar. He goes so far as to administer a written grammar test to all applicants.
Amusingly enough, the website generated a URL by truncating the title to “i_wont_hire_people_who_use_poo.” I’m pretty sure I wouldn’t, either, unless using poo happened to be part of the job description. “Seeking howler monkeys for stock floor trading positions. Throw your résumé against the wall and see if it sticks.”
Um, okay, where was I? Oh, yeah. Is Wiens’ approach excessive? Ah…wait a second. Should that be, Weins’s? Does it depend on whether you’re in the US or UK? Does it depend on which form your fourth-grade teacher thought was “the rule?” <sigh/> I guess my chances of passing Wiens’ grammar test are low. Oh, wait…is it okay to use faux XML in a narrative? I’m so confused!
Anyway, comments on the article run the gamut from strong approval to strong disapproval. I find myself both agreeing and disagreeing with Wiens.
Let’s start with the points of disagreement. That’s usually more fun.
Continue reading It’s a question of its context
Why should we do code katas?
I participated in a coding dojo recently in which some of the comments I heard caused me to think about the purpose of practicing code katas. It seems that many programmers, including some pretty advanced ones, don’t quite get the point.
We were reading about some code katas online so that we could choose one to do for the dojo. We came across a description of the Bowling Kata written by Robert C. “Uncle Bob” Martin. A couple of the guys quickly dismissed it when they saw Uncle Bob’s name. “He’s too prescriptive,” said one. “I don’t want to be told how to approach the problem,” said another. They looked for a write-up of the Bowling Kata that didn’t try to guide us in how to approach the problem.
They found one and we used it. All evening we kept running into silly little issues and speed bumps, such that we really didn’t get a lot of value from the whole exercise. We went down tool-related side paths, broke our development environment a couple of times, forgot what we were trying to accomplish, and started over multiple times. It never felt as if there was any goal or even a general direction. Despite the fact the group included some very fine professional programmers, I have to say it was not the best coding dojo I’ve ever been in.
Obviously, due to the sort of democratic and participatory event a coding dojo is, I have to accept a share of the blame for that. I actively chose not to make suggestions to bring the activity onto some sort of intentional course, because I wanted to see where it might go. In the end it went nowhere, but the experience led me to sit down and reconsider the reasons we do these things, and how we can get value from doing them.
The key point is that there are reasons for Uncle Bob’s approach to katas. Rather than getting to the point directly, I’m going to begin with a couple of rambling digressions, as per my usual style. Continue reading Why should we do code katas?
The commoditization of “agile”
Sales consultant Phil Styrlund had an insight about the way markets have evolved in the Internet age that I think is relevant to information systems consulting in general and to "agile" and "lean" services in particular: Everything is a commodity. Anyone can obtain any goods or services they want by ordering them online.
It used to be that companies offering a product or service could distinguish themselves from others offering similar products or services by highlighting the special features of their product or by bringing unique capabilities to the table. Today, customers just don’t want to hear that. They have access to all the information available about your product or service. They already know. There’s nothing you could say about your product or about yourself that would make you any different, in the eyes of customers, from all the others in the market who are trying to sell the same things. You are a commodity.