How is Agile like a frog in a pot of water?

April 29, 2011
Frog example

Image via Wikipedia

Remember the old tale about the frog and a pot of water?   In essence, if you put a frog into a pot of very hot water, it will immediately jump out.   However, if you put a frog into a pot of cold water and gradually heat it, the frog will allow itself to be cooked to death.

Not to worry — I have never done either of these and I don’t suggest that you do so either.

However, there are lessons from this tale that I believe apply to the Agile development methodology…

I believe that a “successful product” must provide a valuable resolution to one or more needs from your target market.  Otherwise, nobody will buy it.  So when I talk to other Agile practitioners, I am amazed at how little thought they give to getting accurate and reliable feedback from their market.  Many of them make one (or both) of the following mistakes:

Product Owners Focused Solely on Development

The product owners of some companies spend so much time with Development that they quickly lose touch with their market.  Or even worse, allow the product direction to be set by the 1 or 2 customers that they have time to talk to.   Sure, they could talk to a number of customers via email, Skype, Twitter, etc — but you will only get answers to questions that you ask or reactions to significant positive (or negative) aspects of your products.  You may never know that some function takes twice as many clicks to complete as it should or that users are constantly using other tools to compensate for functional gaps in your product.

To know what your customers really “need”, you have to talk to enough of them so that you understand the difference between what a few customers say they want and what your product needs to provide to satisfy your target market.

Note:  If you’re interested in how to do this, consider this article written by Steve Johnson, Luke Hohmann and Rich Mironov  published by Pragmatic Marketing,

Developers Gone Native

Some companies encourage Developers to engage with customers so that they can get first-hand knowledge of what the customers need.    They carefully select the Developers for this task, because some are simply better suited for this type of interaction than others.

However, there are at least 2 problems with this approach…

  1. The Developers can’t spend a lot of time talking to customers — because they are typically senior people who need to be contributing to the product, and
  2. The Developers usually do not have the skills / experience to identify what each customer really “needs” (as opposed to what they say they want) and to synthesize the requirements for the product’s target market from feedback from only a few customers.

As a result, the Developers often focus on providing the capabilities that the customers they have met say they need — almost as if they were working directly (or “natively”) for those customers — instead of providing capabilities that benefit the majority of the product’s target market.

The Frog and the Water

If done right, Agile allows you to get rapid feedback from your market to keep you on course toward creating a successful product.  But your product can “go off the rails” just as easily with Agile if you don’t understand how to obtain and utilize customer feedback.

Waterfall is like the pot of hot water — it provides dramatic evidence of how well (or poorly) your product matches the needs of the market.

Agile is like the pot of cold water — and each iteration increases the temperature of the water in the pot a bit.   So if you do not have good people who are experienced in obtaining and understanding market feedback — you could, like the frog, sit in your pot until it is too late.

What Should You Do?

I believe that each product development team should consist of people who are highly qualified to do their specific jobs.  I look for teams where well-trained engineers are developing a product that is being tested by experienced QA personnel.  I’m not fond of teams where “everyone does everything” — because not everyone can be an expert at everything.

Likewise, your development team should include someone who understands the “art” of obtaining feedback from current (and potential) customers and synthesizing that into prioritized product requirements.  Whether you call this person a “product owner”, “product manager” or something else is up to you.   But they need to spend time at least 25% of their time with your current (and potential) customers.  Otherwise, they will quickly lose touch with what your target market needs and will have to rely on their own opinions, guesses, and/or hopes.

Creating a software product is very expensive and you can’t afford to make very many mistakes, because in many cases your competition is only “one click away” for a current (or potential) customer.  So avoid the temptation to ask developers to do this job “in their spare time” and get yourself a good product manager who can do this job “full time”.


Does Agile development work for ALL software products?

November 2, 2010

I think most people involved in developing software have a reasonable understanding of what Agile / Scrum development is all about.  The general idea is to get customer feedback early and often so that you can adjust the finished product to something that is almost guaranteed to be what the customer wants.

The Scrum project management method. Part of t...

Image via Wikipedia

This is clearly a much better idea than the traditional, or waterfall, approach where you spend months figuring out what the customer wants, more months building it, and then hope (or pray) that the customer hasn’t changed their mind or that the market hasn’t moved while you were doing all the work.

And history is full of examples of products developed using the traditional way that didn’t get close to living up to their original market expectations because they were obsolete or out of touch with their market the day they were introduced.

However, when you listen to some Agile zealots talk — you will hear things like “there never was a product that couldn’t be developed using Agile”.   Frankly, this reminds me of “one size fits all” which anyone over the age of 5 knows is simply not true — especially in today’s market where every customer wants it “their way”.

So with your help, I would like to identify products (or situations) where Agile development may not be the best approach.  The goal is to avoid trying to force-fit Agile where it clearly won’t work and to identify how to adapt Agile concepts in other cases so that we can get the best possible product in every situation.

OK — I know this is ambitious and possibly not achievable.  But a journey of many miles begins with a single step.  So let’s get started by talking about some product types where Agile will have problems:

  1. Embedded Software — The software that runs all of the “electronic” modules in your car are a good example, including the ABS system, the throttle control system, and the fuel injection system.  Obviously, you can’t ship an interim version of this software to your customers and ask for their feedback — they wouldn’t know how to test it.   And imagine if the software had a bug, the car accelerated out of control and someone was injured or killed.   How would the manufacturer explain that it was only a “test” version of the software? (Hmmm, this sounds vaguely familiar for some reason…)   Lastly, it takes a long time to ship a product like this to a customer.  So even if you could get customer feedback, it would come so long after the development had been completed as to be nearly useless to the development team.
  2. Enterprise Software that Requires Customization — This is an idea that I described previously, so I will summarize.  Imagine that you provide a customer with software that takes them 6 months (or more) to customize and deploy, how will they ever be able to provide you with timely feedback?
  3. Real Mission Critical Systems — The software that monitors and manages the nuclear reactor in a power plant is a good example.  How could any software provider explain away an interim software release that allowed a catastrophe to occur because a feature wasn’t “finished”?    I mean before they lost everything in the inevitable flood of litigation.

There are only a few examples, but they seem to have a few things in common.  Perhaps Agile / Scrum development only works with products / situations without these characteristics:

  • No Timely Feedback — It is not possible to obtain feedback from the customer / end user sufficiently fast enough for the Development team to review and incorporate it into the product.
  • No Ability to Fail — It is not possible for the product to fail, due to a feature that is incomplete, incorrectly designed, or improperly implemented, without subjecting the customer / end user to unacceptably high risks.
  • Not a Standard Product — It it not possible for customers to effectively use a “standard” version of the product.  Every version must be customized before it can be used (or tested) by a customer which makes it very difficult to detect whether a failure is in the product or a customization.

I’m sure I’ve only scratched the surface, so feel free to add your comments.

And next time, we’ll look at a few ideas for using Agile Development practices for products which have one or more of these characteristics…

Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.

Managing Requirements — One Approach That Works

October 3, 2010

I’ve had some recent conversations with colleagues and clients about “managing requirements”.  I was surprised at some of the approaches that had been tried — largely unsuccessfully.

And while I don’t claim to have THE answer on this subject, this approach has one significant advantage — it has worked in the past.

Some Background

I believe that “requirements” consist of many different things, including:

  • Issues reported by customers that highlight a need for better capabilities
  • Problems discovered by internal resources that highlight product gaps
  • Market opportunities that identify broad functional capabilities that could be targeted
  • Customer / prospect discussions that contribute specific product needs.  Often this includes “gaps”.
  • Enhancement requests that explain (sometimes in great detail) specific functions where the product needs to be improved

Thus, there is a wide range of specific and broad “requirements” provided by all sorts of internal and external people — and many of the requirements need to be grouped together — either because they logically go together or because without enough critical mass, none of the smaller items could justify the effort to address them.

Lastly, requirements change over time — either because your understanding of what is needed evolves or because the need itself changes.   (For example, if  a requirement specified that your software should support a dual-core processor and a quad-core processor was introduced before the requirement was addressed — you would probably want to update the requirement.)

Required Tools

I believe strongly in using tools for the function they were designed for.  So, I don’t use a hammer to “drive in” a screw — that’s what a screw driver is for.

Thus, I believe that you need the following tools to manage your requirements:

  • Issue Tracker — a tool for collecting, prioritizing, scheduling, and tracking all sorts of issues, including many of the requirement types discussed previously.  My favorite is JIRA, but there are many others just as good.
  • Document Management System — a tool for collecting, tracking, sharing, and managing all sorts of documents.   My favorite is Alfresco, but there are many others.

You may wonder — Why a Document Management System?   Because some requirements require more than a few paragraphs to adequately describe and as previously discussed — requirements may change.  If these “larger requirements” are captured in one or more documents and linked to the issue within the Issue Tracker — you can update the requirements whenever it is necessary without having to update the issue within the Issue Tracker.

My Approach

Here’s the “short” or “cookbook” version…

System Setup

1.  Create issue types (in the Issue Tracker) for the types of information you need to track.  This could include:

  • Bugs
  • Enhancements
  • Product Improvements
  • Major Features
  • Use Cases
  • Stories (and Epics)  — If you’re using Agile.

2.  Add fields to each issue type so that you can capture planning information.  For example:

  • Dev Estimate — how long it would take to implement this issue (or requirement)
  • Dev Estimate Assumptions — any assumptions that were used to estimate the level of effort.  (This is critical unless you plan to re-estimate each task just before you do it, because situations and people change — and you won’t be able to remember the details of each estimate unless the person who made the estimate keeps notes.  And if they are going to keep notes, why not put them in the system?)
  • Dev Estimate Confidence — how confident is the Development organization in this estimate?  “High, Medium, and Low” are often enough, but you may wish to use a percentage.
  • Reference Doc — a field where you put the link to the reference document (within your Document Management System).   You can also create a separate issue type of “Reference Document” so that you can link multiple documents in your Document Management System to the issue — if you commonly need to refer to multiple documents.

3.  Add “planning” capabilities to your Issue Tracker

You need a method to plan which issues (or “requirements”) will be developed next.  If you are using JIRA and Agile, you could use the GreenHopper planning plug-in.  Or you could add a “Target Release” field and pre-populate it with the names of your next 3-4 release vehicles.

The specific tool is unimportant — as long as it is easy enough for you to use, so that you can (and will) use it regularly.

Using the System

1.  Create documents for anything that can’t be described in a couple of short paragraphs or when the description might change over time.

Use your Document Management System to circulate the documents to appropriate internal (and external) stakeholders — so that each requirement is described appropriately.  You don’t want to waste Development time on poorly defined requirements — so spend the time to get them right.

2.  Create issues for each requirement and establish links to their respective documents.

3.  Create higher level “Major Feature” issues

Group related smaller enhancements and improvements under each Major Feature.  JIRA makes this easy with Links.   Other systems offer similar capabilities.

4.  Create individual issues for each customer request

Each time a customer requests a given feature or enhancement, you should record it as an enhancement issue.  And link each customer enhancement issue to an appropriate Major Feature issue.  Thus, when you are evaluating which features to do — you will have a record of the number of customers who requested something, who they are, when they requested it, etc. — which is incredibly valuable.  Imagine your credibility when you contact your favorite customer to ask them if they would like to test a new feature that they specifically requested… (Of course, they will be happier if you are providing their feature sooner than later — but that’s a different issue.)

5.  Plan each release

Plan each release based upon the content that you want to include, the amount of customer interest, and the roll-up of the estimated development effort.

And since YOU decide how frequently you want to launch new releases, you can use this approach for Agile sprints (3-4 weeks) or for major multi-year waterfall releases.


In summary, all requirements (or issues) get recorded in the Issue Tracker system.  All documents belong in the document management system (such as Alfresco).  Documents are written using standard tools (Word, Excel, Powerpoint, etc).  The Issue Tracker becomes your planning tool and you use the workflow and revision control tools of your document management system to manage the distribution, review, revising, and approval of all relevant documents.

I won’t pretend that this is a perfect system — but it DOES work.  And since these types of tools are already being used within a given company — it is MUCH easier to share information with others in the company and to capture data that already exists. Otherwise, you have to convince people to use “yet another system” and duplicate data between your bug tracking and requirements management system — which is simply too much work, invites multiple (and different) definitions of each issue, and makes it far too easy for things to fall through the cracks.

Next time I’ll discuss the benefits of using a Document Management System (such as Alfresco), instead of a source code control system (such as Subversion), to manage documents.

Thanks for reading this far and now it’s your turn…   How do you manage requirements?  How well (or poorly) does your system work?   Is there anything about my approach that needs improvement or concerns you?

Let’s hear what you think…


Does Agile work when developing commercial enterprise software?

September 11, 2010

I recently had the opportunity to attend an excellent presentation on Agile / Scrum at the Nashua Scrum Club by Damon Poole, Founder and CTO of AccuRev and Vice President of the Boston-area Agile Bazaar.  The presentation was focused on how true agility requires product development professionals to examine our beliefs.  It was a very interesting, entertaining, and thought-provoking presentation and he is a very engaging speaker.  Highly recommended.

However, as I considered some of the key ideas being discussed — such as rapidly deploying product updates to customers and incorporating near immediate feedback from customers into the planning process for the next sprint — I could not help but wonder how effective these concepts would be when developing commercial enterprise software.

Most of the commercial enterprise software I have been involved with suffer from one key problem — it requires a significant amount of customization before the customer is comfortable deploying it across their organization.

As a result, a typical deployment requires each company to (a) install each new software release in a test environment, (b) apply their customizations, (c) test their customized installation to ensure it does what they need, and (d) deploy the new release in production.   In some cases, this process can take as much as 6-12 months.

As a result, companies in this type of situation cannot provide much rapid feedback on the new release — because the “real users” of the system won’t even see each new release for quite a while.   They also can’t rapidly deploy new releases because the out-of-the-box version doesn’t satisfy their business needs.

Commercial enterprise software is one of the most important (and expensive) type of software for many companies.  And Agile offers too many benefits when developing software  to be ignored by enterprise software providers.

So, how can we (as software development professionals) effectively utilize Agile during the development of enterprise software?

Care to share your ideas, experiences, and/or opinions?

Creating Product Features Instead of Feature Elements — a Key Agile Environment Challenge

July 11, 2010

Ever have one of those situations where multiple events all pointed you in the same direction?   Recently this happened to me on the topic of “feature elements versus product features” in an Agile development environment.

First I had a discussion with a potential client, then a friend was lamenting about incomplete features in his company’s latest sprint, and then there was the presentation by David Hussman on this topic at the July meeting of the Agile Bazaar.   So this is what I learned…

One of the fundamental ideas behind the Agile development methodology is that your development process is divided into small cycles or sprints.  The idea is that each sprint is sufficiently well-defined to allow it to be delivered to your customers.  And then your next sprint could focus on refining previously completed or new capabilities — depending on what the market (and your customers) need.  In this way, your product is theoretically ready to go to market at the conclusion of any sprint, so you don’t have to wait until all of your “planned development” for a given release has been completed (and tested).

However, this approach doesn’t accommodate situations where your product must include a certain set of related features (we’ll call them “feature elements”)  which cannot be completed in a single sprint and which your product really must include.

For example, assume that you are creating a word processing application which will allow users to create, save, edit, format and print documents in a variety of ways.

Your product MUST have the ability to “create a new document”.  Likewise, without the ability to “save” your changes and then “load” or “open” a previously saved document — the value of your product will be minimal.   This is why, most applications that deal with “objects” provide feature elements for performing “CRUD” (Create, Read, Update, Delete) operations.

Yet, some of these feature elements are much more challenging to implement and thus take longer to complete — often requiring multiple sprints — which is at odds with the Agile concept of being able to deliver the results of any sprint to your customers.

A modified Agile approach known as Kanban appears to resolve this conflict, because the focus is on delivering complete product features and not just feature elements.  In essence, a sprint is not suitable for delivery to customers unless all of the key elements of a product feature are completed.   Thus, to return to our word processor example, you might implement “Create”, “Save”, and “Open” in different sprints, but your product would not be distributed to potential customers until all of these product feature elements had been completed.

This development approach seems nearly ideal to me — but few companies seem to be using it and some strong Agile proponents seem extremely reluctant to embrace it.

So what do you think?   Is Kanban simply too new for many people to have tried it?  Or is it better in theory than in practice? Or is it simply not “Agile enough” for you to consider?

Do you have any experience with Kanban or know of any companies that have used it?  If so, what did you (or they) learn?

How productive is your software development process?

April 23, 2010

Do you wonder how productive your software development process is?

Do you wonder whether an Agile or Extreme Programming approach would increase your development productivity?

Are you worried that your job will be outsourced because your company wants to increase your development productivity?

Wouldn’t it be wonderful if you could actually know the answer to these questions, instead of having to guess or rely on opinions, theories, or experimentation?

I recently had an opportunity to attend a Nashua (NH) Scrum Club meeting where Michael Mah from QSM Associates ( gave a presentation on tools and techniques that his company uses to accurately measure the productivity of a software development process AND to compare the productivity of a project to the industry average for similar projects being done by similar teams.  It seemed almost like magic.

First a bit of background…

I have always thought that any software project consisted of 4 key characteristics or dimensions:

  • People — The number of people who are involved in the project.  This includes everyone who contributes to the development, testing, building, integration, and management of the project.
  • Content — The number of  features that will be included in the project.
  • Schedule — The schedule, or completion date, for the project.
  • Quality — The level of quality that must be attained by this project.

And while you may wish to optimize all of these dimensions for your project, the relationship between them is absolute.  So if you optimize one dimension, another dimension (or two) must be changed to compensate.

We have all seen this in practice.  As an example, consider that recent project where it was on schedule, until a key customer insisted that you add “just a few more critical features”.   For some strange reason, the project then finished later than planned.   And people were surprised.   Wow !!

Now, let’s look at the magic that QSM can do with the same information…

It turns out that QSM refers to these 4 dimensions using slightly different terms, as follows:

  • Effort — The number of people who are working on the project.
  • Produced Software Size — The number of “stories” for which software was produced, or the content of the project.
  • Duration — The duration of the project.
  • Discovered Defects — The number of defects discovered during FQA (Final Quality Assurance), or the quality of the code that was produced.

However you can still accurately determine values for these 4 dimensions and use them to calculate the productivity of a software project.    So when this information is entered into QSM’s software tool, it generates a series of graphs that compare the productivity of your project to other projects with a similar dimensions.   (Please see QSM’s web site for more information.)

This allows you to accurately and reliably analyze the productivity of your project AND to compare it to other similar projects.  So you can also predict, as an example , whether it is (or is not) a good idea to move some (or all) of your development team off-shore.

And in today’s environment, where your products need every possible competitive advantage, wouldn’t you prefer to find out this type of information without experimenting?

%d bloggers like this: