Posted on 4 Comments

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.

Continue reading My personal agile journey

Posted on 3 Comments

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:

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

Continue reading Pros and cons of dedicated teams

Posted on 1 Comment

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

Posted on 7 Comments

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?

Posted on 13 Comments

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.

Continue reading The commoditization of “agile”

Posted on 1 Comment

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?”

Continue reading The fall and rise of shadow IT

Posted on 2 Comments

BBUF: Big Budget Up Front

The packaging of ideas represented by “agile” includes elements pertaining to organizational culture and elements pertaining to processes and practices. Although many of us would like to see organizations adopt useful elements in both areas holistically, in my experience it is not the case that the two are welded together. Instead, cultural aspects and mechanical aspects affect work flow and outcomes differently and independently.

In most organizations that have adopted “agile” methods, people have embraced a subset of the mechanical elements of “agile” development, but they have no understanding of the cultural aspects and, in many cases, no interest. Yet, I think it’s fair to say they are “using” or “doing” agile development. It’s definitely possible to employ some of the mechanical aspects of “agile” development in the context of an otherwise-traditional organizational structure and culture. It’s happening all over the world right now. Because of this reality, I often use the word “agile” to refer only to the mechanical aspects. I sometimes run afoul of agile practitioners because of this.

When I suggest that the use of “agile” methods does not automatically mean we are doing adaptive development, some agile practitioners protest. Continue reading BBUF: Big Budget Up Front

Posted on 1 Comment

Choosing between traditional and adaptive development

The Iron Triangle of scope, schedule, and budget is fundamental to managing software delivery initiatives. Two general approaches are available for managing this aspect of delivery. With the traditional approach, we try to identify all needs, risks, and costs in advance and create a detailed, comprehensive plan before beginning development. With the adaptive approach, we begin with a vision for the product and incrementally evolve the solution based on feedback from stakeholders. Either way, we must deal with scope, schedule, and budget. However, the mechanisms we use are very different with each approach, and the metrics we can use to steer the initiative are different as well.

There are two key factors to consider when choosing an adaptive or traditional approach to Iron Triangle management: Urgency and uncertainty. Generally speaking, when either urgency or uncertainty is high, an adaptive approach is called for. When both urgency and uncertainty are low, a traditional approach is called for. It’s only fair to say that the choice is not always obvious.

Continue reading Choosing between traditional and adaptive development

Posted on

Geek moments

Today I came across a coupon from Dole inviting me to enter a contest, the Big Apple Giveaway. I wondered what the prizes were. Probably iPads, iPods, or other Apple products, I guessed.

Suddenly I realized the contest wasn’t a Big <pause/> Apple Giveaway. It was a Big Apple <pause/> Getaway. Not giveaway, but getaway, as in travel. And not Apple, the company, but "The Big Apple," New York City.

I suppose I could have taken the hint, as the I in "Big" took the shape of a silhouette of the Statue of Liberty. Not an Apple logo, as far as I know. Not yet, anyway. But it just didn’t register at first.

I felt an oddly disorienting sense of being out of phase with reality for a moment. It reminded me of an incident several years ago, when a colleague came to work and told us that she had called a plumber the previous evening, and could not think of any way to describe her problem other than to say, "My kitchen sink is down."

The plumber didn’t quite know what to make of it. "What do you mean, down? Did it fall through the counter-top?"

"No, it just, like, you know, doesn’t, like, work."

I wonder of you’ve had any "geek moments" like those; moments when your computer-oriented mentality scrapes rudely against the hard sides of normality’s box? Or is it just me?

Posted on 1 Comment

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?