Tag: agile

Posted on by — 1 Comment

Don’t do anything stupid on purpose

It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.

Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading Don’t do anything stupid on purpose

Posted on by

What development methods and practices do you support?

From time to time, something happens that reminds me that our espoused theories aren’t always congruent with our theories in use (see this summary for some quick background info on those terms). The author of an article I had cited as an example of "binary thinking" posted a comment asking how I had gotten the idea that he was pro- or anti- anything. I took the question literally, and started thinking about how any of us might get the idea that another practitioner was pro- or anti- any given software development practice. Continue reading What development methods and practices do you support?

Posted on by

The Shimmering

In the movie, Now You See Me, a certain idea was stated multiple times, phrased in various ways: "Look closely, because the closer you think you are, the less you will see." In the past decade, a lot of people have been inching closer and closer to something called "agile," and most of them are pretty sure they can see it.

Things are very different on each side of the "hump" in the diffusion of innovations curve. On the left side, the early side, where the Innovators and Early Majority adopters live, people tend to be forward-looking, open-minded, imaginative, proactive, and willing to take risks. On the right side, the late side, where the Late Majority adopters and Laggards live…well, not so much. Some people are interested in the left side, because that’s where breakthrough ideas are vetted in the proverbial fire of the (possibly over-rated) Real World. Others are interested in the right side, because that’s where methods and practices become scaled, integrated, and institutionalized to support large enterprises. Continue reading The Shimmering

Posted on by — 3 Comments

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

Posted on by — 14 Comments

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.

Continue reading Lack of fluency

Posted on by — 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 by — 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 by — 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 by — 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 by — 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?