Project Management

Disciplined Agile

by , , , , , ,
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Hybrid | Improvement | inception | Inception phase | Kanban | Large Teams | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | Workflow | show all posts

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Failure Bow: Choosing Between Life Cycles Flowchart Update

Evolving Disciplined Agile: Guidelines of the DA Mindset

Evolving Disciplined Agile: Promises of the DA Mindset

Evolving Disciplined Agile: Principles of the DA Mindset

Evolving Disciplined Agile: The DA Mindset

Apply Consistent Metrics Categories Across an Agile Portfolio

Metrics A common question that we get from customers who are new to Disciplined Agile (DA) is how do you roll up metrics from solution delivery teams into a portfolio dashboard?  A more interesting question is how do you do this when the teams are working in different ways?  Remember, DA teams choose their way of working (WoW) because Context Counts and Choice is Good.  Even more interesting is the question “How do you roll up team metrics when you still have some traditional teams as well as some agile/lean teams?”  In this blog we answer these questions one at a time, in order.

Note: We’re going to talk in terms of a single portfolio in this article, but the strategies we describe can apply at the program (a large team of teams) too, and then the program-level metrics are further rolled up to higher levels.

 

How Do You Roll Up Agile Team Metrics Into a Portfolio Dashboard?

Pretty much the same way you roll up metrics from traditional teams.  There tends to be several potential challenges to doing this, challenges which non-agile teams also face:

  1. You can only roll-up metrics with similar units. You do need to be careful with some measures, such as team velocity, because the units vary across teams.  It is possible to enforce a common way to measure velocity across teams, but this tends to be more effort than it’s worth in practice. Sometimes there are metrics which you think you should be able to roll up but you discover (hopefully) that you really shouldn’t.  One example of this is number of defects by severity.  You can roll this metric up when the severity of a defect is determined in a consistent manner across teams, but this isn’t always the case in practice.
  2. Sometimes the math gets a bit complex.  Rolling up metrics isn’t always based on simple addition.  Many times you will need to weight metrics based in terms of time, size, financial impact or combinations thereof.  Interestingly, although some metrics can’t be rolled up because they are measured in different units, you can often roll up the trends of those metrics.  For example, acceleration is the change in velocity of a team.  Given an appropriate weighting formula you can roll up an average acceleration figure across teams.
  3. Some people believe you can only roll up the same metric. Basically, when a common metric is captured across teams (for example Net Promoter Score (NPS) or cyclomatic complexity) then you can easily (albeit with some “complex” math in some cases) roll them up to a program or portfolio level.  In the Govern Delivery Team process goal we refer to this strategy as consistent metrics, an option of the Provide Transparency decision point. This strategy works well when teams actually collect the same metrics, but in when teams choose their WoW this isn’t always the case.

 

How Do You Roll Up Agile Team Metrics Into a Portfolio Dashboard When the Teams Choose Their WoW, and it’s Different For Each Team?

When a team is allowed to choose it’s way of working (WoW), or “own their own process,” the team will often choose to measure itself in a manner that is appropriate to it’s WoW. This makes a lot of sense because to improve your WoW you will want to experiment with techniques, measure their effectiveness for your team within your current context, and then adopt the techniques that work best for you.  So teams will need to have metrics in place that provide them with insight into how well they are working, and because each team is unique the set of metrics they collect will vary by team.  For example, in Figure 1 below we see that the Data Warehouse (DW) team has decided to collect a different sent of metrics to measure stakeholder satisfaction than the Mobile Development team.  The DW team needs to determine which reports are being run by their end users, and more importantly they need to identify new reports that provide valuable information to end users – this is why they have measures for Reports run (to measure usage) and NPS (to measure satisfaction).  The Mobile team on the other hand needs to attract and retain users, so they measure things like session length and time in app to determine usage, and user retention and NPS to measure satisfaction.

Figure 1. Applying consistent metrics categories across disparate teams (click on it for a larger version).

Agile metrics categories

Furthermore, the nature of the problem that a team faces will also motivate them to choose metrics that are appropriate for them. In Figure 1 we see that each team has a different set of quality metrics: the DW team measures data quality, the mobile team measures code quality, and the package implementation team measures user acceptance test (UAT) results. Although production incidents and automated test coverage are measured by all three teams, the remaining metrics are unique.

The point is that instead of following the consistent metrics practice across teams by insisting that each team collects the same collection of metrics, it is better to ask for consistent metric categories across teams. So instead of saying “thou shalt collect metrics X, Y, and Z” we instead say “Thou shalt collect metrics that explore Category A, Category B, and Category C.” So, as you can see in Figure 1, each team is asked to collect quality metrics, time to market metrics, and stakeholder satisfaction metrics but it is left up to them what metrics they will choose to collect. The important point is that they need to collect sufficient metrics in each category to provide insight into how well the team addresses it. This enables the teams to be flexible in their approach and collect metrics that are meaningful for them, while providing the governance people within our organization the information that they need to guide the teams effectively.

So how do you roll up the metrics when they’re not consistent across teams?  Each team is responsible for taking the metrics that they collect in each category and calculating a score for that category.  It is likely that a team will need to work with the governance body to develop this calculation.  For example, in Figure 2 we see that the each team has a unique dashboard for their team metrics, yet at the portfolio level the metrics are rolled up into a stoplight status scorecard strategy for each category (Green = Good, Yellow = Questionable, Red = Problem). Calculating a stoplight value is one approach, you could get more sophisticated and calculate a numerical score if you like.  This is something the governance body would need to decide upon and then work with teams to implement.

Figure 2. Rolling up metrics categories (click on it for a larger version).

Agile metrics - portfolio dashboard

 

From the looks of the Portfolio dashboard in Figure 2 there is a heat map indicating the overall status of the team (using green, yellow, and red again) and the size of the effort (indicated by the size of the circle). Anyone looking at the portfolio dashboard should be able to click on one of the circles or team stoplights and be taken to the dashboard for that specific team. The status value for the heatmap would be calculated consistently for each team based on the category statuses for that team – this is a calculation that the governance body would need to develop and then implement.  The size of the effort would likely come from a financial reporting system or perhaps your people management systems.

 

How Do You Roll Up Team Metrics When Some Teams Are Still Traditional?

With a consistent categories approach it doesn’t really matter what paradigm the team is following.  You simply allow them to collect whatever metrics are appropriate for their situation within each category and require them to develop the calculation to roll the metrics up accordingly.  If they can’t come up with a reasonable calculation then the worst case would be for the Team Lead (or Project Manager in the case of a traditional team) to manually indicate/enter the status value for each category.

 

Parting Thoughts

For the consistent categories strategy to work the governance people need to be able to look at the dashboard for a team, which will have a unique collection of widgets on it, and be able to understand what the dashboard indicates. This will require some knowledge and sophistication from our governance people, which isn’t unreasonable to ask for in our opinion. Effective leaders know that metrics only provide insight but that they shouldn’t manage by the numbers. Instead they should follow the lean concept of “gemba” and go see what is happening in the team, collaborating with them to help the team understand and overcome any challenges they may face.

 

Related Links

Posted by Scott Ambler on: September 04, 2018 12:19 PM | Permalink | Comments (0)

Strategies for Tracking Time on Agile Teams

Time Tracking

In Time Tracking and Agile Software Development we overviewed why teams should consider tracking their time.  Primary reasons include:

  • You’re billing your customer by the hour
  • Your organization wants to account for CapEx/OpEx
  • Your organization wants to take advantage of tax credits (typically for R&D work)

A secondary reason to track time is because the team wants to measure where they are spending time so as to target potential areas to improve.  This is more of a side benefit than anything else – if this was your only reason to track time you’d be better off simply discussing these sorts of issues in your retrospectives.  But if you were already tracking time then running a quick report to provide the team with intel likely makes sense for you.

So what are your options for recording time?  Potential strategies, which are compared in the following table, include:

  1. Automated report from an agile management tool. The basic idea is to extract data from an agile management tool (JIRA, TFS, LeanKit, …) and load it into your time tracking system.
  2. Manual input by team members. Each team member, typically once a week, inputs their time into the time tracking tool.
  3. Manual input by the Team Lead. The Team Lead (ScrumMaster) inputs the time for their team into the time tracking tool.
  4. Manual input by a Project Manager/Coordinator. A PM or Project Coordinator, often in a support role to the team, inputs the time of team.
  5. Don’t track time at all. ‘Nuff said.

Table: Comparing options for tracking time.

Strategy Advantages Disadvantages
Automated report from agile management tool
  • Very efficient because it doesn’t require ongoing data input
  • Sufficient for CapEx/OpEx purposes
  • Sufficient for customer billing when the billing units are by the day (or greater)
  • Requires a bit of development work to feed data from your agile management tool into your time tracking system
  • May motivate the team to start treating the agile management tool like a time tracking tool (which often negates the value of the management tool)
  • Often requires a bit of (programmatic) fudging of the data to calculate the time not captured in the tool (such as coordination meetings, demos, retrospectives, …)
  • May require a bit of negotiation with your organization’s auditors (if any)
  • Only an option for teams using agile management tools
  • Works well for teams that are working in a fairly consistent manner (i.e. mature teams that have gelled)
Manual input by team members
  • Potentially the most accurate approach
  • Sufficient for CapEx/OpEx, tax credits, and customer billing
  • Team members often perceive this as an overhead
  • People will be motivated to input what they believe management wants, particularly if any sort of rewards or punishments are thought to be connected
  • Potential for significant expense across the organization (a few minutes per person per week starts to add up) if this gets too detailed or complicated
  • For people working on multiple teams (a question idea anyway) time tracking often becomes onerous
Manual input by Team Lead
  • Shifts the data input burden away from the team
  • Sufficient for CapEx/OpEx and tax credits
  • Likely sufficient for customer billing
  • Not as accurate as other strategies
  • Takes the Team Lead away from leadership tasks
  • Requires the Team Lead to know what is going on within the team (which frankly should be a given)
Manual input by Project Manager/Coordinator
  • Same as manual input by Team Lead
  • Not as accurate as other strategies
  • Likely requires the PM to interview/badger team members to find out what they did during the week
  • Little better than “make work” for the PM
Don’t track time at all
  • No overhead for the team
  • Your organization may be losing out on tax credits

This blog posting was motivated by a conversation that I had with Stacey Vetzal on Twitter.

Related Reading

Posted by Scott Ambler on: May 29, 2017 06:57 AM | Permalink | Comments (0)

Stable Teams Over Project Teams

One of the interesting trends that we’re seeing within organizations taking a disciplined agile approach to solution delivery is the preference for stable teams. Stable teams, also called stable product teams or simply long-term teams, are exactly as they sound – they remain (reasonably) stable over time, lasting longer than the life of a single project. This blog explores the differences between project teams and stable teams and then overviews the advantages and disadvantages of the stable team approach.  We also explore the issue of how stable teams evolve over time.

Stable Teams

As you can see in the following diagram, with a project team approach we say that we bring the team to the work. What we mean by that is that we first identify the need to run a project, perhaps to build the new release of an existing solution or to build the initial release of a new solution, we build a team to do the work.   Once the work is done, in this case the solution is successfully released into production, the team is disbanded and its team members move on to other things.

Stable teams vs project teams

The stable team approach is a bit different. In this case we first build an effective team then we continuously bring valuable work to the team to accomplish. In this situation the work never really ends, but instead we replenish the team’s work item list (or work item pool depending on the lifecycle being followed) regularly. The team stays together and continues to produce value for your organization over time.

Of course the term “stable team” is a bit of a misnomer as they do evolve over time. For example, many people like to stay on a team for a couple of years and then move on to another team to gain new skills and perspectives. This is good for them and good for your organization as it helps to keep your teams fresh. Sometimes you will want to grow or shrink a team. Sometimes you will discover that two people aren’t working well together and you need to split them up. The point is that there are very good reasons for your stable teams to evolve over time.

We wouldn’t be disciplined if we didn’t explore the trade-offs involved with stable teams.

The Advantages of Stable Teams

There are several advantages to stable teams:

  1. Lower management overhead. There is clearly less “resource management” to be done because you’re not constantly forming and disbanding project teams. In fact, this lower need for resource management activities is one of several factors why agile IT organizations need managers than non-agile IT organizations.
  2. Easier team budgeting. The annual budget for a stable team is incredibly straightforward to calculate: Multiply the number of people on the team by the fully burdened cost of an IT person for your organization. Once again, less management work required for this.
  3. You build better teams. When you build project teams you tend to take the people who are currently available (often referred to as sitting on the bench). With a stable team approach you’re motivated to build your teams with the right people, and very often its best for the team to build itself by inviting others who they believe will fit in well.
  4. There is greater opportunities to build trust within the team.  It takes time to build trust within a team.  Greater trust leads to greater willingness to work together in a more streamlined manner.  As Stephen Covey insightfully points out, trust enables speed.
  5. There’s a greater opportunity for safety.  It takes time to build an environment where people feel safe. In safe environments there is a much greater chance that they will share ideas and be willing to try new things because they don’t fear being thought less of or even punished.
  6. There is less overhead from team formation. You’re forming teams far less often with a stable approach compared to a project team approach, hence there is less overhead in total for your organization.
  7. Better team performance.  Consider the analogy of a train.  Just like it takes time to bring the train up to cruising speed it takes time for the team to jell.  Bringing work to a seasoned team that works together well is like jumping onto a train going at full speed: it’s faster in both cases because you don’t have to get going from a full stop.
  8. You have more efficient utilization of staff. With this approach it is far less likely that someone will be “sitting on the bench” because they will instead be an active member of a team. When someone is hired it is directly into a team. Throughout their career they will move from team to team as appropriate. The only time that they might not be utilized is when their on vacation, sabbatical, or if you purposefully disband a team. The first two reasons are something you still have with the project team approach, and the last reason should happen a lot less often.
  9. Your teams are more likely to improve. When a team knows that they will be working together for a long time, and particularly when they are responsible for the entire delivery lifecycle from beginning to end, they are more likely to streamline their work so as to make things better for themselves.

 

The Disadvantages of Stable Teams

There are several disadvantages to stable teams:

  1. Teams can become too stable. A real danger of stable teams is the potential for groupthink – everyone on the team starts to think and work in a common way, thereby being in danger to common blindspots. Luckily people still want to move to other teams for career management reasons, offering the opportunity to bring new viewpoints into other teams. In the Disciplined Agile (DA) toolkit we have the continuous improvement process blade which supports sharing of ideas across teams so that can also lessen the chance of groupthink. And, as mentioned earlier, some people may need to be motivated to move on to another team for interpersonal reasons.
  2. You still may need to do projects. Sometimes your business team makes promises to their customers. For example, in a software company a sales person makes a big sale and promises that by a certain date your solution will have additional features that the customer needs (in immature organizations they’ll even make such promises without first negotiating this with the delivery team). Another example would be a financial institution that needs to fulfill new industry regulations that require changes to existing solutions. In both of these cases there is a large amount of work to be done that needs to be delivered before a certain date, and this may motivate you to treat this work as a project. You would still bring this work to the appropriate stable team(s) to accomplish as you normally would. However, you would also track the performance of the work to ensure that it is delivered in its entirety as appropriate. The implication is that projects may not completely go away

 

Evolving Stable Teams Over Time

Stable doesn’t mean stagnant.  Of course you still have basic people management issues such as people wanting to expand their skill set by working on something new by rotating to another team, people leaving the organization, and new people joining the organization.  So the team itself may go on for many years even though the membership of the team evolves over time.  Ideally these membership changes are not too disruptive: It’s not too bad adding a new person every month or so, or losing people at a similar rate, but gaining or losing several people in a short period of time can be painful.

 

Our Recommendation

Start experimenting with stable teams if you’re not already doing so. For most organizations the advantages clearly outweigh the disadvantages. In fact, you can see this in the Longevity decision point of the Form Initial Team goal diagram below.

Form Initial Team Process Goal

Posted by Scott Ambler on: November 13, 2016 09:24 AM | Permalink | Comments (0)

Rolling Wave Planning in Disciplined Agile

Wave

The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

Rolling wave planning is implemented in several places of the DA toolkit. First, as you can see in Figure 1 below, it is an option of the Level of Detail decision point of the Develop Initial Release Plan process goal. A rolling wave approach to release planning has the advantages of more accurate and flexible planning although can be a bit disconcerting to traditional managers who are used to annual planning strategies.

Figure 1. The Develop Initial Release Plan goal diagram.

Develop Initial Release Plan

 

The Portfolio Management process blade supports rolling wave budgeting as an option for its Manage the Budget decision point. This is depicted in Figure 2. The advantages are greater flexibility and greater likelihood of investing your IT funding more effectively, albeit at the loss of the false predictability provided by an annual budgeting strategy.

Figure 2. The goal diagram for the Portfolio Management process blade.

Disciplined Agile Portfolio Management

 

The Program Management process blade supports rolling wave planning of a program itself, as you seen in Figure 3. Planning and coordination are critical on a large program, and rolling wave planning offers the advantages greater flexibility, the ability to think important cross-team issues through, and the ability to react to changing stakeholder needs. The primary disadvantage is that it can be disconcerting for traditionalists who are used to thinking every thing through from the beginning.

Figure 3. The goal diagram for the Program Management process blade.

Disciplined Agile Program Management

 

As you can see in Figure 4, rolling wave strategies can be applied in Product Management to evolve the business vision/roadmap. A continuous, rolling wave approach is critical to your success because the market place changes so quickly – these days, few organizations can tolerate an annual approach to business planning and in the case of companies with external customers an ad-hoc approach can prove to be too unpredictable for them.

Figure 4. The goal diagram for the Product Management process blade.

Product Management Goal Diagram

 

Previously we saw that rolling wave strategies can be applied to evolve your technology roadmap, as indicated in the goal diagram for Enterprise Architecture in Figure 5. The advantages of this approach are that your roadmap evolved in sync with both changes in technology and with your organization’s rate of experimentation and learning. The main disadvantage is that your technology roadmap is effectively a moving target.

Figure 5. The goal diagram for the Enterprise Architecture process blade.

Disciplined Agile Enterprise Architecture

As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) toolkit. In fact, in most situations they prove to be the most effective and flexible strategies available to you. The advantages of rolling wave planning tend to greatly outweigh the disadvantages. More on this next time.

Posted by Scott Ambler on: October 25, 2016 11:39 AM | Permalink | Comments (0)

Rolling Wave Release Planning for Agile Delivery Teams

Wave

The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.

In Figure 1 you see how a Disciplined Agile Delivery (DAD) team takes a rolling wave approach to release planning. This is a stable team that releases their product into production twice a year. The team has been in place for almost three years and as a result they no longer need to go through an Inception phase. The Construction phase is typically scheduled for twelve iterations. Their Transition phase still takes one week. Although they’ve automated their test and deployment scripts a long time ago they still need time for internationalization – in this case they need to finalize and acceptance test any translated work.

Figure 1. Rolling wave release planning on a solution delivery team.

Rolling wave release planning overview

 

Figure 2 overviews the level of detail that the team currently has captured in their requirements artifacts and in effect how they would show up in any sort of team work plan. The team is currently in the first construction iteration for the current release, implementing 5 user stories. There are thirteen additional user stories that have been explored in detail by the product owner which at the team’s current velocity is about one month of work. There are an additional thirty user stories identified but not yet explored, and several epics. In the middle of this current iteration the product owner is likely to run one or more look-ahead planning/modeling sessions (called backlog grooming or backlog refinement in Scrum). The goal of this effort will be to detail a few of the near term (yellow) stories to pull them into the very near term (green) category and maybe to even start breaking down an epic or two into more details stories. This effectively pulls work along in the plan. The team’s iteration/sprint planning session at the beginning of each iteration pulls work into the team at that point.

Figure 2. Solution release planning at construction iteration #1.

Rolling wave release planning iteration 1

An interesting implication of this approach is at the beginning of the iteration it isn’t clear exactly what the team will deliver. As you can see in Figure 2 only about one-and-a-half months of work has been explored in detail (eighteen stories in total), an additional two months of work (thirty stories) has been identified at a high level and the rest at a very high level. In addition, the stakeholder’s priorities could shift and different stories and epics could be prioritized higher in the team’s work item stack (backlog) later on in construction.

Now let’s work through what things look like at the beginning of iteration #8.   As you can see in Figure 3 the team is currently working on six stories and has eleven more that have been detailed out for the next month or so. There are thirty-two stories identified for the near term (yellow) category. Interestingly, Construction ends in about two months (remember, the releases are six months long with this team). At this point in time it’s fairly clear what the team will deliver, albeit with some room for change given that there is still to months of construction left.

Figure 3. Solution release planning at construction iteration #8.

Rolling wave release planning iteration 8

 

What Should the Planning Horizon Be?

In this example the planning horizon is fairly long because the team’s release cycle is fairly long at six months.   They chose to maintain about three months of details and kept everything else at a high level and that worked for them. We recently worked with a team at an e-commerce firm following the continuous delivery lifecycle where the distant future (grey) was anything more than two months away. As a result they had detailed requirements for the next two to three weeks (green), about the same number of stories that hadn’t been worked through yet for near term work (yellow), and then a collection of epics after that. The point is that you need to set your planning horizons according to the situation that you face. Context counts.

 

Capturing a Release Plan

A deliver team can choose to capture their release plan in several different ways, and could even combine strategies for doing so. Their options include:

  1. Maintain the plan manually. Many teams will capture their requirements manually, using paper to capture the stories, acceptance criteria, and any supporting artifacts. For the current iteration the team manages their work on a whiteboard with sticky notes or corkboard with index cards. Future work is often tacked onto a corkboard or maintained in file folders or similar containers. The advantages of this approach are that the plan is easy to evolve and work with (you’re moving paper around). The disadvantages are that reporting also becomes manual (perhaps you’re asked to estimate your expected delivery date or cost using burn up or burn down charts), it doesn’t easily support geographic distribution, and that this strategy may be anathema to your governance people if they’re not experienced yet with agile development.
  2. Use an agile management tool. Many teams choose to use agile management tools such as Atlassian Jira, VersionOne, Microsoft TFS, or Rally to name a few. These tools have the advantage that they support geographically distributed teams, they often also address any plan documentation needs for teams working in regulatory situations, they are often less threatening to your governance people, and they can even be integrated into any corporate reporting technologies your company has in place (such as Microsoft Project Server for example). The disadvantages are that they are often harder to use than manual strategies (regardless of the vendors’ marketing claims), agile management tools can still be threatening to traditional-leaning governance people because of they support a more agile way of working, and of course the need to pay for and learn them.
  3. Create a Gantt chart. Your rolling wave plan can also be captured using Gantt charts (yes, Gantt charts can be used in an agile manner if you choose). The article Agile Project Planning Tips works through how a Gantt chart evolves with a rolling wave planning approach. The advantages are that Gantt charts are a familiar way to communicate your schedule to others and that your existing management tools likely support them already. The disadvantages are that Gantt charts can still be a bit clunky from an agile point of view and that many project management tools make it too easy to capture details that often prove to be of little value in practice.

A potential point of confusion is what to call this sort of plan. Up until now we’ve been using the term release plan. However, as you can see in both Figure 2 and Figure 3 the plan extends to more than a single release of this product. This is really a “multiple-release plan” or better known as a product plan (not to be mistaken with a product roadmap, something that your product management efforts will often produce). More on this in the next blog posting in this series.

Posted by Scott Ambler on: October 18, 2016 10:27 AM | Permalink | Comments (0)
ADVERTISEMENTS

"Impartial observers from other planets would consider ours an utterly bizarre enclave if it were populated by birds, defined as flying animals, that nevertheless rarely or never actually flew. They would also be perplexed if they encountered in our seas, lakes, rivers and ponds, creatures defined as swimmers that never did any swimming. But they would be even more surprised to encounter a species defined as a thinking animal if, in fact, the creature very rarely indulged in actual thinking."

- Steve Allen

ADVERTISEMENT

Sponsors