Lowering the cost of change is a frequently cited benefit of adopting agile development and extreme programming, in particular. You’ll frequently see graphs drawn that show an exponentially growing cost curve as the cost of change for a waterfall project and graphs that show a level or even down sloping (after an initial ramp up cost) cost curve for XP projects.
I personally have been in involved in projects where the down sloping cost curve was actually achieved, so I know it is possible. I also know it is rare; on other projects a flat cost curve was all that was achieved. Both are good outcomes, but what is the cause for the differences in these projects? How does a project actually achieve low costs of change?
However, before exploring how to lower the cost of change, defining the cost of change is necessary. I frequently see discussions about the cost of change that center around the time or effort required to implement a story. While not wrong, I think this perspective is too narrow and short sighted. This definition is not affected by a team that is “going in circles”. But who cares if they can go in circles really fast?
Mary Poppendieck has discussed a Maturity Model of Software Development. (She has a presentation on this and an article published in Software Development magazine. http://poppendieck.com/maturity.htm) The basic idea is that what matters is how quickly and reliably can an organization take a user request and deliver it in the software. This is the cost of change I wish to focus on: the amount of time elapsed and resources spent on taking a user feature and having it present in the software application.
Now, returning to analyzing the cost of change itself, there are two considerations: what contributes to the cost of change and how does agile development help lower it.
Contributors to the cost of change:
- time to assess and prioritize a user request
- overhead for specifying a story
- “churn” in stories
- number of changes to code base to implement story
- cost of release
Time to Assess and Prioritize a User Request
How is feedback handled? How many people are part of the decision? The longer it takes for a sales person to communicate a user requirement to product management, have it prioritized and then worked on by engineering, the hight the cost of change. Similarly, the number of people (or worse yet, committees) that must approve or deny the request, the higher the cost of change.
Overhead for Specifying Stories
The time and number of people it takes to specify a story and complete set of acceptance tests affect the cost of change.
Story Churn
The higher the number of times a feature area is revisited, be it because of bugs or revisions due to what was delivered wasn’t quite what user’s wanted, the higher the cost of change.
Code Base Changes Required to Implement a Story
The time it takes to assess and discover the necessary code changes and to implement them impacts the cost of change.
Release Cost
What is the overhead to a release? Is there a manual QA cycle? How long does it take? Documentation done at the end?
How can Agile lower the Cost of Change?
The primary mechanism for lowering the cost of change is bridging the gaps between the user, product owner, developer and application. (For more on this, please see this blog post.)As the gaps are closed, the application tends to be in alignment with the user requirements.
Practices such as an onsite customer and acceptance tests help develop a shorthand of communication between the product owner and the developers. Thus, the overhead of specifying stories tends to go down and existing acceptance tests and infrastructure serve as templates and extension bases for new acceptance tests.
Iterations provide many benefits. They allow opportunities for injecting feature requests, shortening the time between a user’s initial request and when she sees it in the product. Iterations, combined with engaging a cross functional team in each iteration, keeps activities such as documentation and exploratory testing in step with development, shortening release cycles.
Finally, the engineering centric nature of XP encourages the application, and more importantly the underlying code base, to become ever closer to expressing the user’s intentions and needs. It is very gratifying as a developer when your code base almost anticipates new user features.
I think software teams should actively try to measure, monitor and lower the cost of change. The complete “cost chain”, from sales to development, needs to be included and managed. Agile practices, such as XP, will provide a lot of guidance for improving the elements closest to the code, while applying general agile principles, such as cross functional teams, iterations, high communication, emphasis on feedback, can help the other aspects not directly involved with development. An organization that can successfully manage and lower the cost of change will achieve significant competitive advantages such as lower cost and time to market. Organizations that can’t manage the cost of change will have trouble competing at all.
August 15th, 2005
I think in a software project there are varying notions of reality regarding the actual application being developed. They are:
- actual needs of the market or user base
- product owner’s vision of the application
- developer understand of the goals and requirements of the application
- code base and actual executable application
This is
represented in the following diagram:
The gap between these perspectives is normal, particularly at the start of a project. However, I think it is difficult for a project to succeed if the gap is not being closed; there needs to be alignment and overlap among the different viewpoints.
One of the motivations of agile software development, at least in my opinion, is to help close these gaps. The high bandwidth of communication, intense collaboration, emphasis on feedback and the importance of acceptance tests are techniques to communicate the assumptions, needs and current state of each different constituent. With each iteration, the gap should be bridged a little more.
This raises an interesting question: How can you measure or monitor the shrinking (or worse the expanding) of the gap?
I don’t think you can measure this directly. However, there are a variety of indicators that can help evaluate how well you are closing the gap.
Bugs are probably the best indicator. A bug represents a mismatch in expectations, understanding or communication. Bugs are reported when a calculation is incorrect as well as when a user doesn’t like the number clicks it takes to perform an operation. In both cases, there are one or gaps between what the user needs and what the application is providing; perhaps the product owner specified a requirement that made the user experience awkward or a developer missed a test case. If your bug rates aren’t going down it is an indicator that the gaps are not shrinking. I suggest assessing the cause for the constant (or growing) bug rate by evaluating which gap is the widest. Understanding where the communication / comprehension breakdown exists is the most important step in resolving it.
There are other indicators as well, such as the amount of churn in stories (requirements) and the overhead of specifying stories. If you are revisiting the same areas of the application frequently, whether the reason is user dissatisfaction or defects, there are gaps between the user and the product owner or between the developer, user and code base.
There are ultimately two reasons for closing the gap: delivering a product that users like (and will buy) and lowering the cost of change. One reason is a huge component of succeeding today, the other allows you to succeed tomorrow. When the gaps are small and there is alignment between the user, the application and all those in between, you will probably have a winning project.
August 9th, 2005
My blog has not seen a post in a long, long time… My last post even promised that I would post more.
Excuses aside, I do sincerely plan a lot more posts in the coming future. As I noted in an earlier post, I have taken a position at one of my clients, Nominum. I’ve been an employee a bit over a year and it has been a very interesting experience.
I’ve been ranting for a while that XP is an engineering practice and that there is more to successful software projects than what agile development offers. I’ve been critical about the silence (in my opinion) of the agile community and literature on the missing elements that actually have the largest impact on a successful project. I had theories (some at least partially verified in my experience) about the interdependencies between the various elements of the “value chain” in a software project.
My experience at Nominum has smacked me in the face with all the things I’ve ranted about. Its confirmed many ideas, but also posed many challenges. It is still a work in progress, but I revisted and revised many of my ideas regarding XP and agile software development. I plan to post about them in the near future.
August 9th, 2005
This is my first posting since March. That’s a long time. Since my last post I’ve left consulting and I am now currently the VP of Engineering for Nominum, Inc.
I started at Nominum as a consultant, to lead their Scrum and XP adoption. I decided to stay and a major reason is the quality of the team. They are genuinely one of the best teams I have ever been exposed to. (I am not the only consultant who “defected” and joined the company, the coach of the XP team did as well.)
I am looking to add people to the team, about two or three developers. A recent candidate told us “we are the dream team” anyone could hope to work with. I feel the same way. I generally enjoy coming to work everyday. So, enough of a sales pitch. If you or anyone you know wants to join an XP team, send me an email, resume, smoke signal…christian.sepulveda@nominum.com
Our team room….
(P.S. My grand executive office has been “converted” into a nice coffee lounge for the team, as I don’t use it. We have a very nice Gaggia espresso machine in there.)
October 20th, 2004
There have been many discussions about the appropriateness of the term “tests” in describing the unit tests created during test driven development. Most of the debate has centered around the overloaded use of the term “test”. For many, the expectation of testing is to discover bugs. There are also many forms of testing, such as usability testing and exploratory testing. Generally, I think the traditional role of a tester (and most forms of testing) are about the act of discovery.
Test Driven Development is more about verification than discovery and I think this is one core motivation of TDD. In TDD, you specify your expectation first, then write code to satisfy it; the test verifies this contract.
Though I am not making any grand revelation, I think there is a subtle importance in the distinction I’ve made. I was recently asked about test coverage, completeness and TDD. There has been a lot of interest and research regarding test coverage and completeness. There have even been attempts to provide formal proofs of correctness for software programs. The desire is to have a verification mechanism. TDD does provide good test coverage of code bases, though it doesn’t guarantee there will be no bugs or other unexpected behavior. TDD simply provides a mechanism for verifying that declared expectations have been satisfied.
Since I think testing is more about discovery, I think it is a very different type of activity. One of the challenges of testing is that you never know when you are done. Therefore, it is somewhat pointless to ask about test coverage or completeness. How would you define “complete”? The act of testing is about the discovery and refinement of expectations. As expectations are discovered, a verification can be captured, satisfied and automated.
There has been a lot of debate regarding the need of manual testing compared to automated tests. For me, if I use the moniker verification, there is no debate. Verification operations should be automated; testing should not.
March 13th, 2004
This is a revised posting. I got a little carried away with my math in the example. Sorry.
I was working with a team that had been gradually adopting agile practices, but the developers were resistant to practicing Test Driven Development. At one point, I decided to start tracking how much time was spent compiling code, running the application/debugger, re-establishing the context in the application, observing a result and then closing the application. The developer would think about what he observed, make code edits, start the debugger and repeat the cycle. I observed that it took four minutes on average to run the cycle of compile, launch debugger, find context, etc. This would be done an average of eight times per hour; the remaining hour was spent thinking and making edits.
One half of each day was completely wasted. The developer couldn’t really doing anything productive during the four-minute debug cycle because he had to navigate to the corect place in the application and execute the right steps so he could observe the results of the change he just made; he was forced into tedium. In other words, half the development budget was being spent on performing repeated, monotonous tasks. This isn’t a very effective use of resources or talent.
The development world has been doing this for years. My analysis may seem a bit naive; the lost time I refer to has been considered a necessary overhead in order to receive feedback. The feedback is necessary but this method of getting feedback is not.
Consider the use of TDD. The same developer makes a code edit, runs an automated test suite and in seconds gets feedback of the impact of his change. Besides knowing the expected impact, the developer knows the impact of his change on the system as a whole, performing a validation of his expectation and regression check in one step. (My analysis of the four-minute debug feedback cycle didn’t address the time spent determing the system impact of code changes).
Faced with such results, the team in my example did adopt TDD. Their feedback loop was reduced to thirty seconds. In the example, there were eight edit cycles per hour. Previously, thirty two minutes were being used to get feedbak regarding an edit, so twenty eight minutes were being used to make the actual change, consider options, checkin code, etc. This is roughly three and half minutes per edit, for eight edits per hour.
So now, an edit cycle costs a total of four minutes, which doubles the number of edit opportunites. The greater the number of opportunities you have to introduce edits, the faster your progress. This, in my opinion, is one of the reasons teams using TDD go faster. They get similar feedback they would have received in a debug cycle, but it is compressed so much that it empowers the team. The team has so many opportunities to try something, they can afford to experiment with design changes, clean up code or simply move forward. Not only will the team go faster, but the resulting code is generally more flexible, resusable and readable. (I haven’t enough discussed the benefits of regression testing and its related cost savings.)
So the when faced with people resistant to TDD, maybe the question isn’t why to use TDD, but how can you afford not to?
January 12th, 2004
Maybe the customer shouldn’t write the acceptance tests, or at least all of the acceptance tests. I know this sounds like heresy, especially coming from an XP coach. But let me explain…
I’d like the customer to write the acceptance tests. I think they must be intimately involved in the acceptance testing of an application, as the customer is determing the features. But, within the XP literature and discussion groups, there is an emphasis on the customer’s providing the acceptance tests. Work cannot and should not begin until this happens. If the customer can’t define acceptance criteria for a feature, how can she expect a developer to fulfill her expecations.
I think there is a small contradiction here. One reason for small iterations, an important agile and XP practice, is that it provides feedback, mitigating the “I’ll know what I want when I see it” syndrome. So, if the customer is inexperienced playing the role of an XP customer, she may not know how to provide acceptance tests.
Consider a developer who is new to test driven development. In my experience, learning how to precisely define the expectations of functionality before you write the code can be a challenge. How do you test the layout of widgets on user interface? Should I test color and font? An XP coach know he must mentor developers when learning TDD. No one expects a developer to magically adopt this skill.
So why do we expect the customer to magically have the ability to write acceptance tests? At least developers are trained in logical and cognitive activities; the customer may not be.
Some customers are naturally adept at writing acceptance tests. Such a team can only benefit from such a customer. But what about the others? I think they should be trained, mentored, assisted and extended the same patience a developer would be when learning TDD. The feedback and experience of completed iterations should dvelop the customer’s skill at generating acceptance tests.
There is another reason I don’t think it is fair to expect the customer to be soley responsible to write the acceptance tests. Frequently, the domain logic of a system has complex boundary cases and permutations that require careful analysis. Not all customers are comfortable or capable of this analysis. Developers could add a lot of support to the quality of the project, if they view this as their responsibility. (A skilled tester would probably be even better, but this is a different story.) I think the notion of an cohesive, collaborative team means all team members should support the goals and results of the project.
In practice, I know most XP teams and coaches will support the customer and acceptance tests when necessary. I am not proposing an excuse that allows the customer to shirk any responsibility. But I preceive a disconnect in the published attitutude of the XP community and reality on this topic.
December 11th, 2003
Lately, I’ve been trying to explain the reasons why dummy-data classes are a smell in software. Dummay Data classes are classes that do not have behavior, only data.
I thought of a different way to illustrate the problem, as the common arguments have not seemed sufficient lately.
Consider scrabble. When someone presents a word that is challenged, one of the first comments made is “Use ‘fazooloo’ in a sentence.” A response such as “I was playing scrabble and I was asked to use ‘fazooloo’ in a sentence” is generally not appropriate. Besides being sarcastic, the sentence doesn’t convey anything about the meaning of the word. The questioned term was the object of the sentence and performed no action of its own. You could substitute any term and the sentence does not lose any meaning, but doesn’t improve either.
A dummy data class is like a term that can only be used as an object in a sentence. If no sentence exists in which the dummy data class performs the action, it has no purpose but to be manipulated by others. This has various implications, such as encapsulation violations, but I think the sentence analogy simplifies the reaons to avoid dummy data classes.
Martin Fowler has a bliki post about Anemic Domain Models. One characteristic that makes a domain model anemic is the lack of behavior in the objects. Furthermore, I think the domain objects must have domain behavior.
This distinction can have subtle design implications. I worked on a system where we had an elabrorate domain model (or so we thought), but the classes where really dummy data classes. When I pointed this out, others on the project claimed that since the objects knew how to persist and load themselves from the database, that this was their behavior. But from the domain perspective, the objects did nothing. Furthermore, if you then look at the implemented design, there were other smells such as violdation of the Single Responsibility Principle, as the objects where part domain, part technical infrastructure. The design of the system would be greatly improved by starting with the elimination of dummy data classes and following your nose from there.
So, when designing your classes and their collaborations, make sure each class passes the Scrabble Test.
November 27th, 2003
Brian Marick recently posted a blog entry noting the importance of marketing agile development to executive management. As stakeholders, management stands to gain the most from agile development.
The timing of Brian’s post is somewhat coincidental, as this topic has been on the forefront of my mind. I think the next phase of generating agile adoption is to bring the campaign to management. It bothers me that I see mostly developers and technical professionals at conferences and very, very few members of management, particularly senior management.
I’ve been discussing this topic with people much smarter than I, in particular my wife. She has an MBA and works in marketing. Based on my discussions with her, the following are some ideas for raising the visibility and adoption of agile development methods to senior management.
Audience
Executive and senior management, particularly CIO’s and CTO’s, should be the demographic of this marketing effort. This poses some challenges, as such managers are generally removed from the actual development efforts and don’t have much first-hand knowledge of the problems with traditional, heavy-weight methods. Making matters worse, middle management frequently withholds details about complications and, at times, reports a more successful depiction of projects than reality. Middle managers (those in the trenches) are the real “customers” of an agile process, but they are invisible; they have low public visibility and are a needle-in-a-haystack for a marketing plan.
Part of the challenge will be educating senior managers, while “saving face” for the middle managers, as we ultimately need their support.
Brand
Brand, brand, brand. It is the key to marketing. A brand defines the expectations of the vendor / product for the customer. It is the reason you choose product A over product B. For example, Nike caters to the “hard-core” athlete, be it recreational or professional. Volkswagen is about the “serious driver”. Such strong psychological and emotional elements are quite common in consumer brands, but they can have a place in business brands as well.
This is the first action item for the Agile Alliance: define the brand of agile development. More precisely, what is agile development? The answer must be succinct and precise. It may vary for different audiences, but the core message must be the same.
This is a major challenge for the agile community. There is much debate over the question of “what defines agile?” and “which methods qualify as agile?”. The goals and ideas of the Agile Manifesto, Agile Alliance and agile community have developed and are continually being revised.
But in order to have a brand, we must appear to speak with one voice, with one consistent overriding point of view. A brand defines the product. Consider the situation in which a business is choosing among multiple vendors. An organization will not trust a vendor whose message waivers and doesn’t appear to have its act together.
Furthermore, the agile brand needs to be about more than ROI or business value. How would this be different than the claims of any other methodology, particularly the high ceremony, traditional processes? The ways in which agile development is different are important, but so are the commonalities of agile development and any other sound business theory or practice. (We can’t have claimed to re-invent the wheel; business types will assume they know business better than we do.)
This doesn’t mean there must be one agile methodology. The Agile Alliance can be the “parent company” that has multiple product offerings, each appropriate to a different context. But the overall message must be clear and consistent. We must determine the 30-second elevator conversation that answers the question “Who is the Agile Alliance and what is Agile Development?”
Getting Started
Many people don’t know the Agile Alliance even exists. Its important that people associate agile development with the Agile Alliance.
I think the trade shows, conferences and journals that cater to CIO’s/CTO’s are a good start. I don’t know what efforts have already been directed toward this, particularly sponsored by the Agile Alliance.
I know there was an executive track at ADC this summer. I don’t know how successful it was. I think tutorials, seminars and workshops targeted to executives are a good idea. I think the agile community should invite any contacts they have in executive management.
I also think we should “recruit” the help of those in the business world. For example, Rob Austin is a Harvard Business School professor who has a strong interest in agile development and his research is about software development. I believe many in the agile community have a good relationship with him (among others). These individuals can be valuable resources.
Information Resources
Assuming we get the attention of executive management, we need to be prepared to provide information that is relevant to them and directly addresses their concerns.
Agile Roadmap
There needs to be a catalog of agile practices and some guidelines regarding their approach. The roadmap section of the Agile Alliance website needs to be flushed out. (I happen to have a particular interest in the is topic, as does Steve Berczuk.)
Statistics
Executives will want metrics that quantify ROI of agile development over other methods, adoption rates, success rates, etc. Information from the Standish Group’s Chaos report would probably be useful.
Challenges
The Agile Alliance is a non-profit group that doesn’t control or directly sell agile methods. Therefore, the requirements are similar to those for the consortium that markets milk.
I would expect an executive to request referrals from the Agile Alliance and she would expect the referred consultant (or firm) to deliver an “official” agile development process. Once you build the brand, it is important to maintain that relationship and protect the trust and expectations of the market.
This raises some concerns. How should the Agile Alliance provide endorsements? (I think some form of a referral service will be necessary). Questions about certification are a natural progression, which opens a huge debate. For example, a few months ago many in the agile community (including myself) went on the record to oppose SWEBOK. Will we eventually need to form our own version of SWEBOK?
This is somewhat a moot point. There are many strong forces already trying to standardize the industry. It might be negligent of the Agile Alliance to not cast its hat in the ring. This also becomes more important as agile development goes mainstream; most existing practitioners of agile development understand the principles of agile and faithfully practice it. I fear many mainstream adopters will claim to be agile and not understand it.
The challenge for the Agile Alliance is to remain “agile” and not bureaucratic, while maintaining some degree of conformity and unity. Brand integrity is necessary for successful marketing.
These are just some ideas. I think some attempts have already been made to market agile development to executive management. I think devising a marketing strategy raises many issues that the agile community must face and make decisions about. This will challenge us, as formal organization general complicates a good idea.
November 3rd, 2003
Currently, I am working with a team that is transitioning to XP. Besides coaching the team, I am coaching one individual to be a coach so he can eventually be the team’s coach. As a result, I have been thinking a lot about the nature of coaching. In an earlier blog post, I noted some of my thoughts on the abstract and theoretical components of coaching. Here, I am sharing (for what its worth) some practical guidelines for an agile coach.
Identify Expectations
Start by identifying stakeholders. I consider a stakeholder to be anyone that has an interest in the outcome of the project or will be a participant. I include developers, managers, testers, marketing staff, technical writers, and others. For each member of this list, I try to identify what are the expectations and goals of the member (or group). I prioritize the expectations and assign a weighting. I actually treat the expectations as XP stories. I will use 3×5 cards; I track the member or group that “sponsored” the story, its weighting (or cost), and priority. (I know there are other techniques, such as some multi-letter acronym matrix; these alternates always struck me as too complicated).
Take an Agile Approach
Without getting too metaphysical, I take an agile approach to coaching. (See this blog post on qualifications of an agile process.)
feedback
Retrospectives are an invaluable feedback mechanism. They should be done at the end of each iteration and the feedback received should be enacted upon.
Johanna Rothman suggests one-on-one meetings with all team members on a consistent basis. Depending on team size, this can range from every week to every few weeks, but I think the more frequent the better. Fifteen minutes to a half hour is sufficient, but the individual attention will be appreciated It provides a more secure and comfortable opportunity for feedback. I even suggest conducting these sessions offsite when possible or over a meal (or both).
discovery
Returning to the gathering of expectations and identification of stakeholders, a coach should regularly review these lists and evaluate if the expectations are being satisfied, how have they changed and who are the current stakeholders.
unencumberment
Besides the expectations of stakeholders, try to identify their primary activities and support these activities. In Scrum, the Scrum Master insulates and protects the developers so they can work efficiently. I think the coach should try to do this for the entire team. Unfortunately, this can be complicated to achieve as frequently the needs of one stakeholder are in conflict with that of another (Remember, developers and management are stakeholders). The expectation list should give some guidance for evaluating compromises and tradeoffs.
sustainable pace
Regularly assess the team’s progress. When possible, try to assist, mentor or in some way help any team member that is having difficulties. Look for buy-in for the process and build on it. Hopefully these early adopters will help champion the cause as a team needs to take ownership over their process. Otherwise they won’t maintain it or maximize its effectiveness.
synergy
Each of the suggestions supports each other. Retrospectives help discover expectations and needs, etc.
Ultimately the coach is part leader and part manager. In my opinion, the ideal coach doesn’t have to do much as time goes on; the team chugs along by their own steam.
This is particularly fun for the XP coach as you do all this and write code too! (Context and expectations of the coach will determine the balance of activities the coach will do.)
(Ron Jefferies and Bill Wake conduct a nice tutorial on being a coach. There is a good book list that can be found at http://www.xp123.com/xplor/xp0307/index.shtml.)
October 15th, 2003
Next Posts
Previous Posts
