Michael Feathers

Zeno-Length Iterations

 I’ve been thinking about iterations quite a bit lately.  To me, they’ve always been an odd part of Agile.  Scrum gave us the month long sprint, and for years it was sacrosanct.  The thought was that it wasn’t possible for teams to do real work in less time.  In Extreme Programming, we had two-week iterations, but at least it wasn’t a hard-and-fast rule.  The primary consideration we had was that no matter how you picked your initial iteration-length, you should at least keep it constant and not give in to the temptation of saying “well, we’re having trouble finishing our stories for this iteration, let’s extend it for a few days.”  

From the very beginning, the goal of iterations was to force tradeoffs, hard decisions.  Without that discipline, development can really fall off the rails.  Teams need to know how to bring work to closure and there’s no closure quite like being able to say: “this functionality is tested and shippable right now.”

The odd thing about iterations, though, is that you don’t really need them.   Or, at least not everyone does.  This was a bit of a shock to me.  I remember working with a team back in the 1990s that had three-month iterations, and things weren’t really ever getting to closure except in the last few weeks.  There was no urgency and they suffered because of it.  This reinforced the idea that iterations really were necessary, but then I heard about programmers in some trading companies that pushed code into production continually.  It was odd, I thought.  It must be weird not to work with a macro cadence or rhythm – no sense when you go home that you’re closer to realizing a large concrete goal that you’ve had for the last week or month.

Later, after the first wave of agile, I encountered high performing teams that had gone completely iteration-less with no ill effect.  Today, Lean and Kanban are popularizing this model.  Regardless, I do feel that iterations teach a valuable lesson.  They teach you how to really bring work to closure.  It’s a very valuable thing to know, and once you know it, many other things become easy in software development – going iteration-less is no big deal.  I do think, though that there is another piece of learning we can get from iterations that is hard to achieve any other way.  I guess I can describe it as an experiment:

Suppose that you had an iteration of one week, followed by an iteration of 2 days, followed by an iteration of 1 day, followed by an iteration of one-half a day, and so on.  If you still had your sanity at the end of this process, would you have learned anything?  I haven’t tried it with a team yet, but here’s the thing that I hope would come across: if you apply enough ingenuity and you’ve acquired enough skill, you can deliver business value in shorter times than you can currently imagine. 

Time boxes are a constraint.  They force conversation and force tradeoffs.  And, really, that’s not a bad thing.  It’s fertile ground for creativity.

Look at your product today.  If you only had one day to develop and deploy some feature, before putting the product on ice and letting it generate revenue as is forever, what would it be?

 

From People to Programming..

I went to the Agile2009 conference this month, and enjoyed it a great deal.  I have deep roots in that community.. people I've worked with.. people I've known on and off for close to 10 years.  For me, it is a big "catch up" thing.  I pick up things from the sessions but really it's all about the hallway conversations.. people I know and respect who are passionate about delivering software and making the workplace a better place.

I feel lucky that I stumbled upon all of this.  In 1997, I went to the OOPSLA conference in Atlanta, and I was mesmerized by the technical sessions. I was equally mesmerized by the interactive sessions.  In one, I overheard two people talking about how in their consulting job, they had to share a single desk in a half-cubicle, with one of them standing all the time while they were working on their system.  They worked for a huge consulting company, a body shop essentially, and the ethic was "this is the job, your comfort isn't a concern, do the job."

That attitude always terrified me.  I once read a book called 'The Soul of a New Machine' by Tracy Kidder.  It's about a team of young hardware developers racing to build a new computer.  It was 'Death March' before the term 'Death March' was popular. People pulling 18 hour days continually, to bring this thing to life.  The fact is, I love development, and in my 20s, I pulled my all-nighters.  It was intoxicating and fun but when it became expected, it wasn't any longer.  For me, it couldn't be fun when every semblance of choice was gone.

At that OOPSLA, I was lucky enough to stumble into a room where Kent Beck and Ward Cunningham were doing a "birds of a feather" session on pair programming. I'd never heard of it before.  Sure, I'd done it, but when I had I felt guilty.  I felt that when I paired with someone I was wasting company time.  Here were two guys who not only said this was okay and productive, they were also talking about selecting a good chair for programming.  Selecting a chair!  It's hard to convey now how much this impacted me.  Here were people who were saying that you don't have to leave your self at the workplace door, that you can do a great job without shorting yourself and treating yourself like a work tool.

It's amazing how much things have changed since then.  I think that Agile is part of it, but some of it is generational and some of it is economic.  I think that the ethic of "it's the job no matter what" is a legitimate human reaction to fear of failure in a short term situation.  You get people to set everything else aside and focus.. you take all of that wishy-washy human stuff and pull it off the table..  you get together and you climb over the ramparts, hand in hand, with your guns, and if you live, you slap each other on the backs and tell stories over the campfire - that's the life of the tactical hero.  We know, though, that software development isn't a fight or a war.  It's a long game, a game of care and consequences.  Everything we do is sensitively dependent on people, how they feel, what they think is possible in a product.  The game isn't getting through a project and delivering, it's making something very useful, something which fits the user's wants and needs and you win by cultivating startling insights along the way.  That cultivation is the essence of culture, and culture is the essence of successful software delivery in both human and business terms.

Now, having said all of this, I feel myself pulling away from it.  Not the truth of it, but the deeper involvement.  It's been going on for the last couple of years.  One obvious reason is that I'm called less for the "let's transition to Agile" work than the "oh, I've got a big messy pile of code" work.  Life lesson: be careful what you are good at.  The other reason is because I do feel a little out of my element when it comes to remaking a workplace, and let's face facts, that's exactly what transitioning to Agile is, really.  We have the mechanical bits: let's all sit in an open workspace, let's get the customer/product owner involved.  But there are also all of the situational bits, the interface of the team with the surrounding organization, the politics, the fear, meetings with people across an organization about how it all hangs together.  I still love the one-on-one coaching and work with teams.  Everyone has a different view, and what I do is flit from one person to another all day long and help reconcile views, help galvanize action.  Don't get me wrong, it's fun, but it's also..  well.. there's no algorithm for cultural change.  It's a dynamic system and, really, one of my weaknesses is that I like the rush of certainty. I want to abstract away from experience and find what works.

I once told a friend, in a kind of confessional way, that when I'm called in to do a transition, I don't really think about how to help people become more effective, I just walk in and ask myself "would I want to work here?"  And, it's not the building, the project, etc.  It's the feel.  Are people engaged, joyful and proud or are they scared and disheartened? In one particularly odd gig, I worked with a few teams in a company which was going through some rough competitive pressure and some bad history.  As my work with the teams wound down, the sponsor thanked me for all I'd done and and showed me the increase in the quality numbers.. and all that I could think of at that moment was that it wasn't successful by my terms, because I didn't impact the feel in the teams much.  It wasn't what I thought it could be.  It was at that moment that I noticed just how different my definition of success was, how most of it was in human terms.  When it works, it's wonderful and rewarding, when it doesn't you're just left sad and wondering what else you could've done. In a perfect world, human happiness and organizational efficacy would walk hand in hand every single time, but there are times when they don't.

So, I've moved almost completely back into tech.  I spend more time thinking about programming and design than just about anything else work-related recently.  I'm looking for technical solutions and technical patterns. Again, I think it's hard to say how much of this is because of the legacy thing pulling me into the thick of tech and how much is really a matter of choice.  I visit companies with cultures which are all over the map.  Some places are wonderful, some are not so wonderful.  I've seen company cultures get worse and I've seen them get better, and my focus on the team and its technical practices rather than the organization and its bigger issues gives me a bit of distance.  There are people I know who are much more comfortable with that space. 

As much as I love the people stuff, I love the programming, and the cool thing is that it is all connected.  You always have impact. The guy who moves a table to be able to do his work is not a furniture mover by trade, but the table is moved. Saying "how do you feel about that code?" or "what do you think about how your meetings are run?"  You never know where it leads.  

Team Leadership Secrets of Sun Ra and Lope de Aguirre

It’s one of my favorite “beer in hand” statements when I get together with people at conferences: "I'd like to teach a day long seminar about team leadership.  I'd start with showings of Werner Herzog's Aguirre: Wrath of God, and Sun Ra: A Joyful Noise, then I’d follow it up with discussion."

Whenever I say that, I usually get stunned silence and furtive looks at the bartender (cut this guy off!) but I am serious.  I think that those two movies are not only entertaining, but a great launching point for a discussion of team leadership.

Aguirre: Wrath of God is a quasi-fictionalized account of Spanish explorer Lope de Aguirre.  Lope was part of an expedition across the Amazon to find El Dorado (the city of gold).  On the path down the Amazon, he killed two leaders of the expedition (one after the other) assumed leadership, destroyed villages and demanded that the other members of the expedition declare him Prince of Peru, Tierra Forma, and Chile.  In real life, he was shot and quartered.  In the film, he was the last man standing from the expedition, flailing in madness, lording over a pack of monkeys on a deserted river raft as it crept down the Amazon.  The film was a bit more poetic in that regard.

Herzog’s Aguirre (played by Klaus Kinski) is a textbook portrayal of ambition, narcissism, and sociopathy. Kinski’s mechanisations and visual ticks as his character leads his "team" on the mother of all death marches are incredible to watch, and learn from.  If anyone around you acts like Aguirre, run.

Sun Ra: A Joyful Noise on the other hand, is a documentary about a mid-20th century African-American jazz musician (Herman Poole Blount a.k.a. ‘Sun Ra’) who claimed that he was from Saturn, recruited one of the most promising saxophonists of his generation (John Gilmore) and  started a band called ‘Sun Ra Arkeststra.’  The Arkestra dressed up in space aged costumes, created their own rituals and avant-garde music and toured the US and Europe for years.

I'm not going to say much more about Aguirre: Wrath of God right now.  Instead, I'm going to leap into the Sun Ra film. Throughout it, we are led into the world of the band.  We hear Sun Ra philosophize about the world - how it is made of myth and how his myths are as good as anyone else's. Through it all, you notice how much the band is like a cult and you wonder why all of these people fell out of society to go along with something this goofy.  But on the other hand, the film is oddly mesmerizing.  You get the feeling that the band members really didn’t believe that he was from Saturn – that they gave up their normal lives to join this touring band so that they could play, not just in the musical sense but in the broader sense as well.

Everyone knows that cults can be dangerous, recent history is full of examples, but what about a cult that plays on the edge of "play"? Where everyone knows with a wink and smile that they are just playing? I can imagine it being a rather liberating experience.  In the film Sun Ra winks at us. It's all a game, but one he decided to play for fun. It's worth thinking about how much playing we do in real life, really - play which isn’t much fun because the nod and wink aren't there. 

Chef/author Anthony Bourdain once wrote that having a restaurant kitchen is like running your own pirate ship.  If you see work that way, how can it be anything other than interesting?

For years I’ve looked at software development teams and asked myself what makes the good ones tick.  It's hard to single out answers because teams can be good in many different ways.  One thing that I come back to often, though, is the sense that a good team has an inner life.  People joke with each other.  The feel somewhat protected against the other parts of the organization, and they have people who make it fun.  That last bit is an act of leadership and often it comes about because of a strong leader, someone who defines the mythos of the team – who we are, what makes us different?  The person doing this doesn't have to be a manager, but I have seen managers do it.  People who adopt this role instinctually look for the minor dramas that bind people together and foster them.  It's fun to see it when it happens.

There’s a vogue now for self-organizing teams in software development.  That works, to a degree, but as often as not, there’s a certain listlessness to many of them, a sense within them that everyone is always waiting for someone else to step up. Ultimately, I think leadership is an individual action, and it can be an act of play that facilitates good work.  I don’t suggest you jokingly tell your coworkers you’re from Saturn, but there are many actions south of that which might help.

Alpha, Beta, and Gamma Software Organizations

An Alpha software organization uses the latest stable versions of their tools and development languages. It moves as rapidly as prudent and possible to the latest release of, for instance, Python, gcc, or .NET. 

A Beta software organization may not be using the latest versions but it has plans to move to the latest as soon as possible. Beta organizations have solid dates or triggers for the migration. They are either waiting for particular tool vendors to catch up with a language release or for some other part of their own organization to do a roll out.

Gamma software organizations are in limbo. They have no plans to upgrade. These are the organizations which drifting along in Java 1.3.1 or .NET 1.1 or some pre-Cambrian version of C++.

Organizations can get caught in Gamma-hood for a variety of reasons.  One is client dependency.  If you are shipping software to external clients and they can't/won't upgrade their systems, you're caught.  If you're running on your own servers, Alpha-hood is yours to lose, and it's a shame that so many organizations do lose it. 

It's easy to fall off the upgrade path, but, having visited many teams, I notice that the ones that don't fall off perform better. 

A team's upgrade policy seems to be a reliable measure of health and seriousness. 

Porn for Consultants

I don’t watch much TV, but there’s one show that I’m addicted to. It’s Kitchen Nightmares with Gordon Ramsay. There are two versions of the show, the British version and the American version. The British version is a bit better – it’s not quite as fluffed up, but regardless, both shows are worth a look. In them, Gordon Ramsay, a famous chef, goes to failing restaurants and tries to turn them around in a week. And, the way that he does it is incredible. He walks in, tries out the food, criticizes the hell out of it, and then proceeds to tell everyone on the staff just how insanely bad everything is and precisely how responsible they are for it. He doesn’t mince words either. Often every other word is bleeped. A couple of times, he’s gone to restaurant owners and told them to f--- off. It might just be that that’s how you say “pay attention” in the restaurant trade, but I’m pretty sure that it doesn’t work in software development consulting.

Ramsey has some advantages, as a consultant. Every meal service is a new iteration. He can walk in, teach the staff something, and see immediate consequences. He tears people down and builds them up, as needed, but when he leaves, the restaurant is a bit better off than it was before and people know what the problems are. Ultimately, they have to decide whether they are going to solve them. 

The fact is, this is very much like software development consulting, except for the “rough and tumble” bit. And, that’s why it’s porn to me. I think that ultimately, in the restaurant business, you can get away with a bit more because it’s a less polite industry. It’s seen as blue-collar. People yell at each other to get dishes out of the kitchen. It’s expected. In most software development teams, if anyone raises their voice it’s a big deal. Developers walk eggshells with each other, and it can make communication less direct than it should be. But, really, we need to call each other out when good practice lapses in a team. If we don’t, it’s not politeness; it’s abdication.

Ramsay gets results but sometimes it doesn’t work out. In the British version of the series, he goes back to restaurants he’s visited in the past and sees how they are doing. Some take what they’ve learned and continue to make progress; others fall back on old behaviors. I noticed early on that some teams I work with fall back also, and it led me to take a bit of a different tack than Ramsay takes. The question that I always have in mind when I’m working with people is what they’ll be doing after I’ve left. How do I give them something that they can build on and know whether they will own it. Maybe that’s what politeness is for.

Soft Sciences

The other day, I was at the airport in Madrid, lurking around a bookstore trying to find something to read on the long flight home.  The store had a well-sized English language section, but it was stocked mostly with crime and romance novels.  It didn't have any of the history or pop science that you see in larger American airports.  Usually, I settle for one of those.  I bought my copies of Blink and Freakonomics in airports.  They are just the sort of reading that I like after a long gig.. books of ideas that really don't have anything to do with software development, although I often end up relating them back to development out of habit.

I kept looking and I eventually ran across a set of five paperback novels by a writer named Paul Auster.  I'd never heard of him before, but I was tempted to buy all of them.  Each of the books had a back page description that intrigued me, and the reviewer comments looked great also.  I thought it over.  Five books was a bit much, so I settled for two and read one, Oracle Night, on the flight home. 

Oracle Night is the tale of a writer, who after a near-death experience, buys a notebook and starts to write a story about a man who decides to abandon his life and start a new one after a similar experience.  As he writes in his notebook, his own life becomes stranger and eventually starts to shift out of control in counterpoint with the story that he is writing.

The book was great.  It had all of the elements that I've been looking for in fiction lately.  A complicated plot, crisp writing, mystery and a philosophical edge.  When I got home, I looked up Paul Auster in wikipedia and this sentence leapt out at me "Two strong elements in Paul Auster's writing are Jacques Lacan's psychoanalysis and the American transcendentalism of the early to middle 19th century.."

It was then that I realized that something nutty was going on.  This was the fourth time over the past few weeks, that I'd discovered that this guy, Jacques Lacan, was tied into something that I'd seen.

Before I'd gone off to Madrid, I caught a few minutes of a documentary about a man named Slavoj Žižek.  Slavoj is a contemporary Solvenian post-modernist and cultural critic.  In the documentary, he said some interesting things about world affairs, things about the resurgence of nationalism and racism that we see in various parts of the world now that some of the older programs of the 20th century have lost their punch (communism) or succeeded (global capitalism).  He tied it back to a world view that he claimed came from Lacan.  Out of curiosity, I ordered a few books by Žižek and Lacan from Amazon.

The third Lacan connection is a bit weirder.  On reddit, I'd run across a reference to a painting called L'Origine du Monde (The Origin of the World) by Gustave Coubert.  Be careful about googling that one.   L'Origine du Monde is a graphically sexual painting that scandalized France in the 19th century.  And, it turns out, that before it found its final resting place in a French museum, it was owned by Lacan.

The last connection came when I started flipping through a book about Lacan.  It turns out that he had worked with  a psychoanalyst named W.R. Bion who'd done some of the earliest work on group dynamics.  I'd heard about Bion from  Elizabeth Whitworth,  a researcher I'd met at an agile conference. 

So, I have to figure out who this Lacan character is and why I keep running into him.  What I've read of his work so far is interesting.  Lacan extended the ideas of Freud, making the case that the unconscious is structured like a language.  We form our identity in a strange dynamic between the symbols that we use, our ideas about them, and our experience.  He saw psychosis and neurosis as breakdowns in the mind's ability to accept or utilize certain symbols.

There's nothing quite like reading the work of psychoanalysts.  Freud, Jung, Lacan, Bion, etc.  Many people claim that what they were doing was too soft to be science, and I think they have a point.   But, on the other hand, if you take the point of view that they were doing something very difficult, trying to understand the basis of emotional experience and motivation in much the same way as physicists try to find elementary particles, it's easier to appreciate what they were doing.  Physicists have tools.  They can measure.  The things that these early psychoanalysts were interested in weren't measurable.  All they had was observation and inference.  It's like the tale of the blind men and the elephant.  Every blind man tells you something different about what what he's felt, but if you stand back, you might get a sense of the whole elephant.

Anyway, for me this dive into Lacan is interesting.  It gets me out of the binary.  There are thousands of views of human nature.  There's truth in all of them, yet none of them are true.  That's tough to deal with if you want certainty.  But, really, what's fun about certainty?

Prosthetic Goals and Metrics That Matter..

I'm not quite sure why, but I've been hearing a lot of code coverage horror stories recently.  It's great that people are discovering that automated testing is good, but you can't measure quality with coverage.  Yes, coverage does give you a measure of effort.  It does, after all, take effort to get coverage numbers up, but sadly it's possible to get a lot of coverage that doesn't do you much good at all. 

Brian Marick wrote a wonderful paper about code coverage misuse (pdf).  I won't repeat his points here, but the one thing that I'll add is that coverage is a particular lousy measure of a quality effort because ultimately you want the team to pay attention to quality, not numbers.  The numbers might tell you something about quality, but it's dangerous when they start to become a goal rather than the means to a goal.  It's hard to hit one target when, in reality, you're aiming for another one.

I used to call this sort of thing a surrogate goal until Tim Ottinger came up with a better name: prosthetic goal.  A prosthetic goal is something that you hold up as the goal when you want people to achieve some other goal that you can't measure easily.  Want employees to produce more value, add an incentive program.  Want people to work with quality?  Adopt ISO9000.

Sometimes prosthetic goals and your ultimate goals dovetail nicely, but at other times they don't.  There's a gap.  You can spend so much time working on the prosthetic goal that you lose on other fronts.

Want to improve quality?  Then measure quality.  Measure bug count.  Or better yet, measure delays that are due to bugs and try to reduce them.  Time is money after all, and that's money down the drain.

Speaking of wasted time..  I'm hoping that I run into a team someday that measures average build time on developer's machines.  How long does it take for each developer to get feedback whenever they hit the compile button?  There are many teams that could work a lot faster if it didn't take them so long to compile.

Andragogical Challenge

I'm in Poland right now, and I just got back to my apartment after a long day of teaching.  I never thought I'd enjoy teaching as much as I do; I've always been a bit of a loner, so standing in front of a group of people was something that I had to work at.  But, one thing that I've noticed over the years is that the best way to get interesting insights into an area of design or practice is to teach it.  Often when you're in front of a group of people, reaching for an explanation, you find it. 

It's not all fun, though.  One of the things that I battle constantly is something that I call androgogical challenge.  Andragogy is an interesting word.  Many people don't realize it, but the root of the word pedagogy is ped, which means children.   Andragogy is the corresponding  word for the study of adult teaching.  Adults learn differently, and some of our quirks, as adults, trip me up. 

What are the quirks?  Well, one of them is the need to relate to experience.  When you're attempting to help people learn something in programming, choice of examples is critical.  Unfortunately, it is very hard.  If you pick something too easy or too stylized, some people will see it as a "toy example" and "turn off."  They can't imagine how it relates to the work that they do.  If, on the other hand, you choose something which is very realistic, you can end up with overload.  It is hard to highlight the important points in a sea of detail.

So far, I haven't found any set way to tackle this problem, but I know that I constantly have to be aware of it when I teach and when I write.   Examples have to be detailed and realistic enough to engage, but also fertile with interesting decision points.  But, if you supply too much detail you can end up derailed, dealing with points that don't really have as much bang for the buck.  It's a hard balance.

How Long Does It Make Sense to Develop Software?

This is a serious question.

Imagine the startup scenario: a new company with bright plans. If the company needs to have a web presence (and what company doesn’t?), chances are they will hire team of top notch programmers to craft a set of applications to start the business on. The team works furiously for a year, dealing with all of the ins and outs of the business space and at some point requirements start to slow down. The company starts making money and the users get used to the web interface and they react violently to major changes. The company establishes itself and establishes a market. They are going to make money no matter what they do with their website. Development goes into maintenance mode. The original set of programmers start looking around and saying “I don’t want to work on this!” They dust of their resumes and join the next startup. Not everyone leaves, of course. Some people are happy about the reduced pace. They get comfortable and they deal with bug reports and the odd feature request.

That scenario plays itself over and over again across the business world. Startups need to deliver software quickly. They need to carve out a niche. But, if you’re in a business where you can get some guaranteed returns once you line up a good set of customers, the value of software development goes down. It just doesn’t matter much any more. 

A decade ago, Microsoft was a textbook example. In the beginning, software mattered at Microsoft, a lot. They competed on every field that they could, but once they nailed Windows and Office, it seemed that they really didn’t have to write code any more to make money. In many industries, that state of affairs can last a long time. But, invariably the competitors come. What happens then? At the moment when it is most critical to write new code, a company finds that it can’t. Why? Its development skills have atrophied. The developers that built the edifice are gone or off in management and the ones that are left just aren’t used to designing new software.

So, how long does it make sense to develop software? I have a friend who says that over time the best companies will discover that it is critical to maintain that capability and they will do whatever they can to keep it going. It’s the Toyota model: be your own competition and pursue excellence. It seems that Google uses this model. Their developers run wild with new ideas continually. There’s no resting on laurels. But, I wonder how many other companies will take that course? From an economic point of view it’s easy to trim development, treat it as a cost. It’s easy to reduce the challenges and leave it moribund.

My prediction is that we’ll continue to see this cycle in software development and the rewards will go to the companies who can kick-start their development when they need to.  It's hard work.  Often it seems harder than maintaining a development culture. 

Going to North Carolina...

I'm off tomorrow morning to visit North Carolina for a day.  Joe Little invited me to speak at Agile Carolinas, a new user group that's starting up in the area.

I'm going to talk about Coaching Software Development Teams.  It's a kind of an awkward topic for me.  I've been doing coaching work for about seven years, but I find that it is difficult to talk about.  I'm not content to talk about the "feel good" things that usually dominate discussions of people work.  The fact is, you have to make hard choices when you choose to help people along the way toward new skills and better performance.  You have to be there for them and for their employer.  You have to behave ethically and pragmatically, in a way which recognizes and complements the surrounding culture. 

Tough to do, tough to talk about, but fun nonetheless.  If you're in the area, pass by.