Tiempo Development and the Agile Business

I have heard a future of business organization, and it sounds as if it works.

After ten years of hearing companies only begin to appreciate agile development and then agile marketing, I certainly was not expecting to hear a company organize its management, its strategy, and its planning around a company-wide agile process. But when Tiempo Development, billing itself as yet another agile development outsourcer, gave me a telebriefing last week, I asked the obligatory question and was floored to hear that they had, indeed, done so. 

The Beginning Of The Epic

I am sure that, like many another agile-development startup, Tiempo asked themselves why they couldn’t apply agile principles to management – and yet, others I have talked to stopped there.  Tiempo, however, when faced with the need to begin doing better planning and budgeting as the business scales, seems to have had the guts to take a leap of faith and try to do it via a variant of Scrum, complete with Kanban-type lean scheduling, plus the “epics” and “stories” beloved of agile marketing.  In other words, there’s a five-year plan and budget (and, of course, in an agile organization that’s not set in stone) devolving into yearly, quarterly, monthly, and weekly epics and stories. 

Revisions to the plans are quarterly, flowing forward into a new rolling five-year plan. As in Scrum, daily task sessions and weekly reviews communicate widely, and change flows from below as well as above.  “Customer” feedback comes in laterally and frequently from project customers, as well as from above and below on the plans and their implementation.  To put it another way, the concentrated but broad communication of Scrum ensures the maximum of customer-driven evolution, while the five-year horizon ensures that long-term strategic considerations engage in a delicate dance with short-term customer –driven product specs.

We are long past the time when companies would ask whether agile development scales.  Still, the question should be asked:  how well does a Tiempo-style “Scrumban” management approach scale?  The apparent answer after about 1 1/2 years of practice is:  Quite well, so far.  The reason, I would suggest, lies in the initial establishment of five-year company goals in terms of “rocks”.  That is, the implementing CEO picked about five goals that formed what he saw as the fundamental things that the company needed to achieve over the next five years – the “rocks” in both the foundational and the risk sense. 

Again, as noted, the “rocks” are not made of concrete; they evolve over time, fairly frequently, as the company evolves.  Think of them as “virtual rocks”.  They therefore combine long-term perspective; frequent review based on customer and employee feedback; and a broad perspective, not only for the CEO but also in terms of employee understanding of (and buy-in to) strategy. Plug in more business, plug in new areas, plug in new employees.

To Understand Agile Management’s Effectiveness, Redefine Success

What does Tiempo report as evidence of success in agile management?  Interestingly, they start first with better communications between managers and “line” developers, followed by quick surfacing of bad news for rapid handling, and then “empowering” the employees.  It was only when I probed deeper that the follow-on effects emerged:  more rapid development without other sacrifices, leading to better profitability; greater customer satisfaction, leading to greater follow-on business and willingness of large enterprise customers to trust Tiempo in new areas; and a strong growth path that has the CEO more concerned with avoiding lack of focus via too many new areas than with short-term risks.

It was not a given that this would be so, but in this respect agile management is mirroring agile development.  My survey four years ago found a persistent pattern of comparative focus on change rather than cost, speed, profit, quality, or (downside) risk leading to greater cost, speed, profit, quality, and customer satisfaction as well as “upside” risk, while “downside” risk decreases – all compared to attitudes and processes that do focus on these things.  That Tiempo is focusing on the employee and customer satisfaction parts of the effect is what we should expect if Tiempo is “talking the agile talk and walking the agile walk.” And so, if agile management is indeed like agile development, out of this process we should indeed expect better top-line and bottom-line results that are likely to endure.

The problem is, of course, metrics that will establish these things – because the merits of agile management are not as easy to prove as those of agile development.   A fluke, a Board of Directors and the stock market will call the first agile management bottom-line results, caused by unique circumstances and remnants of past practices.  All these daily and weekly meetings, are they really doing any more than past business strategy fads?  I believe strongly that the answer is resoundingly yes. But I can’t do a survey like the agile development one to prove the point, because there are no obvious speed, cost, and risk-reduction metrics for the CEO’s actions, just customer and employee satisfaction, which have proven misleading in the past.

And so, we are back to CEO “culture”, just as we had to deal with IT and business management “cultures” that were highly resistant to the touchy-feely feel-good aspects of agile development.  Remember, CEOs are the byproduct of a selection process that emphasizes enormous, visible hard work and schmoozing as well as hard-nosed attention to the bottom line, and rewards these by surrounding the CEO with those who understand that their future depends on giving the CEO positive reinforcement, as well as with compensation that most fair-minded outside observers concede is well beyond the demonstrated relative effectiveness of the CEO.  In other words, power and money.  I once took a survey at B school that asked whether I wanted to make money, have power, do good for people, or accomplish something; it turned out that those who answered power or money got much more of both.

I mention this because (and this is only my impression) what really got the CEO excited, talking to me, was his own personal satisfaction – that is, the “accomplish something” part of the B school survey.  And yet, there was no reason he wouldn’t wind up with just as much power and money as my classmates who answered “power” or “money”.  In other words, in the agile world, you can make as much (or more, since the organization should be more successful) money and have as much power, but work less (remember, you’re not running around trying to single-handedly move an ocean liner of an organization or sell the world on your product) and get more real satisfaction out of it, because you can point to shared concrete projects finished successfully, not just praise from those who wish to share in your money.  And so, if the CEO and upper management can make the cultural shift, they may well find that they are better off in every way, including personal satisfaction – another agile paradox.

In fact, it turns out that the creators of agile processes may have been craftier than they knew in calling projects and project groupings “stories” and “epics”.  It speaks to something Tolkienesque in all of us.  A study recently reported in MIT Technology Review suggests that we don’t have fixed memories like snapshots of events, we have stories of the past, and each time we revisit them, we can change them, e.g., to fit new understandings of the past, a new narrative arc.  When I do TCO studies, it’s not all about yes/no, 1-5, and numbers; I ask the interviewee to tell his or her story, the story of him or her in the project.  Set the stage for me, what was your environment; tell me how the project unfolded; tell me what you found were the results; and only now tell me how this affected the TCO that you find justifies the project.  I have found the insights from such an approach far richer and better founded than those from standard surveys, even when the data is sparser.

In an agile business such as Tiempo’s, it sounds as if everyone becomes a hero or heroine in a shared epic that never ends, always new and unfolding.  Oh, and by the way, it should perform better than an old-style business.

Caveats and Not So Bottom Line

I have always been a bit dissatisfied with the analyst’s usual disclaimer:  Your mileage may vary.  Yes, and your hair may grow longer or get cut shorter.  In this case, my real disclaimer is not that agile management may or may not apply to your organization, but rather that I don’t have the figures or real-world use cases to support my belief that Tiempo’s agile-management experience applies well to most medium-sized and large-sized enterprises and organizations. 

Will Tiempo continue scaling?  Does the agile management model appropriate to a small-to-medium-sized software-development outsourcer apply to most other types of business – not the traditional “hardware” manufacturing firm that forms the “unconscious” of all businesses today, and which as far as I can tell is a small fraction of today’s businesses, but the rest of them?  What I see and hear says that it should; but until it happens, there are afaik no decent metrics to show it is working.  Your mileage will probably not vary, but you won’t know the mileage for sure until the end of your first long trip.

No now we can proceed to my not so bottom line – because, remember, agile is about focusing on change, and the bottom line will follow.  Agile development, by now, has thousands of successful use cases. New product development is getting there, and there is now a “hardware” (silicon foundry) use case, as cited in a blog post a while ago.  Agile marketing is approaching its thousandth use case – I note that in a little over a year, the Bay Area agile marketing group has gone from zero members to well over a thousand; and IT is doing its best to keep up.  And now, we have an agile management – and hence agile business – use case. It’s time to start shifting the burden of proof.  Instead of wondering why you should be an agile developer/marketer/business, you should be demanding good reasons why you shouldn’t be.

I have heard a future of business organization, and it sounds as if it works.   Please stop asking about the mileage and start installing the tires.