Re: agile and product roadmaps
- --- In email@example.com, Ron Jeffries
> On Tuesday, November 1, 2005, at 6:07:13 PM, March, Steven wrote:
> > Thanks to those who responded to my question on agile and product
> > roadmaps.
> > It seems, summarizing the responses, that the general sense is
> > you become an agile shop you stop making long-term promises infavor of
> > making near-term promises while holding long-term intentions thatyou
> > don't take too seriously because they will inevitably need tochange.
>You're assuming that everything that the agile team commits to is a
> I don't think of it this way. An Agile team might not make terribly
> specific long-term promises, for these reasons:
> We expect that the value of each of the features promised is not
> well known.
> We expect that the value in the future of those features will not
> be the same as it is now.
> We expect that new feature ideas will emerge which are more
> valuable than many of the currently-contemplated features.
> We expect that some of the currently-contemplated features will
> turn out to be of little or no value at all.
> We do not -- and cannot -- know the specific cost of each feature.
> So Agile teams do not commit to these things. Agile or not, any team
> that /does/ commit to specific features over the long term is
> dealing with the same uncertainties. The inevitable result is that
> projects take longer than expected and deliver features that no one
> really wants, while missing out features that would be really good
> but weren't in the original list.
> An Agile team can and will commit, however, to something far more
> valuable than a specific list of features imagined up front. The
> Agile team will commit to deliver, on specified dates during the
> entire lifetime of the project, the customer's own selection of
> features, based on the customer's estimate of value and the team's
> estimate of cost.
feature. In some cases, that isn't true. For example, a team might
commit to supporting a product on a particular platform for a
particular period of time. Or of migrating the code over time to
support a particular set of databases. Customers may make other
decisions about what software and hardware they install, based on the
longterm support roadmap that a vendor lays out.
- If I understand it correctly, customers don't often know what they want right from the start. What the system should look like evolves over time NO MATTER WHAT methodology you use (waterfall or agile).Also, the most needed requirements and capabilities are implemented first in Agile methods. So, the customer is assured of a certain level of functionality and usually far more quickly than in waterfall methods.Finally, who said customers want to make long term commitments? Wasn't it the software community that demanded tight requirements and developed all the controls for managing requirements creep?
"March, Steven" <steve.march@...> wrote:Hello,Thanks to those who responded to my question on agile and product roadmaps.It seems, summarizing the responses, that the general sense is that when you become an agile shop you stop making long-term promises in favor of making near-term promises while holding long-term intentions that you don't take too seriously because they will inevitably need to change.So I get this and think there is a lot of pragmatic wisdom in holding long-term plans this way. However, from the customer's perspective that doesn't give them much that they can count on. It leaves our customers in uncertainty and not knowing if they can trust us to fulfill their needs or not as a supplier. Why would a customer want to establish a long-term relationship with a supplier if the supplier is only willing to make near-term commitments.It seems to me that when faced with uncertainty we have at least two responses: 1) drift into the future or 2) commit to creating a certain future. The first option doesn't allow our customers to coordinate effectively with us. With the later option, responding to uncertainty with a commitment, enables customers to coordinate with us (even in the cases where we have to revoke our commitments and make new ones). Naturally, having to revoke commitments will impact our customer's trust in us if we don't revoke our commitments with care and responsibility for the impact we have on them. With the former option, responding to uncertainty with drifting, there is no possibility to coordinate effectively in the long-term and to build trust.I don't see anything inherently incompatible between the practice of product roadmaps (longer-term commitments) and agile ... IF ... we can responsibly revoke commitments and re-commit when we have to. However, I see a few business drawbacks by not making longer-term commitments.I'm wondering what you all think of that and how you see this. Thanks for the conversation.Take care,-SteveI think it is important (in most environments) to have some level of long-range plan and goals. To see why, imagine you are hiking and want to cross a particular summit. You look up the trail and aim for the highest thing you see (that must be the summit, you reason). However, once you reach that point you realize it was a false summit and that it obscured the real summit, which you know head for only to realize it too was a false summit. Never looking further ahead than the current sprint is like this. It is possible to have a series of successful sprints that do not necessarily lead to the most satisfying overall 6-month release.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Mike Cohn
Sent: Tuesday, October 25, 2005 12:34 PM
Subject: Re: [scrumdevelopment] agile and product roadmaps
Another example since were winding down baseball season: A team doesnt decide who is the one best batter we can send to the plate next? They put a bit of forethought into that and sort players based on a variety of factors (e.g., you wouldnt want your best base-stealer to follow your slowest guy who almost always gets on base).
Planning ahead is critical to reliably achieving long-term project success.
You dont, however, want to take the plans too seriously. They are point-in-time guesses and should be updated after each sprint based on new knowledge.
As I saw in another post, I describe this via a planning onion. Innermost in the onion is the daily plan (made in the daily scrum), outside that is the sprint plan, outside that is the release plan. Continuing to the outside are the product plan (a perhaps 1-2 view of the life of this product), followed by portfolio planning (which products fit with what we know and do and whom we market to), followed by company strategy. Its possible to have a few more layers in this onion in some companies (e.g., product platform strategy in some cases). Each of these layers of the onion needs deliberate thought and planning and each looks forward to a differing degree. Not all are the specific concern of a dev team but hopefully someone is thinking about these outer layers. The key is to have an agile mindset when doing sofor example, realize that any 18-month plan is going to change.
Agile Estimating and Planning
User Stories Applied for Agile Software Development
On 10/25/05 9:38 AM, "March, Steven" <steve.march@...> wrote:
My organization has a practice of publishing 18 month product roadmaps of releases with promised features. We are not an agile shop today but are considering moving in this direction.
How do organizations that practice agile do this?
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
YAHOO! GROUPS LINKS
- Visit your group "scrumdevelopment <http://groups.yahoo.com/group/scrumdevelopment> " on the web.
- To unsubscribe from this group, send an email to:
- firstname.lastname@example.org <mailto:email@example.com?subject=Unsubscribe>
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
V/R,JoeyWould you rather have a nice life or interesting stories?
Yahoo! FareChase - Search multiple travel sites in one click.
> "March, Steven" <steve.march@w...> wrote:You can make commitments with agile. What you cannot do is predict
> I don't see anything inherently incompatible between the practice of
>product roadmaps (longer-term commitments) and agile ... IF ... we can
>responsibly revoke commitments and re-commit when we have to. However,
>I see a few business drawbacks by not making longer-term commitments.
the future. Predicting the future is what we try to do when we
promise to deliver on an exact date a product with all the requested
features with high quality within a set budget.
Agile can do what any other project management methodology can do in
terms of commitment. The difference with Agile is that you have the
opportunity to see real progress (or lack thereof) more immediately so
that you can adjust the plan. Also, with Agile, you have the
opportunity to deliver the most valuable features regardless of what
the original plan was. Other methodologies that are concerned with
"hitting the plan" and enforcing "change management" aren't driven by
delivering value, their focus is on sticking to a plan, no matter how
acurate that plan turns out to be.
If people focus on delivering the most value within a set deadline I
think it would help get everyone closer to the solution that is
>From: jhoover6672000 <jhoover6672000@...>And it is worth pointing out to the PO and other stakeholder that other, non-agile methodologies can NOT do this either. These methodologies pretend to have this ability, veiled in ceremony and SOPs - but it is an illusion, a big lie.
>You can make commitments with agile. What you cannot do is predict
>the future. Predicting the future is what we try to do when we
>promise to deliver on an exact date a product with all the requested
>features with high quality within a set budget.
- Joseph Snively wrote:
>When you buy software you are often making a long term commitment. The
> Finally, who said customers want to make long term commitments?
cost of moving OSes for example can be massive to nearly impossible.
For example, if we use Wind River for our embedded system that is
deployed on 1000s of devices out in the real world we have made a long
term commitment. So have they.
Let's say we want to make use of a new processor, we want to know when
they will support it and we want to see it on their roadmap. A roadmap
is usually by quarters so it's not that small a target. We will make all
our schedules dependent on that data. If they don't hit then the
consequences are dire. We don't want to hear anything like we think we
don't know when we'll implement that feature because we use methodology X.
- On Wednesday, November 2, 2005, at 3:13:50 PM, jhoover6672000 wrote:
>> "March, Steven" <steve.march@w...> wrote:I can predict the future. Just not quite that well. But neither can
>> I don't see anything inherently incompatible between the practice of
>>product roadmaps (longer-term commitments) and agile ... IF ... we can
>>responsibly revoke commitments and re-commit when we have to. However,
>>I see a few business drawbacks by not making longer-term commitments.
> You can make commitments with agile. What you cannot do is predict
> the future. Predicting the future is what we try to do when we
> promise to deliver on an exact date a product with all the requested
> features with high quality within a set budget.
any other process predict the future that well.
Do only what is necessary. Keep only what you need.