Category: Agile

Agile Ain’t Wishy Washy

As I write this there’s a group of about 15 developers and designers standing near my desk in a heated but constructive argument about how to check the design is right before the code heads off to QA.

Occasionally the dichotomy of agile vs. waterfall is raised, and sometimes “agile” is used as a euphemism for “flexible” as in, “well, there was an update in design document X, and we’re agile, so you should be able to integrate that.”

If there’s one thing I’ve learned from doing agile it’s that agile ain’t wishy washy, i.e. it’s not really some sort of flexibility nirvana. Any software development process relies on firm lines drawn around what, when, and how the work gets done. Otherwise, shit don’t get done.

Yes, agile is better at responding to change. But it is effective, somewhat counterintuitively, because it responds to change with a high degree of rigidity. For example, if the stories aren’t written in a way that makes it clear to developers how to code a feature and how to test it, it doesn’t get accepted into a sprint. Once stories are accepted into a sprint nothing else can start until the next sprint. And so on. When I first encountered all this rigidity I thought the developers were acting like self-involved prima donnas. Actually, they’re just enforcing the rules that make the process work.

Agile responds to change, not wishy washiness.

Published
Categorized as Agile

Agile with a capital/lowercase A

It looks like agile software development is having the same growing pains, expressed through semantics, as the design field (or the Design field). It’s the perceived misapplication of language that catches my eye…

Jason Gorman argued that the meaning of Agile was ambiguous and was being inappropriately applied to a very wide range of approaches like Six Sigma and CMMi. He also argued that “Agile”, “evolutionary”, and “lean” (as in Lean software development) did not mean the same thing in practice, even though they are all lumped under the banner of “Agile” – possibly for marketing purposes. Gorman argued that process-oriented methods, especially methods that incrementally reduce waste and process variation like Six Sigma, have a tendency to limit an organisation’s adaptive capacity (their “slack”), making them less able to respond to discontinuous change – i.e., less agile. He also argues in later posts that “agile”, “lean” and “evolutionary” are strategies that need to be properly understood and appropriately applied to any specific context. That is, there is a time to be “agile”, a time to be “lean” and a time to be “evolutionary”.

Fascinating, but a nuance that will be completely lost on business clients who are focused on other matters. But just as IDEO shows what they do instead of only talking about it, I think making it all tangible will be a way around the semantic mess. I’d like to see the Agile Alliance produce a “shopping-cart“-like video of an agile project.

Bad News Should Travel Fast

Another reason I like agile management is because when something bad happens, you should know as soon as you can. If you only check project status every week or longer, that can be way too late. It’s like what Robert Duvall says in The Godfather: “I have to go to the airport. The Godfather is a man who likes to hear bad news immediately.’“

Seeing the Real Difference Between Art and Design

The Sartorialist blog has been a big hit, with each post getting dozens of comments. Why? On the surface it’s the usual blogger story: an individual with insight on a particular topic publishes quickly and honestly sans organizational overhead.

To me, the Sartorialist does something else important. He delineates the difference between art and design. Many publications aimed at the fashion consumer, whether it be men’s magazines or even the New York Times, present clothes as art. I imagine the editors are fashionistas, and publish for (the taste and budgets of) other fashionistas. The Sartorialist on the other hand covers what people actually wear and so has something of agile in it, quickly revealing what people are and do. It’s field research with a point of view.

Marketing Experimentation

Last year I hacked away at an article about the need for a greater degree of experimentation in marketing organizations, but it never really seemed to gel quite right, and eventually I abandoned it. I’m happy to see that Joseph Jaffe completed the task in Manifesto for Experimentation. Successful executives I’ve seen already embrace this attitude when they become comfortable with tolerating risk, but it doesn’t commonly spread through organizations.

Old School Scrappy Innovator: William Norris

Thomas J. Watson Jr., the head of I.B.M., which was famed for its militaristic corporate culture, was incredulous over Norris’s operation. So lean, so ragtag, so bafflingly humane. In a 1963 memo, Watson wondered how Control Data achieved with just a few dozen people what he had not with several thousand. Control Data later went on to defend its supercomputer innovation in an antitrust suit against Big Blue. It prevailed and won a settlement of $600 million.

A good example of agile innovation, from The Bleeding-Heart Rationalist.

Get Real For Free

The [[37Signals]] Getting Real book is now available free online as well as in PDF and paperback formats. With a focus on building web apps, it’s a great perspective on using an agile/craft way of working. It’s also a clever publishing strategy, analogous to the traditional hardcover/paperback progression:

  • Test and then build crazy excitement around the point of view
  • Publish a PDF version inexpensively and sell tens of thousands of copies
  • Release a paperback to capture additional market share (in time for the holidays!)
  • Release a free HTML version that also serves as a marketing vehicle for their other products

Not too shabby.

Published
Categorized as Agile

Fortune on Agile Businesses

Fortune magazine has rewritten Jack Welch’s rules on management to reflect changes in the business environment. Jack’s first rule was Big dogs own the street and Fortune says that rule should now be Agile is best; being big can bite you.

With the rate of change in business today, it’s hard to argue with the benefits of being agile, but exactly how does a manager make her organization more agile? I’ve been exploring this by adapting agile development principles for general managers, creating practices for becoming adaptive, fast, and focusing on value. I’ve really only scratched the surface so far; there’s incredible potential to improve the way we structure projects, make investments, and communicate, and it’s great to see media like Fortune recognize this potential.

Link courtesy businessinnovationinsider.com

Published
Categorized as Agile

The cost of iteration

Iterating on paper? Cheap.

Iterating in software? Still pretty cheap.

Iterating the Airbus A380? Not so cheap: “Airbus said Tuesday that it would produce only 9 of its giant new A380 jets next year, not the 25 planned, because of numerous design changes…. Small changes, like moving small pieces of equipment, were cascading through the system and creating the need for additional adjustments in wiring…”

This simple idea, illustrated in painful penalties and time-to-market costs for Airbus, is elegantly expanded upon in Austin and Devin’s book Artful Making. The authors — one a business professor and the other a theater professor — contrast the cost of iteration with the cost of exploration, look at its use in industrial and knowledge work, and how the iteration cost curve changes over a project.

In general the book is a wonderful look at applying “artful” (i.e. design or craft) ways of working to knowledge work, which is what business design is in large part all about. I’ve been recommending it to everyone.

Agile publishing

37 Signals’ new book Getting Real is out, and looks like a great read about applying agile techniques and spirit to web app development. It’s agile both in the content and in having small chapters, something we’ve seen in books like Godin’s Purple Cow and what I’m working on by re-interpreting agile principles for general managers in Evolve.

Who has time to read long books?

Published
Categorized as Agile

Agile everywhere

I’m finding examples of agile work practices in more and more places, and see them as perfectly aligned with the application of design practice in innovation services. Here’s a running list…

I think people in the product design and user-centered design disciplines work in agile ways as well, but haven’t yet found a common frame that other disciplines readily understand.

Dancing elephants: Lockheed

I love seeing big companies move in agile ways (because it’s so unusual), even if it only arises from panic of losing their old revenue streams. Here’s an example from Lockheed, whose old culture (despite their Skunk Works-style innovation) included bitter internal fights over whether to pursue unmanned aircraft…

…It also designed and delivered the seven-pound Desert Hawk within 127 days of receiving an Air Force request. The total cost for the first six drones and laptop-computer control system was less than $400,000, Mr. Cappuccio says. To date, Lockheed says it has supplied 126 Desert Hawks, which are used for surveillance to protect U.S. bases in Iraq.

When you also produce the most expensive fighter jet in the world, that’s certainly overcoming your innovator’s dilemma.

Incidentally, here’s an article about another group at Lockheed using agile practices.

A bakeoff of product innovation methods

Malcolm Gladwell’s The Bakeoff is now online, in which the food R&D firm Mattson tries to create the perfect cookie. Project Delta created three teams: one traditional in-house team, an “XP” (extreme programming) team of two people, and an “open source” dream team of the industry’s best working remotely. For anyone thinking about how to arrange people to create innovative products I’d say it’s a must read primer. With a couple caveats:

  1. The “open source” and XP methods are for building products, not for inventing new ones. The article illustrates why they don’t work well for inventing new things. We need some vocabulary to distinguish between innovation teams and building teams.
  2. Either the implementation of the methods or the description of them lacked key elements of what make them work. Open source is not simply an unstructured group of people contributing independent pieces. In Linux, for example, code is tested and reviewed by a central committee. And XP uses structured roles for programming vs. reviewing.

The explanation of getting team size right alone is worth reading the article for. Some expertise on the team is good, but too many people create friction in the process and impedes progress. Also see What Makes Teams Work?