The Only Legitimate Measure of Agility

29 04 2016

“Oh no you di’unt.  I know you didn’t just say there’s only one legitimate measure of agility!”

Oh yes I did.  That’s exactly what I did.  Not only is there just one legitimate measure of agility, but it’s a very simple measure, requiring only one metric, and a completely objective one at that.

“Obviously, you don’t understand.  Agility is a tremendously complex proposition, requiring many moving pieces, and any attempt to measure it is going to have to take into account at least dozens if not hundreds of different metrics, which will be different from methodology to methodology, and most of those metrics will be untidily subjective!”


An agile culture is indeed tremendously complex, but I’m not going to measure the culture. I’m going to measure the success of the culture, which is a simpler task.


Agility is a measure of how frequently new functionality is released to customers customers customers in production production production.  Significantly, this is not how frequently it’s released to the business in the UAT region.

Why customers customers customers?  Why not the business?

Those of us who are developers are familiar with the phenomenon, discovered only after wading through thundering torrents of human misery, that it’s difficult-bordering-on-impossible for developers to understand what the business wants from them without an iterative process of stepwise refinement.  That’s why we have the business in the room with us.  That’s why we’re constantly pestering them with questions.  That’s why trying to cope without a product owner is such a disastrous idea.

But as hard as it is for us developers to understand what the business wants, it’s at least as hard for the business to understand what the market wants without an iterative process of stepwise refinement.  Harder, because they have not only to know what the market wants, they have to predict what it will want when the software is finished.  The business is undoubtedly better than we developers are at predicting the market, but that’s not saying enough.  Without iterative stepwise refinement of the project’s goals, it will end up being much less responsive to customer’s needs–and therefore much less valuable–when it is finally released. If it is finally released.

Of course, that iterative process of stepwise refinement for the business is frequent releases to production. This is so that the customers, who pay the bills, can see and react to the trajectory of the product, and the business can either A) adjust that trajectory for better effect, or B) abandon the project, if it turns out to have been a bad idea, early before millions of dollars are irretrievably gone.

That’s what the word “agility” means: the ability to respond quickly to unexpected stimuli and change direction rapidly.

The only legitimate measure of agility is this simple formula:


where w is the number of weeks between releases of new functionality to production.

If you release every week, you’re 100% agile.

If you release every month, you’re 23% agile.

If you release every year, you’re 1.9% agile.

If you release twice a day, or ten times a week, you’re 1000% agile!

I know what you’re thinking.  You’re thinking, “What about the single startup developer with execrable engineering practices whose production server is running on his development machine, and who ‘releases’ every time he commits a code change to source control?  Are you going to try to claim that he’s agile?”


Yes I am.

He may not be very good at agile, but he definitely is agile, responding constantly to customer needs.  He’s certainly more agile than a big company that releases only once a year but has dutifully imposed all the latest engineering best practices on its developers.

And if he doesn’t go out of business, it will be his very agility that will force him to develop and adopt better engineering practices, purely in self-defense.  Which is to say, enthusiastically and wholeheartedly, as opposed to the way he’d have adopted them if a manager forced them on him.

You see, that’s the way it works.  Demos aren’t agility. Retrospectives aren’t agility. Pair programming isn’t agility. Not even test-driven development is agility. Releasing to production is agility, and all those other things are supportive practices that have been empirically demonstrated to enable agility to be sustained and increased.

A client says, “If everything goes right, we release about once a year.  We’d like to be more agile, but we have a lot of inertia, and we’d like to take it slow and gradual.  So we put up this card wall, and now we’re considerably more agile.”


No they’re not.

They were 1.9% (max) agile before they put up the card wall, and they’re 1.9% (max) agile now. The card wall may or may not be a good idea, depending on how they use it, but it has zero effect on their agility.

I think agile transformations ought to start on the other end.

Do whatever it takes to develop the ability to release to production every week, and then start doing it.  Every week.

If you have new code since last week to release, then release it.  If you have no new code, then re-release exactly the same code you released last week, and complain bitterly to everyone within earshot.

Presently, perhaps with the help of a powerful director or vice president or executive, you’ll start getting some code.  Probably it won’t be very good code, and minutes after you release it you’ll have to roll it back out and return it for repair; but you’ll be agile, and your agility will drive the development team to adopt the engineering practices necessary to support that agility.

That’s the way we do things in an agile culture, isn’t it? We try something for a short time to see if it works, and if it fails we figure out what to do to improve the process and try again.

Maybe the dev team will choose to adopt card walls and demos and retrospectives and TDD and continuous integration and all the rest of the standard “agile” practices, and one or more of us will get rich teaching them how.

Or…maybe…they’ll come up with something better.


Moral Hazard: The Implacable Enemy of Agile

25 03 2012

This is from Wikipedia:

In economic theorymoral hazard is a tendency to take undue risks because the costs are not borne by the party taking the risk. The term defines a situation where the behavior of one party may change to the detriment of another after a transaction has taken place. For example, a person with insurance against automobile theft may be less cautious about locking their car, because the negative consequences of vehicle theft are now (partially) the responsibility of the insurance company. A party makes a decision about how much risk to take, while another party bears the costs if things go badly, and the party insulated from risk behaves differently from how it would if it were fully exposed to the risk.

In more general terms, moral hazard is a situation where it is the responsibility of one person or group to make a mess, and the responsibility of another person or group to clean it up.

For example, for a limited time while I was a kid, it was my job to play with the toys in my room, and my mother’s job to keep the floor uncluttered enough that she wouldn’t fall and break her neck when she had to walk across it in the dark.

So…who won, do you think?  Was the floor always clean, or was the floor always messy?

Of course the floor was always messy.  It was always messy until a rule was made–and enforced–that if my room wasn’t cleaned by a specified time, then I either wouldn’t get something I wanted or would get something I didn’t want.  (Decades later, I honestly don’t remember which.)  The trick was to take the incentive out of the wrong place and put it into the right place.

But this post isn’t about parenting, it’s about company culture.  Here are some more relevant examples of moral hazard:

  • A company has a maintenance team–or a group of them–whose job it is to jump on production problems and fix them when they crop up.  That is, it’s the development team’s job to create production problems and the maintenance team’s job to fix them.
  • Architects come up with designs, which developers then implement.  That is, it’s the architects’ job to create dozens of small but annoying and confusing incompatibilities and discrepancies between their overarching concept of how the system should work and the reality of how the system actually does work, and the development team’s job to make that design work anyway (in the process creating even more discrepancies between the architects’ picture of the system and reality).
  • Some uber-architect in the IT organization writes a Checkstyle (or other) coding standard and mandates that all code must pass the standard before it’s allowed into production.  That is, it’s the uber-architect’s job to create thousands and thousands of build errors, and the development teams’ job to clean them up.
  • Technical people outside the development team must sign off on all code before it goes into production.  That is, it’s IT’s job to create deployment delays at the last moment based on various criteria that have little or nothing to do with actual business functionality, and the product owner’s job to keep customers from leaving because of those delays.
  • Agile coaches explain all the things that each part of the Agile process is supposed to accomplish, and their clients take them seriously.  That is, it’s management’s job to spend a large portion of the development team’s time on meaningless meetings, and development’s job to deliver anyway.
  • Ideas from the dev team for making things better better or easier or faster or more efficient are submitted in writing to a special committee, which at its next meeting–or the one after that, or at the very latest the one after that–will gravely consider them and all their associated consequences.  If an idea is judged to be worthy, the machinery for imposing it on the entire organization will be set in motion as soon as the proper approvals can be applied for and awarded.  That is, it’s the committee’s job to impose incomprehensible, irrelevant, and counterproductive regulations on distant teams that already had an environment all set up and working for them, and the job of those teams to deal with the unintended consequences.

Moral hazard puts incentives in the wrong places for getting anything done.  It destroys morale, it dulls the wits, and it creates endless loops of excuses.  For example:

Product owner: “We didn’t go into production over the weekend?  Why not?”

Development team: “It was the operations team’s fault: they rejected our package.”

Product owner: “Why did you reject their package?”

Operations team: “It wasn’t our fault: the Checkstyle analysis blew up with over 700 coding-standard violations.”

Product owner: “Why did you submit a package with over 700 coding-standard violations?”

Development team: “It’s the architect’s fault: there’s no way we can track down and fix that many violations and still get your functionality into production on time.”

Product owner: “Why did you create a Checkstyle configuration that was so out of whack with the way our team codes?”

Architect: “It’s the development team’s fault: we have to have some standards, otherwise we’ll end up with a whole base of impenetrable code that nobody dares change!”

Product owner: “Why don’t you have any standards?

Development team: “Uh…”

The real answer to that one, of course, is one that the development team probably won’t give: coding standards are somebody else’s responsibility, not theirs, so they aren’t used to thinking about it and don’t really care.  Likewise things like simple design.  They’re not responsible for the design, and making official changes to the design is so painful and time-consuming that it’s much easier not to think about design at all, and just hack in fixes where the official design doesn’t fit reality.  Testing?  Sure, they’ll have to make a token effort in that direction, but as long as the Emma coverage numbers are such that the code passes the externally-imposed checks, it doesn’t really matter how good or bad the tests are, because if there are problems the maintenance team will catch them.

In a situation like this, the drive to excellence inside the team is largely extinguished, for two complementary reasons.  First, the culture is designed so that excellence is defined by people outside the team, so that any ideas the team has to make things even better are therefore by definition not excellence (or else said people outside the team would already have had them), so they are resisted or even punished.  Second, it’s just not the way things are done.  Mediocrity is a way of life, and anything completely intolerable will be taken care of by somebody else in some other layer of company bureaucracy.

Any team member who has a hunger for excellence must surmount both the why-bother and the you’re-gonna-get-in-trouble obstacles before he can accomplish anything.

The thing that has made Agile so successful, in the places where it has been successful, is the fact that it puts the incentives in the right places, not the wrong places.  To the greatest extent possible, the rewards for your successes and the consequences for your failures come directly to you, not to somebody else.  You are given not only the power but also the incentive to better yourself, the project, and the organization, and whatever stands in your way is made big and visible, and then removed with alacrity and enthusiasm.

Many organizations believe that they have adopted Agile by instituting certain of the practices that Agile coaches tell them are part of Agile, but they retain a company culture shot through with moral hazard where many of the incentives are counterproductive.

For example, in a truly Agile environment:

  • There is no separate maintenance team.  The development team is responsible for a project from conception to end-of-life.  If there’s a production problem that means somebody rolls out of bed at 3:00 in the morning, then it’s somebody from the development team responsible for that project.  If the project is so buggy that its dev team spends 80% of its time fixing production issues, then until the project is much healthier, that dev team isn’t going to get many new projects.  Hence, the dev team is going to do everything it possibly can by way of testing to make sure the project is ready for production, and by way of logging so that if there are issues forensics will be quick and easy, and by way of simple and open design so that any problems can be fixed fast.  And they’ll do this without any scowling remonstrances from a stern-faced architect outside the team, because the built-in reward for success and consequence for failure is worth much more to them than anything he could offer anyway.
  • Developers come up with designs, which they then vet–should they decide it’s necessary to avoid becoming a maintenance team–by consulting with architects who know the whole system better than they do.  The architects have no power or responsibility to approve or reject; their job is merely to act as information resources.  Hence, the designs will be better and simpler, because they spring up from reality, rather than down from an ideal.  The architects will know more about what’s really going on, because they’ll be doing more listening and less telling–and because if they don’t, development teams will prefer to interact directly with other development teams to find out what they need to know and make the highly-paid, expensive architects superfluous.
  • If Checkstyle or one of its competitors is used at all, it’ll be used because the team has decided it will be helpful, and the standard it enforces will be tailored to the team by the team, not imposed on the entire organization by somebody with a Vision who actually writes very little code.
  • The product owner, not anyone in IT, decides when the code goes into production and is responsible for the result.  If the product owner puts code in too soon, he’ll be responsible for the negative experience the customers have: but that’s appropriate, because they’re his customers and he knows what’s important to them.  At least he’s not likely to put the code in too late, because as the product owner he knows which barriers to production are important to his customers and which they don’t care about.  Wanna place any bets on where he’ll stand on Checkstyle violations?
  • The team’s cadence–iteration length, end/start day, standard meetings, impromptu meetings, etc.–is determined by the team based on the requirements of the project and the needs of the product owner.  Fly-by-night Agile coaches may pass through and provide consultation and advice, but it’s the team–not management, not IT–and the product owner that decides what works best for the project.
  • Finally, anyone on the team who has an idea to make things better or easier or faster or more efficient can directly implement that idea for the team immediately, with no submission process or lengthy approvals more involved than bringing it up after standup one day and getting thumbs-up or thumbs-down.  Whatever it is, it doesn’t have to affect or be imposed upon anyone else in the company.  If it turns out to be a good idea, other teams will notice, inquire, and imitate: voluntarily, on their own, because they’re attracted by it.  If it turns out to be a bad idea–and let’s face it, nobody can say for sure whether a newly suggested practice will have unforeseen and unintended consequences–then it will slow down only one team for an iteration or two before being abandoned, and the company will cheaply learn something valuable about what doesn’t work.

If a company labors to adopt Agile, but insists on keeping the moral hazard in its culture, the change will be limited to a few modifications in practice, but no significant increase in velocity, efficiency, quality, or morale.  Furthermore, people in an environment like this will look around and say, “So this is Agile, huh?  What a crock!  This sucks!”

But what if the company is also willing to put the incentives where they belong, as well as adopting practices that those incentives have shown to be useful in other organizations?  What if IT is told that its purpose is to serve and support development teams as they direct, and the development teams are told that if IT doesn’t support them properly, they’re to bypass it and do whatever’s necessary to get into production?  What if development teams are told that their purpose is to serve and support the product owner, and that if they don’t satisfy their product owner, he’ll go find another team?  What if the product owner is told that his purpose is to serve the business, and any demand made on him by development or IT that doesn’t move toward satisfying the needs of the business can be rejected out of hand?

In a situation like that, moral hazard will quickly become Big And Visible, and it can be dealt with promptly.

As a matter of fact, one might say that an Agile transformation should consist chiefly of a quest to expose and eliminate moral hazard, and that the various practices for which Agile is so well known will automatically trail along behind because they’re the best way anyone’s found so far to operate in a low-moral-hazard environment.

If you adopt economical driving habits, you’ll end up putting less gasoline in your tank.  But if you skip past the economical driving habits and just put less gas in your tank, you’ll end up muttering grim imprecations as you trudge down the highway with a gas can.

Programming Language Blues

16 11 2011

I spent some time recently putting together a list of pros and cons for various programming languages for a large (thousands of devs) Java shop that tests after in Ruby. (Ruby 1.8, not JRuby.) We’re bucking for approval to write a greenfield project in something more modern than Java.

The project will require high-volume data processing.  There’s a big relational database, many MQ queues, and web services galore.  We’ll be modifying a couple of existing web applications, but not writing any from scratch–at least not of any significant size.

Several folks on Twitter have requested to see the list; here it is. If you read carefully, you may detect the barest hints of bias.  Enjoy.

Java Advantages:

1. Lots of people know Java.

2. Extensive installed base of support in the form of software libraries.

Java Disadvantages:

1. Difficult to learn in a modern Agile TDD environment, because it predates many of the concepts on which Agile and TDD are based.

2. Very verbose, compared to modern languages. Example:

def ageMap = [Kurt: 29, Dan: 45]
val ageMap = Map ("Kurt" -> 29, "Dan" -> 45)
(let [age_map {:Kurt 29 :Dan 45}])
ageMap = {'Kurt' => 29, 'Dan' => 45}
let ageMap = Map.fromList [("Kurt", 29), ("Dan", 45)]
Map<String, Integer> ageMap = new HashMap<String, Integer> ();
ageMap.put ("Kurt", 29);
ageMap.put ("Dan", 45);

3. Weighted down with obsolete concepts the rest of the community has moved away from, like checked exceptions and static typing without type inference.

4. Glaring lack of closures.

5. Compulsively imperative syntax in a season where the industry is of necessity moving toward functional programming.

6. Concurrency primitives are very low-level; hence non-trivial concurrent programming is nearly impossible to get right and nearly impossible to fix if it’s not gotten right.

7. JUnit, the most popular testing framework, is definitely showing its age alongside more modern rspec-like frameworks; Java syntax pretty much precludes anything rspec-like that’s not distracting kludgework.

Groovy Advantages:

1. Dynamic typing makes writing powerful tests very easy.

2. Almost a superset of Java; easy to learn for Java programmers. (Most .java files will compile and run without modification as .groovy files.)

3. Receptive to a functional style of coding.

4. Much more concise than Java; therefore less error-prone.

5. Modern testing frameworks already exist for Groovy.

6. JVM language; compiles to .class files just like Java; instantly and completely compatible with all existing Java libraries and frameworks.

7. Healthy and growing Groovy community.

Groovy Disadvantages:

1. Over-use of dynamic typing can make program code difficult to read.

2. Dynamic typing means the compiler can offer much less help than in a statically-typed language.

3. Dynamic typing means that deciding at runtime what a given method call means is a non-trivial operation; performance is lower than statically-typed Java, for which the meaning of a method call is always clear.

4. IDE plugins for Groovy are notoriously bad, both because Groovy’s dynamic nature fundamentally limits the amount of help they can provide, and because they’re immature software. IntelliJ IDEA has the best Groovy plugin, but it’s still bad compared to the worst Java plugin. (Update: I’ve been informed that the Groovy plugin for the SpringSource Tool Suite version of Eclipse is much improved in its newest version; I haven’t been in STS for a number of months.)

5. No better than Java at concurrency.

Scala Advantages:

1. Statically typed, so that the compiler can give significant help and performance is at the same level as Java.

2. Much more powerful and flexible type system than Java’s.

3. Smart type inference engine, so that types are not overspecified and change is easier.

4. Syntax is more logically consistent than Java’s; easier to learn for beginning developers than Java.

5. Tremendously powerful language in general; ease of writing domain-specific languages in Scala means that it can be made even more powerful in particular areas of interest.

6. Functional programming is built into the language, although imperative programming is made simple as well.

7. Significantly more concise than Java.

8. Features such as implicits provide many of the advantages of a dynamic language without the disadvantages.

9. High-level concurrency primitives–actors, in particular–are built right into the language.

10. XML is native syntax in Scala: you can write XML literals in Scala without putting them in strings.

11. Enough like Java that Java programmers can quickly learn the Java-like imperative side of Scala and become productive, then absorb the goodness of the language more slowly.

12. Modern rspec-like testing frameworks exist for Scala–for example, ScalaTest.

13. JVM language; compiles to .class files just like Java; instantly and completely compatible with all existing Java libraries and frameworks.

14. A prospective hire who knows Scala is likely to be a significantly better developer than a prospective hire who only knows Java.

15. If you spec a project in Scala, and word gets out that you’re becoming a Scala shop, throngs of said significantly better developers will be pounding on your doors to get away from J2EE.

16. Large and growing Scala community; may be the fourth most popular language behind Java, C#, and Ruby.

Scala Disadvantages:

1. Powerful syntax requires powerful compiler; compile time can be twice or three times as slow as Java.

2. Scala programmers don’t grow on trees (although they’re not that hard to create), and Scala shops attract the ones who already exist.

3. Scala IDE plugins are, like Groovy plugins, still immature; but Scala plugins can provide more assistance than Groovy plugins because Scala is statically typed.

Clojure Advantages:

1. By far the coolest language in common use today, except for J and maybe Erlang.

2. Almost completely functional; provides future-proofing against the coming wide swing toward functional programming, and eliminates much of the hassle associated with writing tests for imperative languages.

3. More flexible and powerful than an object-oriented language–especially a partially-OO language like Java; can be made to act OO for people who are uncomfortable outside OO.

4. Much more concise than Java.

5. Optionally-typed; dynamic typing when flexibility is needed, static typing when performance is needed.

6. The testing framework distributed with the language itself, clojure.test, already beats JUnit.

7. High-level concurrency primitives–agents, futures, promises, and software transactional memory, in particular–are built right into the language.

8. JVM language; compiles to .class files just like Java; completely compatible with all existing Java libraries and frameworks.

9. Small but growing Clojure community.

Clojure Disadvantages:

1. Syntax is wildly different from anything most Java programmers have seen before.

2. Imperative programmers will be uncomfortable at first with the functional style of coding that Clojure pushes heavily.

3. Clojure programmers don’t grow on trees, and are not easily created unless they already have a passion for learning.

4. Lisps have always had academic interest, but every Lisp so far has faded eventually into obscurity in the business world. If ever a Lisp could succeed, it seems Clojure has the best chance; but Clojure may end up fading too.

Ruby Advantages:

1. Dynamic typing makes writing powerful tests very easy.

2. Receptive to a functional style of coding.

3. Much more concise than Java; therefore less error-prone.

4. The original rspec was written for Ruby; JUnit & Co. cough and choke in its dust.

5. Ruby community is the third largest after Java and C#. Ruby programmers are easy to find.

Ruby Disadvantages:

1. Syntax is different enough from Java to make for a fairly steep learning curve (steeper than Scala, not as steep as Clojure).

2. Ruby is notoriously slow, especially in its own virtual machine.

3. Not a JVM language; no access to existing Java libraries or frameworks; if used with JVM languages, much code will need to be duplicated.

4. Dynamic typing means the compiler can offer much less help than in a statically-typed language.

5. Ruby is no better than Java at concurrency.

Haskell Advantages:

1. Pure functional language–or as pure as it gets, anyway. All data is immutable. Easy to test, easy to understand, easy to reason about.

2. Statically typed, with a type system so powerful that Haskell programmers claim, with some justification, that the compiler can find all your bugs before you even run the code.

3. Powerful high-level semantics offer both conciseness and descriptiveness.

4. Performance is high.

Haskell Disadvantages:

1. Syntax and semantics are both wildly different from anything most Java programmers have seen before.

2. Imperative programmers will be uncomfortable at first with the functional style of coding.

3. Haskell programmers don’t grow on trees, and are not easily created unless they already have a passion for learning.

4. Not a JVM language; no access to existing Java libraries or frameworks; if used with JVM languages, much code will need to be duplicated.

Cage Match

14 10 2011

As I’m currently on the bench between engagements, my company sent me out to interview for a gig with a small local company that creates third-from-the-bottom-tier websites for startups.

Let me explain what I mean.

A bottom-tier website, in the definition I’ve chosen to use here, is one that serves up nothing but static data: that is, it’ll have a front page with your company’s name, logo, contact information, and a blurb or two about the business you’re in, recommendations from previous clients, and so on, but it’s essentially just a point of presence on the Web that gets you into search-engine results and not much more.

A next-to-bottom-tier website is one that has some functionality behind it, but that has been created without any programming expertise using one of a hosting company’s standard creation wizards.  Maybe there’s a user database and a shopping cart and an RSS feed, but they’re all standard building blocks hooked together in a standard way by the site owner without any build-time interaction from developers.

A third-from-the-bottom-tier website, like the ones this company creates, has the same active building blocks, but there’s also a comparatively small amount of real custom business logic involved that has to be coded by real developers.

The operative issue for this company is that since the startups (two- and three-person companies) it works for don’t tend to have big budgets, it has to complete these simple websites quickly–sometimes on the order of just hours, more often in a month or less, occasionally as long as three months–so that it can afford to hire developers who are capable of doing the work.

To that end, the company depends heavily on Spring Roo and several custom plugins that let it generate most of the code for a new website in just a few minutes so that they can spend the rest of the time on cosmetics and business logic.

So I was interviewing with the CTO, and I spent some time arguing with him about whether his small budgets and reduced cycle times would be better served by an Agile process or by the compressed-SDLC/waterfall process he was using.

I’d like to explore some of these questions a little further here, but I’m hampered by two things.  First, there’s my obvious prejudice in favor of Agile.  Second, while the CTO has obviously read a fair amount about Agile, he has never had any direct experience with it, leading to certain misconceptions that couldn’t be addressed in the space of a job interview.  Perhaps interested readers can compensate for these failings, where they appear, in the comments.

Issue: No interaction with the customer between requirements specification and demo of finished product

CTO’s position My position
The customers, by and large, are not technical people and don’t care about technical issues. We’re the technical people. If we run into requirements that are not completely specified, we use our heads to make the best guess and build it in, and the customers are generally fine with that once they see it. Technical people should decide technical issues; but non-technical issues are not really their forte. If a non-technical requirement isn’t completely specified, it’s probably because the specifier didn’t think about it especially hard; perhaps if he had, he would have uncovered completely new requirements without which the project will be significantly poorer.
If we show the site to the customers before it’s done, they’ll want all kinds of other stuff too. They’ll creep the requirements, we won’t get finished by our deadline, and we won’t get paid. Creeping requirements are a good thing, not a bad thing. It means the finished product will come closer to meeting the customers’ needs. Also: more requirements, more money. Don’t deal in time: always work on what the customer thinks is most important right now, and let them stop paying you when the money is worth more to them than the next feature down the priority list.
Our customers are tiny two- and three-person companies. They don’t have time to be constantly babysitting us: they’ve got more important things to do. If we send them a question requesting clarification of a requirement, it may take them two or three days to respond, and their response may just immediately prompt another question. Our schedule doesn’t allow us that kind of time to be waiting around. It’s true that an Agile development process requires high-bandwidth communication with the customer. I feel like this one’s a good point. My best response would be: which is worse, having a feature be blocked for awhile, during which time you work on another feature, or wasting time and funds developing the wrong thing?

Issue: The first time a product sees production is after it’s completely finished.

CTO’s position My position
Almost all our websites use exactly the same components, and we deploy them all the same way on the same hosting service. We know the route to production very well, and have it mostly automated; there’s no reason for us to deploy more often. It’s a good point. There are two reasons for pushing to production early: first, to get a handle on the process; and second, so that your customers can see the product early. You’ve already gotten the first taken care of, and you’re intentionally eliminating the second.

Issue: Project is not deployable until development is complete

CTO’s position My position
We work under very tight schedules; we don’t have the time to spend repeatedly making the code deployable. If you had continuous integration running automated tests, you could easily fix it so that your code was deployable whenever CI was green.
Even if we could get quick at it, there’s no need to deploy early. If you had constantly-deployable code, then customers who ran out of money early could have at least something for the money they had already spent, rather than nothing.  A customer who has run out of money is an unhappy customer, but a customer who has run out of money and who gets nothing for the investment he’s already made is an unhappier customer.
That would require customers to be constantly looking at the product.  Our customers don’t have time for that: their days are full of appointments. Then they’re accustomed to appointments.  One of those appointments could be a weekly demo of the product, closely guided and sharply focused just on what’s been developed that week.  You’d be done in half an hour.  You could leave that version of the code running over the next week on a private server so that they could check it out on their own whenever they had time–even from their smartphones.

Issue: Automated test coverage is very low

CTO’s position My position
We work under very tight schedules: we don’t have time to spend writing tests. Tests make development faster, not slower. They don’t make you type code faster, but they make you think more about what you are typing, and they almost always force you to get it right the first time, so that the time spent later stepping through with the debugger is eliminated.
Some of our developers write tests; others don’t. We don’t enforce a rule; we’re most interested in having them do whatever makes them go fastest. What’s fastest is a Very High Test Coverage environment where everyone can instantly see all the effects of every change. It’s not faster if all you count is the time from when the source file is created to the moment the developer first checks it in as finished; but it’s significantly faster if you wait to stop the clock until it’s really finished, including all the bugfixes made necessary in the new code and in existing and future code it touches.
If you wait to write tests until after the code is already developed, then you know A) what needs testing, and B) how to test it. But I already know what needs testing even before I turn on the machine: everything. And I typically find it quite difficult and time-consuming to figure out how to write tests for code that’s already in existence, written without regard to testability, than I do to simply demand each bit of code into existence with a failing test. [Thanks to Justin Searls for that terminology.] That code is going to be more testable, therefore more accessible, therefore more loosely coupled, therefore better, therefore more understandable, therefore quicker to develop around and to refactor.
A mass of automated tests will make it painful and slow to refactor existing code. Quite the contrary: any significant refactoring of any significant chunk of code absolutely depends for its timely success on VHTC!  Without tests, you’ll be finding subtle bugs in your refactoring for months.  Refactoring is precisely where VHTC comes into its own and shows its real value.

Maybe the tests you’ve seen aren’t the kinds of tests I’m talking about.

Issue: Pairing is rare

CTO’s position My position
We pair occasionally, but we only pair senior developers with each other, and only under emergency circumstances, and generally for long periods–perhaps 12 hours. Hmm. Maybe you and I mean different things by “pairing.”

Issue: Change is expensive

CTO’s position My position
The way we’ve been doing it works for us, even if it outrages your sensibilities. We have a lot of happy customers and we’ve made a lot of money. We’re going to keep going in the direction we’re going at least for another year. Can’t argue with success. You’ll be fine as long as some hungry Agile startup competitor doesn’t come along and eat your lunch.
We’re not yet a big company. Agile would be pretty much completely new to us. It’d take us awhile to learn it; during that time our velocity would be lower, our customers would be less happy, and we would make less money, as well as having the added expense of courses or consultants or coaches or whatever we chose to train us. We can’t afford that now. Maybe after that year. Uh…that is…it’s…I mean…ah…

Sorry, I got nothin’.

Mixing Coaching and Delivery

10 10 2011

After a year and a half of exploring what happens when you try to mix coaching and delivery, I have formed some fairly strong opinions on the subject.

In more than one way, it’s like grinding up an entire bicycle into a barrel of steel filings and then eating them with mustard.

Is it possible? I don’t know. But I’m pretty sure that even if it is possible, it’s not a good idea.

When a coaching-plus-delivery coach is pairing with a client developer and they encounter something the client developer doesn’t understand, the coach has three choices.

A) Be in slow, pedagogical, I-don’t-care-how-many-iterations-this-one-point-card-takes coaching mode, and explain in full detail, making sure the coachee gets it and maybe even doing some spikes on the side to demonstrate concepts.

B) Explain what you’re doing as you bang out the solution, allowing enough drag to answer a few questions, but maybe slowing down only to half speed and not getting distracted from the task at hand.

C) Say, “You should have learned this when I explained it to you last week” and just abandon the client developer, leaving him in the dust in order to crank out delivery.

Choice A has definite value, as it’s the best learning environment there is and builds proficiency in the client developer if the coach is any good. This increased proficiency is the client’s reward for paying confiscatory prices for developer coaches.

Choice C has definite value, as it produces velocity and at least one useful piece of information about the client developer: whether he shrugs, gives up, and goes out to have a smoke, or whether he grabs hold, hangs on, and guts it out immediately, then goes home and sticks his nose in the books to catch up. The client buys unusually high velocity, plus information about whether his developers have what it takes to operate at that level or not.

Choice B has no real value. For a long time I thought it did, but not after long and bitter experience with it. Explanations of that sort seem to have little traction on real-world clients in real-world situations, and they serve chiefly to further frustrate the coach as he abrades his velocity yet again for what he has learned is no good purpose. The client buys low velocity and unimproved proficiency, and the consulting firm looks bad.

We need to keep our coaches choosing Choice A and Choice C appropriately, and rescue them (and our clients, and our companies) from Choice B.

How do we keep our folks in Choices A and C and rescue them from Choice B?

I think we need a changeover point, or at the least a well-defined set of changeover points. An individual coaching engagement should look broadly like this:

1) First, I coach you. Every time a basic question comes up, I’m always in Choice A mode, never Choice C. Make the wrong decision and we’ll have a pleasant, humorous, unhurried talk about why the right decision is better.

2) Now, some well-defined milestone comes up–one that cannot be postponed, at least not indefinitely.

3) Then, I depend on you for delivery. Every basic question automatically gets a Choice C answer. Make the wrong decision and I take the keyboard from you and do it right. Maybe you can cut it; maybe you can’t.

4) Finally (if you can cut it), I trust you to make the right decisions on your own as you crank out the delivery, and I move on to another developer or another team or another engagement.

I should note here that when I say “basic question”, I mean not, “Why are you using a map there instead of a list?” but “Mock? What’s a mock?”

If we have no official changeover point, or if we try to install one but get no support from management, then every coach is constantly having to make judgment calls among Choices A, B, and C, and since he’s always going to be wrong by somebody’s lights for choosing A or C, he’s going to choose B most often, and everybody will suffer.

If we can get a management-supported changeover point, then there’s never any question between Choice A and Choice C for the coach, and he never has to get anywhere near Choice B.

If a manager hassles him about Choice A, he can defend himself: “You agreed that we weren’t going to start seeing real delivery until the changeover point. You want velocity this iteration? Fine, I can give it to you; but it’s going to push the changeover point out an iteration.”

If a client developer hassles him about Choice C, he can defend himself: “Hey, you’ve been through the changeover point. You should know this stuff. Are you a software developer or a princess?”

Another reason for management support: if we get management support for the changeover point, the implication the client developers will take away is that after the changeover point, developers who can’t make the grade may get scraped off. From that implication will come questions like, “Say, can we pick a card with lots of mocking in it this time? I’m still a little weak on mocking, and my changeover point is coming up next week.”

“Changeover point” is pretty vague and ambiguous. What do I mean?

Specifically, I mean a changeover point between coaching and delivery. However, in the real world things are a little more complex.

A client developer has to learn a number of discrete kinds of things during a Pillar coaching engagement. For example, at a recent client, a bunch of Java developers and a few Perl developers had to learn Groovy and Grails. They have to understand the concept of a development environment with CI as its nerve center. They have to learn how to write automated tests in general; then they have to learn how to write each different kind of automated test. They probably have to learn to use new technologies, like DBMaintain or maven or git. They have to learn to do little-design-up-front from the perspective of TDD, which is different from the way you think about design when you’re not testing. They have to learn how to pair, and get over the ego- and agoraphobia-related aversions almost everyone has. They have to learn to think in terms of business value rather than functionality. They have to learn various code smells and how to avoid them, and various code patterns and how to apply them.

And any halfway-competent developer coach is going to be able to at least double the length of this list. It’s unrealistic to expect anyone to be a tyro in all this stuff up to a given point, and then to be an expert in all of it.

So instead of one changeover point, the optimal situation would probably be to have more than one, where you have to concentrate on the basic stuff to pass the first, more advanced stuff to pass the next, and so on.

For example, I really wish we could have seen how BJ Allmon’s plan for a recent client would have worked out.

On one of the teams there, we decided that a new client developer entering the project ought to be able to run a one-point card all by herself (except for very minimal help, on the order of “Hey, you misspelled that!”) from beginning to end, including any defects, after three weeks of coaching. That requires a certain level of aptitude in a few fairly low-level skills, and the developer can get a definite feel for the skills required by going through some representative one-point cards with her coach.

And we decided that that same developer, after six weeks on the team, should be able to run a three-point card all by herself with the same very minimal level of help. Three-point cards require both different skills and more aptitude in already-acquired skills.

We never got to see how this would have worked in real life; but I had high expectations for it. Something like this: “Bill is still an Egg, because he just started, so we’ll be coaching him exclusively. Mary passed her one-point test, so she’s a Tadpole. We’ll coach her too, but harder. Jeff, on the other hand, is through his three-point test and a full-grown Bullfrog. He’s a hair-on-fire high-velocity delivery hound, and solidly in Choice C territory.”

I’m going to recommend that something like this be part of any future coaching engagements I’m part of.

A Parable of Agile Transformation

10 10 2011

“We want you to help us get to the point where we can compete in the Indianapolis 500.”

“Do you want to win it?”

“Well, sure, I guess that’d be nice eventually and all, but for the time being let’s just look at becoming competitive, shall we?”

“Sure, sure.  All right.  Well, first, let’s have a look here at the kind of car you’ll need.  This, for example, is the car that Jacques Lazier drove in 2007.”

“Heh.  That’s pretty funny.  No, we’re pretty happy with the vehicle we have.”

“You’ll never make it with an 18-wheeler.”

“Well, that’s what you’re here for.  Our 18-wheeler can carry 80,000 pounds of cargo.  How much can your funny-looking little car carry?”

“That’s not the point.  The Indy 500 is not about carrying as much weight as you can, it’s about carrying as little weight as you can.  The less weight, the better.”

“But look how small it is!  Where’s the sleeper cab?”

“There’s no sleeper cab.  There’s no second driver.  Indy races aren’t long enough to need more than one driver; they’re over in a few hours.”

“I don’t like the fact that it only has four wheels.  Our truck has duallies for a reason: if we lose a tire miles from help, we can slow down and run on its dual partner until we get somewhere where we can get the tire changed.”

“An Indy car is never more than one lap from a complete full-service rebuild shop, and it goes fast enough that it can coast into the pit with a flat tire or a blown engine.  And anyway, the tires don’t have a chance to get old; we change them at least every hour.”

“Yeah, and that’s another thing.  Reliability.  Our big rumbly low-RPM diesel engine is just better than your little snarly thing: we haven’t had to do any major service on it since the 1980s!”

“But there’s no need for that kind of reliability in the engine of an Indy car: it’s torn down and completely rebuilt after every few hours of operation!”

“And what’s with those stupid-looking wings on the car?  Those’ve gotta be just needless expense.”

“You’ve never experienced the need for a wing, because your truck can’t go fast enough to use one.  But when you get up to Indy-car speeds, you have to have wings because if you don’t you’ll go flying off into the grandstand.”

“But your car isn’t even street-legal!  Where are the headlights?  We’d end up in trouble with the law with that thing!”

“The Indianapolis Motor Speedway is a private track, not a public road.  Street laws don’t apply.  Besides, the Indy 500 is always held in the daytime.  Headlights would be useless extra weight.”

“Well, mostly we were hoping that you could modify our truck so that we could push the accelerator down past level with the floor–you know, to make it go faster.”

Get All These Documents Approved and We’ll Put You Down for Next Quarter’s Release

10 10 2011

How does Agile fit into a company where getting your data supplier to add a field to the data being supplied takes a month?  Where you share read-only access to the development environment with several other teams, and you have to fill out a service ticket to have a change made to it?  Where new technologies and tools have to be approved by department heads before they can be used?  Where development machines cannot be reconfigured by developers, but must be maintained by tech-support personnel?  Where your production hosting service requires six weeks of notice before a production release, and it takes two weeks to assemble the documents describing that release and two more weeks to get them approved?

It doesn’t.  Obviously.  There’s no succession of small changes you can make to a company culture like that that will result in the company becoming Agile.  You can make your team completely test-driven with continuous pairing and everything automated through CI and the most beautiful retrospectives in the industry, and the best it’ll do is get you out to the line you have to stand in a lot quicker.  The line will be just as long and just as slow, and by the time your carefully prioritized stories finally get out to the customer, many of them won’t be of use to him anymore.

That sort of a culture results from layer after layer of process and ceremony being added to catch bad, buggy code before it hits the customer.  By the time it begins to constrain the company enough that it hollers for help, though, the process will be ingrained enough that the people ensnared in it won’t hear or won’t believe that a healthy Agile process produces code that isn’t bad or buggy in the first place.  They may actually be so riddled with Stockholm Syndrome that they like the process and believe the claims that it keeps them safe.

In a case like this, I believe you can’t change the process; you have to bypass the process.  Get a “hall pass” from a powerful ally in the company–perhaps the CIO or the CTO–that gives permission for this one team and this one project to do only what is physically necessary to get a bare-bones, hello-world version of this project into production just as fast as possible.

Hack together your own temporary data-translation code to give you what will eventually come from your data supplier when they get around to it.  (When they do, rip out the hack and use their more complete, professional solution.)  Bonus: if you test-drive the hack, you’ll have automated validation of their solution, when it comes, and if they like they’ll be able to look at your tests for a rigorous definition of what you want them to do.

Send somebody to Best Buy to pick up some machines to turn into pairing stations.  Download whatever you want onto them.  Decide among yourselves whether you’ll even tell the tech-support people about them.  Probably you won’t want to tell the department heads about them, at least not until you’ve gone too far to go back.

Set up your own development environment in a virtual-machine appliance and install it in VirtualBox or VMWare on each development machine and CI. (That idea comes from Justin Searls.) Have your sponsor tell the DBAs to provide you with a JDBC connection (or equivalent) and the necessary firewall holes and leave you the heck alone.

Deploy your code into production in the Cloud.  Provide your own production support for it: if you’re test-driving correctly and deploying automatically, there should be precious little production support to do.

Do whatever you have to do, but get into production!  Make a serious attempt by the end of the first week, so that you can have the bugs worked out and succeed by the end of the second week.  Thereafter, release to production every week at the latest and preferably more often–maybe much more often.

Users will love this–even if your application is really ugly at first.  Product owners will love it, because the short feedback loop will provide lots of guidance and energize the developers to produce massive volumes of value in amazingly short time.  By the time the rest of the IT crowd shambles together to assemble against you, you’ll have a lot of people on your side.

And once you’ve got that first project essentially finished, you will be in a very good position.  First, you’ll have established a proven way that things can demonstrably be done: the IT establishment won’t be able to call it hypothetical pie in the sky.  Second, if you’ve done it right, your project will be under budget, under deadline, and fraught by few or no defects–and the code will likely be the best code anyone in that company’s ever seen.  Finally, you will have presented all the forces for transformation with a terrific argument against all the forces of status quo.  All the product owners will be saying, “I want my product done the new way, not the old way.”  The developers will be saying, “That way looks like a whole lot more fun than this way.”  The CFO will be saying, “You’re telling me that switching everything over to the new way will save us seven million dollars a year?!”  The customers will be saying, “Wow: they sure got a lot more responsive and attentive all of a sudden.  Wait ’til I tell my friends!”

The IT establishment may hate you for that, sure enough; but if they do, they won’t be around long enough for it to be a problem.