The Simple Math Behind TDD?

For those who have followed this blog or read the book, you might know that I called Chapter 13 of SSA “Concurrent Testing” and not TDD (Test-Driven Development). I talked about TDD in the book, but I didn’t specifically prescribe it. TDD says:

1. Write the test
2. Run it and watch it fail (meaning build it permanently into the test harness and execute it there)
3. Write the minimum amount of code necessary to pass the test
4. When it passes the test, go work on another story!

At the time I wrote the book, TDD was still a little edgy and had not crossed the chasm to the mainstream, even the early agile mainstream. It it just hard for some developers to get their head around this early investment in test case development as it changes the way they think about coding (though for the better).  And I suspect that is still likely the case. So I was generally happy with the Concurrent Testing chapter, because it drives teams to be able to “unit test-acceptance test-component/feature test-system test”, all in the course of an iteration. Good enough for me.

However, last week I was with a client along with Amir Kolsky of Net Objectives. Amir is a TDD expert and proponent and he advised the client to always “write the test first”. We had a minor debate about the differences in viewpoint. After all, if the team leaves the short, two-week iteration with everything tested, isn’t that about as good as it gets?

Well, actually not. Amir led us through this “simple TDD math exercise”.

First:

Next:

and finally:

I had to admit that I had seen plenty of rework time (Rt)in recent iterations so it was fairly easy for me to support this simple conclusion.

After our meeting, I attended iteration demos from a number of teams and I saw quite a bit of Rt there too.

Ok, write the test first!

Advertisement

Reaching the Agile Enterprise Tipping Point – A Workshop

Recently, I’ve been working with a number of large companies who are reaching the agile enterprise tipping point. In most cases the development teams or some outside agents have introduced agile as a potential solution to a host of problems – productivity, quality, time to market, whatever – but the managers and executives aren’t quite ready to “take the plunge.” Their reticence may be due to lack of understanding of the methods themselves, the “agile is just for small teams” rallying cry of critics, too many agile Dilbert cartoons, or just the understandable fear of change on such a large scope. (No professional Agilist has ever said “this will be easy”).

No matter the source of their reticence, if management can’t be tipped, the organization can’t be tipped and the benefits of enterprise agile adoption will remain just out of reach.

Over the last year or so, I’ve worked in a number of such situations and have come to the conclusion that the best way to help an organization reach the tipping point is with an onsite workshop, which focuses on enterprise agility for certain, but as applied to each companies specific context and challenges.

I put together this workshop data sheet for one such enterprise and it occurred to me that it might be useful to some others as well. Here it is:

Reaching the Agile Enterprise Tipping Point: A Two Day Workshop

Also, I’ve restructured the Services page on this blog to highlight some additional packaged services. These could serve as a potential roadmap for those enterprises in the process of “taking the plunge” into agile development.

More on the Agile Release Train – Internal vs External Releases

In a number of posts, including Enterprise Agility – The Big Picture(5) The Release Revisited I’ve commented on the desirability of separating Internal Releases (or Potentially Shippable Increments) from External or General Availability Releases. Although not directly represented in the Big Picture itself, this is the assumption behind the Agile Release Train graphic in the model. This creates a separation of concerns that allows development to work on the fasted possible pace, producing PSIs at an even and fast cadence, while the market and our marketing teams make the appropriate decisions as to what gets released to customers and when.

In a recent article entitled to To Release No More or to Release Always, posted for free download at the Cutter Consortium, (note you’ll need to enter the promotion code RELEASEMYTH) Israel Gat of BMC comments on this model as follows:

Think of the in-pipe in this example as engineering and the out-pipe as the business. Engineering can post releases at its own pace. The business can selectively choose from the posted releases. In this paradigm, marketing is not obligated to promote a release upon its completion. Marketing might do so in three months; it might choose to promote the current release with another release due at a later time; it might choose to make a release available on a limited basis; or it might choose never to promote a release.

He then goes on to note an even more potentially aggressive release postulate:

An intriguing question poses itself if you accept this premise of asynchronous operation. If the business is free to determine how it will promote a release in the market, why should engineering be bound to producing releases in the traditional manner? Can everyone benefit from relaxing the constraints that usually surround a release and move toward a more flexible, fluid release concept?

Ryan Martens, Rally Software’s CTO, commented on both this article and indirectly on the method behind the madness of the Agile Release Train in his recent post at Agile Commons, Ryan notes:

As a result, I coach most agile teams to start by making sure their “internal release” cadence is twice as fast at marketing, operations and the market is used to.  In this way you get a release where you can gain feedback and steer the “external release” to market better.

Couldn’t have said it better myself.

–Dean

Enterprise Agility – The Big Picture (14a): On Agile Portfolio Management and the Legacy Mindset

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing post (see the Big Picture Category on this blog ) we have been working our way from the bottom (stories, iterations and the like) to the top where the enterprise vision and portfolio management resides. In this post, we’ll start a miniseries to describe the last big icon to the left – Agile Portfolio Management.

The Big Picture 14 - Agile Portfolio

A Particularly Relevant Case Study

Recently, while researching this topic for another purpose, I ran across an excellent case study from DTE Energy called: Establishing an Agile Portfolio to Align IT Investments with Business Needs. The article was written by Joseph Thomas and Stephen Baker and presented at Agile 2008. Unfortunately, I did not attend this presentation while I was at Agile 2008, but I found the whitepaper published in the proceedings. It appears to be available at http://submissions.agile2008.org/files/CD-ThomasBaker-EstablishAgilePortfolio-Paper.pdf and I highly recommend it for those readers of this blog that have
product or asset portfolios (and you know who you are).

Here was the introductory “grabber” for me:

“Those who implement agile software development and agile project management in a traditional corporate environment may encounter legacy corporate and IT processes that reflect legacy mindsets and cultures- These remnant processes, mindsets, and cultures represent opportunities to improve the systemic value that agile approaches are capable of enabling.”

This is a reminder that team agility does not automatically engender enterprise agility and in most all cases, the team is just the beginning. The article is surely relevant to the enterprise perspective, because when it comes to scale, DTE Energy is right “up there”:

“DTE Energy, a Fortune 300 is a diversified energy company involved in the development and management of energy related businesses and services nationwide with $9 billion in annual revenue and 11,000 employees. DTE Energy’s Information Technology Services (ITS) organization, now consisting of over 900 people, provides leadership, oversight, delivery, and support on all aspects of information technology (IT) across the enterprise.”

Illustrating the maturity of thought reflected in the article, DTE Energy’s IT teams have been implementing and extending agile practices in their enterprise since 1998, moving through CMM levels II and III via agile practices. They have almost a decade of agile adoption upon which to build their ongoing learning. As reflected in the case study, DTE also illustrates Kaizen Thinking (continuous thirst for improvement) that is the hallmark of top enterprise agilists. Evidently it is just this thirst that drives the agile initiative ever upward until it hits the level of portfolio planning and decision making at DTE.

The Transformation Starts on the Ground

The title of the article, along with the maturity of DTE’s agile implementation efforts, also reflects the fact that building the agile enterprise is a “ground up” exercise. The primary work must start with the development teams themselves. They build all the code. If they aren’t agile, no one is. Thereafter, dealing with many of the challenges at the corporate level, (with the Project Management Office (PMO) often being the control room of the mother ship) is likely to be a significant challenge that must be addressed. For it is there that projects and programs are initially formed, budgets and resources are determined, governance is established and longer term (and not particularly agile) external commitments are typically made. If not successfully transformed, many of the potential benefits of the agile enterprise – time to market, productivity and quality, ROI, revenue and profitability growth – may be heavily mitigated.

However, this next set of enterprise challenges is most easily addressed after the teams have first demonstrated  the substantive productivity and quality improvements of the methods. That way, they’ll be standing on their accomplishments and can serve as an object lesson in what agile could do, if only unfettered.

But for readers of this blog series now is a later time and it’s time we addressed the big “portfolio” icon on the top left of the Big Picture

Legacy Mindsets Can Hinder Potential Enterprise Benefits

DTE’s whitepaper starts with a discussion of the various legacy mindsets that can inhibit achievement of the full benefits of the agile enterprise. These include: “widget engineering”, “control through data”, “order taker mentality” and more. This is an important underpinning for the enterprise transformation we are driving, because one can’t recognize solutions to a problem if one does not understand the problem. These mindsets must be understood and addressed before much agile progress can be made at the portfolio level.

We’ll discuss these legacy mindsets, and more from our own experiences, in the next post.

More on Agile Product Managers and Product Owners

In a recent post, How to be the Ultimate Agile Product Team, Jennifer Fawcett opines on the evolving roles of agile project managers, agile product managers and agile (and traditional) product managers in a fast growing ISV/Embedded systems environment.

Like some others, Jennifer has concluded that the Product Manager role in an agile environment continues to focus primarily on mostly traditional PM responsibilities – market analysis, business case, new products and features, product roadmaps, etc. – while the new Agile Product Owner role focuses primarily on working daily with the team in support of implementation. That’s not to say that the APO doesn’t own or drive the vision for the feature or component that the team has responsibility for, rather it’s more a matter of focus (implementation (APO) vs. market needs analysis (APM) and the level of abstraction (feature or component level (APO) vs. product or system level (APM).

She described her view of the differing responsibilities in the following table.

Agile Product Manager (APM) Responsibilities	Agile Product Owner (APO) Responsibilities
Tracks industry trends	Tracks internal cadence and deliveries
Defines release objectives	Defines iteration objectives
Provides overall strategic direction	Provides day-to-day tactical direction
Delivers business level use cases or stories	Provides system level use case or story elaboration
Has a solid understanding of current solutions	Has an understanding of architectural component and subsystem design
Defines external roadmaps	Defines user acceptance tests
Manages release and portfolio priorities and backlogs	Manages the iteration and cross project priorities
Manages the changing needs of the market and customer base	Unblocks and focuses the portfolio or feature teams throughout the iteration
Manages market messaging and positioning	Defect scheduling
Provides the overall vision	Provides the implementation
Lives in Marketing	Lives in Engineering
Communicates daily with the Product Owner (shares a brain with the PO)	Communicates daily with the Product Manager (shares a brain with the PM)
Delivers The Release	Delivers The Iteration

Perhaps more importantly, she goes on to note that building an effective set of relationships between these roles requires Collaboration, Partnership and Trust. For that discussion, I refer you directly to her article.

Enterprise Agility – The Big Picture (13 continued): Estimating Epics

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing post (see the Big Picture Category on this blog ) we have been gradually working our way from the bottom (stories, iterations and the like) towards the top to where the enterprise vision originates. In the last post Portfolio and Vision, we briefly described the Epics that drive so much of the behavior of the agile teams at Level 1 and 2. In this post, we’ll talk about Epic estimation.

Big Picture 13 (continued) - Estimating Epics

Everything Starts with the User Story

Before we discuss estimating Epics, however, we must return to Level 1where the teams do their work. In an earlier post, we discussed the User Story.  This is the artifact used by agile teams to communicate the basic intent of the behavior of the system, heavily weighted towards descriptions which clearly deliver value to the user. User stories are captured and maintained in a team’s Backlog, where they are prioritized, estimated and held until they are to be implemented. Estimating user stories is a team skill that all agile teams must master. The aggregate amount of story points that a team can deliver in the course of the iteration is the team’s velocity, and every agile team has one and maintains it routinely. Velocity represents the amount of user value (number of story points) that a team can deliver over any particular time box. Story points can be measured in the abstract (story points) or as Ideal Developer Days (IDDs), with the abstract measure being the most common.

To learn how to estimate points in the abstract, teams are taught relative estimating, often with the simple exercise below:

Exercise: Assign “dog points” to each of the following types of dog to compare their “bigness”: Labrador Retriever, Dachshund, Great Dane, Terrier, German Shepherd, Poodle, St. Bernard, Bulldog.

With this exercise, teams learn how to assign a “relative bigness” to each dog (or story) without debate or concern for the actual units of measure. Then they use that scale to estimate their upcoming stories and after a few iterations, they know their initial velocity (story points per iteration) by counting the points for all completed stories. When teams change size, or vacations or holidays occur, they simple adjust the expected velocity in each iteration and plan for a greater or lesser number of stories as indicated.

Estimating Delivery of Features or Epics

At the Feature or Epic level, our estimating model can be the same and it builds on the basic agile estimating team skill. We simply estimate these bigger items relative to each other and maintain the relative estimates in the Release or Portfolio Backlog. However, while that part is relatively straightforward (but admittedly it is not so straightforward to compare unlike things to each other), even relative sizing gives us no idea when a team can possibly ship what.

For this next step, we are dependent on the Big Picture’s model of expressing system behavior in terms of the parent-child relationship implied by Epics, Features, and Stories:

>> Epics cause Features to exist; (features are “children” of the epics that spawned them)

>> Features cause Stories to exist; (stories are children of the features that spawned them)

>> Stories are the native implementation unit and are also used to measure Velocity

All that is well and good but it still doesn’t tell us anything about when we can deliver what to whom. For this we need some tracking information which allows us to translate Epics into story points. Fortunately, competent agile project management tools (every agile enterprise will likely have one) support this hierarchical model and will have captured historical story point data for earlier Features and Epics. Given an understanding of what percentage of the team’s time we are willing to devote to the new item, we can use historical data  to predict how long it will take to deliver a new Epic. (Example: Epic A was implemented in about 1,000 story points and took X months; Epic B is a little bigger, therefore B will take a little longer).

The Estimated Cost of an Epic can also be Derived

This provides a rough estimate of the time it might take to deliver an Epic based on teams (and teams of teams) actual velocity. It still doesn’t give us any notion of cost. While the teams themselves may not have a one-for-one translation of a cost of a story point, at the portfolio level it is fairly straightforward to calculate one. Simply, look at the burdened cost for any timebox for the set of teams most likely to implement the new Epic and divide that by the number of story points they achieved in the same unit of time. This gives an estimate of the cost per story point for the subject teams in that domain. So if a story point costs, for example, $1,000, then more story points cost more.

A Big Note of Caution

I suspect that you’ve already applied caution enough with this imprecise, yet effective agile estimating model. However, one additional and critical factor is the assumption that all a team’s story points can be dedicated to a new initiative. That is rarely the case as most teams run from 20-50% of their total capacity supporting the existing product with necessary features that are “below the radar” of the portfolio level, as well as resolving defects, performing research spikes, refactoring and other work items that may not contribute so immediately to new user value. So in applying this model, one must be aware of how teams measure their velocity and base the time estimate (but not the cost estimate) on the velocity which is actually available to be used for new Epics.

That’s it for this post. The next post will likely be a miniseries (a post or two or three) on that last big box to the left, the Agile Portfolio.