Category Archives: Project Management

Update: Secure Funding Goal Diagram

Update

We recently updated the Secure Funding goal diagram, shown below.  The change was the addition of the Choose Funding Scope decision point, to recognize that the type of team you’re funding will affect how you fund said team.  We have also published details about each decision point and its associated options, including the tradeoffs of each, at the Secure Funding overview page.  This is information that we previously had only published in the first Disciplined Agile Delivery book but we’ve decided to start publishing updated versions of this information to the web to make it more accessible to you.

Secure Funding

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) framework 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 the Initial Team

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 framework. 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.

Disciplined Agile Product Management

 

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) framework. 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.

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.

Introduction to Rolling Wave Planning

Rolling wave

For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) framework, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few.  This blog overviews this important practice.

The basic idea 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 below you see an overview of how rolling wave planning works and in Figure 2 an example of how a Disciplined Agile Delivery (DAD) team applies it for release planning. Upcoming work is planned in detail, the planning unit “X” is one month in the case of the delivery team. In order to do their work they need detailed user stories and supporting artifacts such as acceptance criteria and supporting models such as user interface (UI) sketches or data source analysis. They have this information for the work that they are doing right now as well as about one month’s of upcoming work. They don’t yet need details for work that is several months away in time. In this case for work that is two to three months in the future they only have user stories developed and work that is four to six months away epics. Work in what the team considers to be the distant future, in this case six or more months away, is described in very high-level terms such as epics or solution capabilities.

Figure 1. Rolling wave planning overview.

Rolling wave planning overview

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

Rolling wave release planning overview

Part of the work that the team is doing right now is to keep their plan up to date. For example, if they are working in two week iterations they will pull two weeks of work into the team. During the current iteration they will pull about two weeks of user stories from the near term category (the yellow box in Figure 2) into the very near term (the green box). They may also bring upcoming work into the near term category at this point too.

Rolling wave planning has its source in iterative software development such as the Rational Unified Process (RUP). It is a strategy that is commonly applied by agile software teams and the Project Management Institute (PMI)’s Project Management Book of Knowledge (PMBoK) supports it.

In future blog postings in this series we will work through examples of applying rolling wave planning in practice.

How to Choose an Agile Release Cadence

Metronome

One of the things that a delivery team needs to do, often in collaboration with product management, is choose the release cadence of their product. This is an important aspect of, you guessed it, release planning.  Your release cadence defines how often you release your solution both internally and externally into production (or the marketplace). The issue is how to determine how often the product should be released into production. In this blog we explore:

  1. Where are you deploying to?
  2. What affects release cadence?
  3. What release cadence choices do you have?
  4. What do we recommend?

 

Where Are You Deploying?

There are several target environments that you might choose to deploy to. These environments include:

  1. Demo environment(s). Many teams maintain a demo environment for their solution so that their stakeholders can see what has been developed to date at their leisure. Demo environments support transparency with your stakeholders, reduce the number of “one-off” requests by stakeholders for demos (because they can simply see the solution for themselves), and of course they provide a stable environment in which your teams can run demos.
  2. Testing environment(s). Many teams have their own testing environments, or they work with independent test teams with their own testing environments, or both. You should strive to test as often and early as possible, an implication being that want to deploy into your test environment(s) as often as you possibly can.
  3. Production/marketplace. Some teams will release their solutions into their production environments (or to someone else’s cloud) where end users will use the systems. In the case of commercial software companies they will release their solutions into the marketplace where they are then sold to customers. Throughout this blog whenever we use the term production we also mean the marketplace.

For the sake of terminology, deploying into demo or testing environments are often referred to as internal releases and into production as an external release.

 

What Affects Release Cadence?

There are several factors that affect the choice of release cadence:

  1. Stakeholder needs. How often do your stakeholders, and in particular your end users, want your solution to be released? This can be a difficult issue because very often your stakeholders might not be able to perceive what is appropriate for them. We’ve seen stakeholders ask for quarterly releases, be delighted when then get monthly releases, and then start asking for weekly releases once they realize the potential of modern agile strategies.
  2. Stakeholder capability to accept change. We like to think that more often is better, and in the vast majority of situations it is. As difficult to believe as this may seem, at the far extreme we’ve also seen some systems where the natural release cadence is once every three or four years because that’s the rate at which stakeholders are able to accept change. In this case the product was a transaction processing (TP) system infrastructure product, but we’ve heard similar stories about major database management systems (DBMSs) products too. Granted, a release cadence this long is very rare but it does happen in a small number of situations. Far more common is the mistaken belief by IT professionals that their stakeholders are unwilling or unable to accept shorter release cycles. We’ve seen numerous organizations where the IT people tell us that their stakeholders can’t handle anything more regular than a quarterly or bi-annual release, yet these same stakeholders regularly use commercial software that is updated several times a week.
  3. Your organizational culture. Some organizations, particularly those with an existing traditional release management team, often have release cultures that lean towards larger and less frequent releases. These organizations often have significant investments in legacy systems and insufficient investments in automated regression tests/checks. As a result releasing solutions into production tend to be seen as a risky endeavour. At the other extreme we’ve seen companies with more of a continuous delivery mindset that have a “release as swiftly and often as you can” culture. These organizations have typically invested heavily in code quality, automated regression testing, and automated deployment thus making deployment a simple and virtually risk-free effort.
  4. The team’s ability to deliver. Of course a primary determinant of your release cadence will be how often you’re able to actually produce a potentially consumable solution. This is affected by the skills of your team members, your ability to collaborate, your ability to vertically slice functionality into small features, and your delivery infrastructure.
  5. Your delivery infrastructure. How easy it is to release a potentially consumable solution into production is determined in part by your technical environment. This includes the extent of your automated regression tests, your automated deployment scripts, and your capability to monitor production. In general, the greater the level of automation the more often you can release.
  6. Your solution architecture. Is your solution architected to be released incrementally? Is it possible to enable/disable functionality at a granular level (perhaps via feature toggles or a similar technique)?
  7. The cost/risk to release.   Cost and risk tend to go hand-in-hand when it comes to releasing solutions into production. This is because the more manual your release/deployment processes the more expensive they become and the more likely there are to be problems somewhere in the process. Conversely, the more you automate the overall deployment effort the cheaper it is to deploy and the less risky it becomes as you’re more likely to run into, and then automate a solution to, deployment problems. The less expensive and less risky it is to release your solution the more viable it becomes to release more often.
  8. Release cadence of other teams. Like it or not your team is likely dependent on the work of other teams. For example you may need web services being built by another team, and you can’t fully release your solution until those web services are available in production.  We’ve written detailed articles about how to manage dependencies between agile/lean and traditional teamsdependencies between agile teams, and dependencies between agile and lean teams.

 

Release Cadence Choices

Table 1 lists many common release cadences, from more than annual to several times a day. It also lists the potential tradeoffs of each approach and indicates when you may want to adopt each one.

Table 1. Comparing external release cadence options.

Strategy Potential Advantages Potential Disadvantages When to Apply
Many times a day Enables very short time to market

Enables teams to adapt quickly to changing stakeholder needs

Enables granular release of functionality

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Your solution architecture must support toggling of features to enable deployment of larger functions as a collection of smaller features

Effective for high-use systems, particularly those used by external customers in highly-competitive environments
Daily Same as above

Provides a regular (daily) release cadence that is predictable

Same as above Same as above
Weekly Provides a regular (weekly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Same as above Effective for high-use solutions, particularly e-commerce or BI/reporting systems

Appropriate for teams following the Lean lifecycle

Monthly Provides a regular (monthly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one-week iterations or the Lean lifecycle

Quarterly Provides a regular (quarterly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Enables simpler requirements management practices (compared with longer release cadences) due to lower impact of a feature moving to the next release

This is a major milestone for teams moving towards an “advanced” lean-agile strategy as it motivates greater discipline.

Requires continuous integration (CI)

Requires automated deployment strategies

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one or two week iterations

Variable Works well with a project mindset (although that’s questionable in and of itself) Teams need to be able to judge when their work reaches the minimally marketable release (MMR) stage and the business value added exceeds cost of transition. This decision point is captured in the DAD project lifecycles by the “sufficient functionality” milestone

Politics can hamper this decision point. You should put an upper limit on the acceptable time between release

Project teams

Stable teams assigned large “projects”

Bi-annual Good starting point for teams new to agile who are currently working on traditional projects with longer release cadences because it motivates adoption of disciplined strategies Can be difficult for stakeholders who are used to less frequent releases The team may need significant agile coaching as they will run into many of the “but we’re different and that agile stuff can’t possibly work here” type of problems
Annual Provides a regular (annual) release cadence that is predictable

 

Very risky, the team is likely to miss their date

Requires internal releases to obtain feedback

The deployment has likely become high risk because you do it so infrequently (self fulfilling problem)

Appropriate for low priority systems or for high-risk deployments (note that the deployments may have become high-risk because you do them so infrequently)
More than annual See annual

 

See annual

This is common for infrastructure systems, such as a database or transaction managers, that have many other systems highly dependent upon them

 

Our Recommendations

When it comes to releasing your solution, we have several recommendations for you to consider:

  1. Automate, automate, automate. The more you have automated, the lower the cost of deployment and the lower the risk. This enables you to release more often with confidence.
  2. Release internally very often. This is your opportunity to get good at releasing your solution, at squeezing out the cost and the risk.
  3. Release externally as often as possible. The faster and more often you can release into production the more competitive your organization will be.
  4. Always look for ways to release more often. Impressed with your ability to release once a month? Aim for bi-weekly. You’ve now releasing bi-weekly? What’s stopping you from releasing weekly? Weekly releases? Meh! Release daily! Your team is releasing daily grandpa? How about automatically releasing many times a day every time you have a working build?

 

Further Reading

(In Agile) Where do all the managers go?

Business team

On February 23, 2016 I gave a webinar entitled (In Agile) Where do all the Managers go? A recording of the webinar is posted on Youtube and a PDF of the slides on Slideshare. This blog overviews the webinar and provides answers to the numerous questions that were asked during it.

Webinar Overview

The webinar began with a discussion of four trends that are reducing the need for people in management positions:

  1. Technical management tasks are performed by the team. As a result there is much less work for managers to do.
  2. Leadership is addressed by new roles. Team leadership responsibilities are in the hands of non-managers.
  3. Experienced organizations are moving towards stable teams. Important side effects of this are that much less “resource management” is required and team budgeting is greatly simplified.
  4. Status reporting is being automated away. Once again, less work for managers to do.

We then discussed the options that existing managers have in an agile environment. In Disciplined Agile there are four roles that existing managers are likely to transition to: Team Lead, Product Owner, Team Member, and Specialist. Specialist roles – such as Data Manager, Portfolio Manager, Program Manager, and Operations Manager – occur at scale and the corresponding positions are few and far between. Read the article Disciplined Agile Roles at Scale for more details.

We end with words of advice for existing managers: Observe what is actually happening; be flexible; and choose to evolve.

Questions and Answers

We’ve organized the questions into the following topics:

Evolving to New Roles

Will not the existing technical managers be disappointed with only people management work?

That depends on the person. Some will be very happy to do this, some will not.

How will managers fit into a leader role?

It depends on the person again. Some managers are very good leaders right now, some have the potential to be good leaders, and some don’t. They will need training and coaching to fit into their new role(s).

Addressing “Management Activities”

If there are no PMs in Agile, who handles communication with clients (meeting deadlines, priorities, etc.)

The Product Owner. 

How does individual performance to be taken up in Agile team? I think that is more crucial and challenging for Agile Leader / Manager.

It is always difficult to address performance-related activities. There are many lines of thought on how to do this. The most progressive is for the Team Lead to provide feedback to team members on a just-in-time basis. If the Team Lead seems behaviour, either desirable or undesirable, but a team member then they should comment on it right away so as to reinforce or dissuade it as soon as possible. Many organizations still have an annual review process, a strategy that many organizations have abandoned due to it’s ineffectiveness, where functional managers get involved with the review process.

I have seen that you have selected the Team Lead as the responsible of assess team members and budgeting the project. In Scrum the Product Owner is compare to a CEO that’s the reason I would say the Product Owner is responsible for bugdeting and about assessing I prefer a more democratic form which involve all the members. So what do you think about PO managing the budget and a democratic assessing vs one single vision assess?

Yes, I misspoke during the webinar. The Product Owner is often responsible for the team’s budget and is responsible for reporting the current financial information to the stakeholders. The Team Lead is often responsible for similar reporting to their management team.

Having multiple people involved with reviews/feedback is usually a pretty good idea. The People Management process blade captures several potential strategies. However, it is still a good idea for the Team Lead to provide feedback as well, see my earlier answer.

Potential Management Roles

I think there is still a need a bridge manager role between Finance, Teams, and PMO type orgs to ensure Product owners have budget… views. Thoughts?

In smaller organizations this likely isn’t an issue. In larger organizations there is often a Portfolio Management effort that is responsible for such issues.

What might be potential responsibilities of an Operations Manager, Data Manager, …?

Please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

Okay, the data management team needs a team manager/leader. Are large organizations using various resource managers? (Although would be less necessary with stable teams I would think)

Exactly. Large organizations still tend to have people in resource manager roles, although sometimes they have different titles such as CoE Lead or HR Manager, but with stable teams they need far fewer of them.

If the team has a Team Lead/Scrum Master that is only the servant leader for 1-2 teams, is it suitable to have people managers?

What value would a “people manager” bring to the team? This is the fundamental dilemma for managers, for everyone for that matter, when an organization moves to agile ways of working. If they’re not bringing real value to the team then they either need to find ways to do so, which likely isn’t whatever management activities they’re trying to cling to, or they need to go elsewhere and try to add value there.

Do you intend to update the DA 2.0 interative pic on the DAD site to talk about “Potential Management Roles at Scale” as mentioned in page 18 of this presentation?

Yes. We actually have something in beta that we haven’t released yet. We’re just about to release an update to the main picture, which in turn requires an update to the role version of the interactive pic.

What is the most basic difference between Project/Program/Portfolio Managers in Agile?

Quick answer is that there isn’t Project Managers in Disciplined Agile nor in methods such as Scrum, XP, and so on. At the program level (a large team of teams) you likely need someone in a Program Manager (or more accurately Program Coordinator) role to coordinate activities (see the Program Management process blade for details). A Portfolio Manager is focused on the IT level and should be concerned about pre-development activities, development/delivery teams that are currently in flight, as well as operational activities.

Also, please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

People Management

How does one manage the career path of the Team Leads? Is there career progression beyond a TL to be a specialist or does s/he continue being a TL throughout his career?

Everyone is different, so there isn’t one exact answer. It depends on what the person wants to do and what positions are available to them. If their desire is to move into management then there are fewer IT management positions available to them. If they want to become an AO or PO then they need to work towards getting the skills and experience to fulfill those sorts of roles. The People Management process blade includes career management strategies.

How do you evaluate what roles are/will be necessary?

It depends on the needs of the team in the situation that they face. The primary delivery roles typically exist on all delivery teams and the secondary roles start to appear at scale.

How do you see the role of a BA in agile?

Most existing BAs, like most existing project managers, will need to transition to other roles. However, at scale there is a need for some people in the specialist BA role. I recently has a user group presentation recorded on this very topic. See Disciplined Agile Business Analysis: Lessons from the Trenches.

Management Reporting

How do we approach a situation where management wants weekly status reports from a Program Manager who can combine both Team Lead & Product Owner roles, as well as manage multiple projects that may be similar in nature or not.

A few thoughts on this:

  1. It’s an incredibly bad idea to combine the TL and PO roles because it puts too much responsibility in the hands of one person. Furthermore, putting it into the hands of a former manager, someone who may have a command-and-control mindset instead of the collaborative mindset required of agile, can exacerbate the problem.
  2. You may need someone that Team Leads should work with to coordinate activities between teams (such as a Program Manager or Portfolio Manager) and someone that Product Owners should work with (a Chief Product Owner) to coordinate requirements activities. See The Product Owner Team.
  3. I do see stuff like this happen when organizations are transitioning to agile. They are still learning how to make agile work within their environment, they have a lot of people who haven’t yet made the transition, and they have a lot of middle management staff whom they want to treat fairly by finding them other work. Sadly that other work is often overhead that can be done away with given a bit of thinking.
  4. If you institute automated dashboards, what we originally referred to as Development Intelligence in Disciplined Agile, then a lot of your status reporting goes away.

 

In a typical organization, where to team lead(s) report into?

It depends. We’ve seen them report into a Program Manager or a Portfolio Manager. During the transition effort a Project Management Office (PMO) may still exist so Team Leads might report into there, although we often find that there’s a serious cultural and mindset difference that can be very frustrating for everyone involved.

During Your Agile Transformation

What about managers being responsible to support an agile transformation journey in a large organization?

Yes, they would very likely be working as part of an Agile Center of Excellence (CoE), although that would be mostly staffed by experienced agile coaches. There is a need for one or more senior execs to sponsor your agile transformation.

How to deal with “Project Manager” role renamed as “Agile Project Manager” but expected to do the same responsibilities as traditional PM?

We see this sort of stuff all the time unfortunately. First thing to do is to get these people educated in how agile actually works in practice, we’d suggest DA 101: The Disciplined Agile Experience or DA 104: Introduction to Disciplined Agile as your best option to get the whole picture. Next, work through with them how they would actually add real value on the team (see the discussions earlier). Very likely many of the activities that they think need to be are being handled by someone else or have been automated away. Third, get them some coaching to help them to truly transition to agile.

On my project, I am the Team Lead and there is a Project Manager. So far, I have observed that there are several conflicts in responsibilities. How do we come to an agreement of who handles which responsibilities? For my next project, would you suggest I work on a project with no project manager?

We often have to run facilitated workshops in organizations where we work through the roles and responsibilities that are needed in practice. We do this with a wide range of people and we do so in a collaborative and public manner. You need to come to an agreement as to who does what. Doesn’t sound like that’s happened in your case. When you work through this sort of an exercise you quickly discover that you don’t need a project manager, although there may be some project control officer (PCO) responsibilities that would be assigned to either the team lead or some sort of administrative role (such as PCO).

Do you have any advice on how to deal with the removal of the traditional hierarchy – in a flattening of responsibilities, ‘reporting-lines’ and salaries (or having a vast range of skills and pay-scales all with a job title of ‘team member’?)

This is what an agile transformation will accomplish for your organization. It takes time and investment in your people to implement. I highly suggest that you get some experienced coaches to help you do this.

Management is severely, negatively, personally affected by Agile, and will not look fondly upon it in many cases. Any tips to reduce this? Do you recommend mass management reduction, or multiple smaller rounds?

The first step is to recognize that your organization doesn’t exist to create jobs for managers, regardless of what the managers may think. Agile is about focusing on value, so why wouldn’t a good manager be interested in being actively involved with doing so? My recommendation is always to get training and coaching for everyone, including managers. As I described in the webinar there are many options for existing managers in the agile world if they’re willing to be flexible and evolve. Your organization should choose to help people make these transitions to new roles. However, if people are not willing to make the transition then they shouldn’t be surprised if the find themselves being asked to seek employment elsewhere.

It sounds like the person asking about “who’s responsible for delivery” might have used “responsible” when they meant “accountable” – many managers are the single wringable neck for something in their job description. Do you feel Agile draws the same distinction between the two like ITSM, for instance, does?

Agile is based on a collaborative, teamwork-based mindset. Having said that, it does make sense to have someone ultimately responsible for certain things. For example, the Product Owner is responsible for prioritizing the work on an agile team. Similarly, you may have someone in the Release Manager role who is responsible for overall Release Management within your organization. This is particularly important for regulatory environments where by law you need to have someone not involved with development who makes the final decision as to whether the solution is released or not.

From your observations and experience, what is the average timeframe for the managers number to decrease? How long does the process of the shift take?

It depends. We’ve seen this happen over timeframes as short as six months to several years.  With solid coaching this process will go a lot faster and smoother.

How to motivate and enable senior leaders to give up control?

In agile, particularly in Disciplined Agile, senior leaders have greater visibility and opportunities to steer than what they had in the traditional world. What they need to do is give up their false sense of control that traditional strategies provide. The real issue usually isn’t senior leaders but instead is middle management. They are the people who are currently performing many of the management tasks that are implemented in a more streamlined manner following agile approaches.

How can middle management start the agility journey when top leaders are not yet on board?

Agile typically begins following a stealth adoption strategy where senior leaders are unaware that it’s happening. The point is that anyone, including middle management, can start adopting agile strategies long before senior leadership gets involved. Strategies such as working collaboratively, enabling your team(s) to plan and organize their own work, adopting dashboard technology, and streamlining the bureaucracy whenever possible is very possible to accomplish on your own.

Thanks for being frank about the role(s) for managers in an evolving Agile culture: Agree, traditional project management organization’s aren’t highlighting these trends (and positive outcomes.)

You’re welcome. Traditional project management organizations often go at it from the point of view of how to continue justifying management activities. We go at it from the point of view of how to improve your overall organizational effectiveness and as a result come to a different conclusion.

Stable Teams

Will the idea for stable team become stale after some years? People tend to get frustrated doing same work. What’s the solution in that case?

Stable teams evolve over time. You’ll get people joining the team every so often and similarly leaving the team every so often. It’s natural for people to want to move on and try something new every few years. As a result your organization will still need People Management activities in place that motivate and enable people to manage their careers.

As far as stable teams go, commonly Valve, Inc. is referred to a place where teams are formed around projects that the team members find the most interesting. Project leaders try to sell their project to get developers. Your thoughts?

This is great technique that other organizations may be able to adopt. Allowing teams to form themselves is likely the most effective way to do so. However, like all strategies, there are some potential disadvantages. Team culture may become ingrained and they will not attract people with a different culture who would have the potential to add some real value to the team otherwise.

Is there a method to build the stable teams? Domain, Product, line of business?

There are several strategies for doing this. The most common is to form feature teams that do all of the work to implement a feature as a vertical slice through your entire infrastructure. Another approach is to form component teams that work on a technical or domain component/framework/LoB. A third approach is internal open source. We’ve discussed these strategies in greater detail at Strategies for Organizing Large Agile Teams.

Do you think stable teams concept will work in service-based organisation?

Yes. It’s a bit more difficult because you’d be bringing entire customer projects to the team at once instead of a flow of smaller features. Of course you can break each large project up into smaller features and feed them to teams in an interleaved manner, requiring a sophisticated approach to requirements management.

Training and Certification

What baseline training do you recommend for agile managers?

A good place to start is training on agile thinking, often referred to as how to be agile. Then I would recommend training that describes the full delivery lifecycle from end-to-end, something like DA 101: The Disciplined Agile Experience or DA 104: Introduction to Disciplined Agile. You want to understand all aspects of the agile delivery process, not just the management ones. Scrum training is popular but far too narrow. SAFe training isn’t for beginners.

I would like to participate in a certification workshop/further training. There doesn’t seem to be many offerings in the US. Are there plans to expand training opportunities in the states?

Yes. In fact we have training coming up in the Baltimore area in March and Philadelphia in April. We will have more open enrollment workshops scheduled soon.  Please visit the homepage of the Disciplined Agile Consortium for a listing of upcoming public workshops.

What should we be telling folks that have PMP’s – are they still valid? is PMP training moving toward Agile software development.

Yes, the PMI is moving towards agile but they have a very large ship to turn. Unfortunately the PMI training tends to suffer from the challenges that I described earlier – it seems to promote a rather unrealistic vision of how managers can potentially fit into agile.

The practical realities of software estimation

In IT we are often asked to estimate the expected time/schedule or cost of software development. Sadly, the desire of stakeholders to have “predictable” schedules or costs results in significant dysfunction within a software development team.  When a software team is  forced by their stakeholders to commit to a schedule/cost they must then ensure that the schedule/cost doesn’t slip. For example, to protect themselves from increased time and cost due to scope creep, software development teams will make it difficult for stakeholders to change their requirements during Construction and even go so far as to drop promised scope late in a project. The desire of stakeholders to reduce their financial risk often results in behaviors by the software development team that ensure that stakeholders don’t get what they actually want.  Naturally IT gets blamed for this.

Practical Realities of Software Guesstimation

We need to do better.  In this blog we summarize the things that we know to be true about software development estimation. In no particular order, they are:

  1. Estimates are guesses. Look up the word in the dictionary – An estimate is a rough approximation or calculation, in other words a guess. Unfortunately, too many people think that estimates are promises, or worse yet guarantees.  In our opinion “guesstimate” is a far more appropriate word that “estimate”.
  2. Scope on IT projects is a moving target. Our stakeholders struggle to tell us what they want and even when they do they change their minds anyway.  Any guesstimate based on varying scope must also vary in kind.
  3. Guesstimates are probability distributions. Although your stakeholders may ask for a fixed amount guesstimate, for example “this will cost $1 million”, the reality is that there’s a chance the cost will be less than $1 million and a very good chance that it will be more.  There is ample evidence that the initial estimate for a software development project should be given in a range of -25% to +75%, so your million dollar project should be quoted as a range of $750,000 and $1,750,000.  This is shown in the diagram above by the green distribution curve.  In many organizations this can be politically difficult to do, and strangely enough in many cases stakeholders prefer to be lied to (it’s going to be $1,000,000) rather than be told the truth.
  4. Guesstimates must reflect the quality of the inputs.  A guesstimate needs to reflect the quality of the information going into it – if your scope is fuzzy your guesstimate based on that scope needs to be equally fuzzy.  Sometimes stakeholders want a guesstimate with a tight range, perhaps +/- 10% (the red curve in the diagram), early in a project.  To provide a tight range such as this you need to have a very good understanding of the requirements and the design.  Early in the software development process this can only be done through more detailed modeling, an expensive and risky proposition which often proves to be a wasted effort because the requirements will evolve over time anyway.
  5. Guesstimates anchor perception. The primary danger of providing guesstimates to people is that they believe them.  Tell someone that it’s going to be $1,000,000 and they fixate on that cost even while they are changing their minds.  Tell them that it’s going to be between $750,000 and $1,750,000 and most people will fixate on the cost of $750,000.  Some people will focus on the average cost of $1,250,000 even though the median was $1,000,000 (guesstimates are in effect Weibull probability distributions).
  6. It’s easier to guesstimate small things. ‘Nuff said.
  7. It’s easier to guesstimate work you’re just about to do instead of work in the distant future. It is much easier to identify the details of work to be done right now, and thus turn a large piece of work into a collection of smaller pieces that are easier to guesstimate.  In part this is because you have a much better understanding of the current situation you are working in and in part because you are more focused on the here and now.
  8. The people doing the work will likely give a better guesstimate.   They are more motivated to get the guesstimate right, particularly when they must commit to it, and have a much better idea of their abilities.  Granted, someone may need to coach people through the guesstimation effort.  In Disciplined Agile this is a responsibility of the team lead.
  9. Someone who has done the work before will give a better guesstimate than someone who hasn’t. Experience counts.
  10. Guesstimates reflect the situation that you face.  Which organizational situation do you think will result in a short schedule and lower cost: Five people co-located in a single room or the same five people working from different locations in difficult time zones?  Or how about a team working under regulatory constraints versus the same team without those constraints?  Context counts.
  11. Multiple guesstimates are better than a single guesstimate. Getting guesstimates from several people provides insights from several points of view, hopefully prompting an intelligent conversation that enables you to develop a guesstimate with better confidence.  Similarly, the same person producing guesstimates for the same piece of work using different guesstimation strategies will also provide a range of answers that you can combine.
  12. Guesstimates should be updated over time. As your understanding of what stakeholders want improves, and your understanding of how well your team works together, you should update your guesstimates.  As your understanding of the fundamental inputs into your estimate improves you are able to produce a better estimate, thus enabling the stakeholders of that guesstimate to make better decisions.
  13. It costs money to produce a guesstimate. The precision of an estimate is driven by the detail and stability of the information going into it. Want a tighter range on your estimate?  Then you’re going to have to have a better handle on the requirements, design, and capabilities of the team doing the work.  This greater precision requires greater cost.  The fundamental question posed by the #NoEstimates community is effectively “Is the value of improved decision making capability from having the guesstimate greater than the cost of creating the guesstimate?” The implication is that you must ensure the cost is much less than the benefit, hence their focus on finding ways to streamline and even eliminate the guesstimation effort.
  14. Guesstimation is far more art than science. See point #1 about estimates being guesses.  The best guesstimates are done by the people doing the work, just before they need to do the work, for small pieces of work.
  15. Formal software guesstimation schemes are little more than a scientific façade. Function point counting, feature point counting, and COCOMO II are all examples of formal strategies.  They boil down to generating numeric guesses from your detailed requirements and design, plugging these guesses into an algorithm which then produces a guesstimate. These are all expensive strategies (they require detailed requirements and design work to be performed) that prove to be risky (because they often force you into a waterfall approach) in practice.  Yes, they do in fact work to some extent, but in practice there are much less expensive and less risky strategies to choose from.  People like these type of guesstimation strategies because they provide a false sense of security due to their complexity and cost.
  16. Past history isn’t as valuable as people hope.  Some formal guesstimation strategies are based on past history, but this proves to be a false foundation from which to build upon for several reasons.  First, people have different levels of capability which change over time as they learn. Capers Jones has shown that developers have productivity ranges of 1 to 25, the implication being that if you don’t know exactly who is on a team and how well they work together your corporate history will be questionable.   Second, technologies evolve quickly so past history from working with older versions of technologies or completely different technologies becomes questionable at best.  Third, people and teams change (hopefully for the better) over time, implying that an input into your guesstimate is fuzzy at best.  Fourth, because every team is unique and faces a unique situation basing estimates on past history from other teams in different situations proves questionable.
  17. Beware professional guesstimators. They tend to break many of the rules we’ve described above.

To summarize, when you are required to provide estimates for your software development efforts that you should take a pragmatic, light-weight approach to doing so.  This blog posting has provided many practical insights that should help guide your decisions.  These insights and many more, are built right into the Disciplined Agile framework.