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 | estimation | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Improvement | inception | Inception phase | Large Teams | layer | 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 | serial | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | velocity | 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
Kashmir Birk

Recent Posts

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

The Disciplined Agile Foundation Layer

The Team Lead Role: Different Types of Teams Need Different Types of Leaders

Disciplined Agile is a Hybrid

How Large Are Agile Teams in Practice?

Categories: Large Teams, Scaling

The contrite answer is that they’re as large as they need to be, and the contrite agile answer is that they’re as small as they can be.  Now that we’ve gotten the contrite answers out of the way, how large are agile teams in practice?

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following graph summarizes the responses around team size.

Agile team size

This year’s survey found that roughly half (48%) of agile teams are more than 10 people in size and one-quarter are more than 20 people in size.  These findings are similar to what we’ve found in the past with both the 2012 Agility at Scale survey and the 2009 Agility at Scale survey.

In short, don’t let anyone tell you that you can’t do agile with a large team because others are clearly doing so in practice.  Yes, large team agile is different than small team agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery.  The Disciplined Agile (DA) toolkit provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including team size.  In fact, you may find our article around large agile teams to be of interest.

Related Posts:

 

Posted by Scott Ambler on: January 31, 2017 11:00 AM | Permalink | Comments (0)

Disciplined Agile Program Management: Internal Workflow

In this blog posting, the latest in our ongoing disciplined agile program management series, overviews the workflow internal to program management.

Workflow Within a Program

The workflow within a disciplined agile program is depicted in the following diagram.

Disciplined Agile Program Management - Internal workflow

As you can see in the workflow diagram, someone in the role of Program Manager coordinates the three leadership teams (described in greater detail in Large Agile Teams):

  1. Product Delivery Team.  This team is responsible for dealing with cross-team “management issues” such as moving people between teams, resolving disputes that cross team boundaries, and any coordination issue that doesn’t fall under the purview of the other two leadership teams.  The Program Manager often leads the Product Delivery team, which is made up of the Team Leads from the delivery sub-teams, and may even be a Team Lead of one of the delivery teams as well.
  2. Product Owner Team.  This team is responsible for requirements management, prioritizing the work, and assigning work items to the various sub-teams. This team is led by a Chief Product Owner (CPO), not shown, who is often a Product Owner for one more more sub-teams.
  3. Architecture Owner Team. The AO team is responsible for facilitating the overall architectural direction of the program, for evolving that vision over time, and for negotiating technical dependencies within the architecture.  This team is led by a Chief Architecture Owner (CAO), also not shown, who is often an Architecture Owner on one or more delivery sub-teams.

 

The Program Lifecycle

DAD includes a Program lifecycle for a team of teams.  The diagram for this lifecycle is shown below. An important difference between the Disciplined Agile approach and SAFe or LeSS is that the delivery sub-teams may be following different lifecycles.

Disciplined Agile Delivery (DAD) supports several delivery lifecycles, including the Scrum-based agile/basic lifecycle, the Kanban-based lean lifecycle, a continuous delivery lifecycle, and the Lean Startup-based exploratory lifecycle.  Even when the sub teams are following the same lifecycle they may be working to different cadences (or not) – in the Program Management goal diagram we explicitly show that there are several strategies for sub team cadences.

Both diagrams show that some programs may include a parallel independent testing effort in addition to the whole team testing efforts of the sub-teams.  The delivery sub-teams will make their working builds available to the testers on a regular basis, who will integrate all of the builds into their testing environment.  This independent testing effort often addresses end-to-end system integration testing as well as other forms of testing that make better economic sense when done in a centralized manner.  Independent testing is common for large programs that are tackling complex domains or complex technologies or that find themselves in a regulatory environment that requires independent testing.  The SAFe equivalent to a parallel independent test team would be called a system team, in this case one doing system integration plus independent testing.  Same basic concept, slightly different wording.

 

Related Postings

Posted by Scott Ambler on: July 15, 2015 11:39 PM | Permalink | Comments (0)

Why Do We Need Agile Programs?

Why?

An IT program is a large IT delivery team composed of two or more sub-teams.  The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goal of producing a consumable solution for their stakeholders.  In this blog posting we examine some of the reasons why large IT delivery teams are formed and strategies to reduce or even eliminate the need for such teams.

There are several reasons why large IT delivery teams exist in the first place:

  1. Some endeavours are inherently big. Sometimes an organization will decide to take on a complex effort, such as developing an operating system, an air traffic control system, a financial transaction process system at a bank, and many other examples.
  2. Overly-specialized staff promote larger teams.  When IT staff are narrowly focused it requires many people to work, at least part time, on a team so that the team has sufficient skills to get the job done.  When people are generalizing specialists your teams become much smaller and collaborative.
  3. Overly bureaucratic processes promote larger teams.  Sometimes the systemic bureacracy in the organization requires large numbers of people to address that bureaucracy.  I once assessed a eighty-person project team who were doing work that only required between ten and fifteen people to do the “real work” and everyone else to conform to the overhead of their traditional CMMI-compliant process.  Sadly they didn’t rework the team and failed to produce anything after three years and many millions of dollars of investment.  As an aside, it is possible to effectively combine CMMI and disciplined agile approaches, but you need to overcome the cultural dissonance of the two paradigms.
  4. Working on large teams can lead to greater rewards.  Similarly, someone is “empire building” and purposefully creates a large team so that they will be rewarded for doing so.  We have worked in two organizations where before their agile transformation the pay grade of a manager was determined by the number of people the person managed.  Worse yet, in one organization the people on the larger teams tended to get better bonuses, and quicker promotions, than people on smaller teams regardless of the actual ability of the team to deliver value to the organization.

In our opinion only the first reason is a valid one for building a large agile team.  The other reasons reflect aspects of organizational cultures that need to be fixed in time.  Luckily, there are several strategies that you can employ to reduce the size of a team:

  1. Reorganize the problem into a collection of smaller problems.  Disaggregation of a large problem is performed through a combination of agile envisioning and agile business analysis. This is a key responsibility of your product management efforts: to feed reasonably-sized portions of work to IT delivery teams.
  2. Reduce the problem.  Sometimes a large problem can be shrunk down through pruning features out of the vision, or at least by deferring them until later.
  3. Address your organization’s culture. As we discussed earlier, most of the reasons that organizations build large IT delivery teams are the result of cultural challenges.  Fix the real problem by adopting agile and lean ways of thinking and working.
  4. Organize the large team into a collection of smaller teams.  In other words, create a program.

When you find yourself in a situation where you need a large IT delivery team, and those situations do exist in many organizations, and you can’t find a way to reduce the size of the team, then you will need to adopt strategies to coordinate that team.  The disciplined agile project management blade describes such strategies.

Related Postings

 

 

Posted by Scott Ambler on: July 10, 2015 10:08 AM | Permalink | Comments (0)

Disciplined Agile Program Management: External Workflow

In this blog posting, the latest in our ongoing disciplined agile program management series,  we overview the external workflows that a large delivery team is likely to be involved with.

Workflow With Other IT Teams

The following diagram overviews the major workflows that a disciplined agile program is associated with.  Note that feedback is implied in the diagram.  For example, where you see the Technology Roadmap and Guidance flow from Enterprise Architecture to Program Management there is an implied feedback loop from the program to the enterprise architects.  Also note that the workflows do not necessarily imply that artifacts exist.  For example, the data guidance workflow from Data Management could be a conversation with a data management person, it could be a concise description of data standards, or it could be detailed meta data – or combinations thereof.  A second example would be a program providing their development intelligence to the IT governance team through automated rollup of metric data via your organizations dashboard technology.

Disciplined Agile Program Management

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with Program Management
Continuous Improvement Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department. Your continuous improvement efforts should result in improvement suggestions gleaned from other teams that the program can learn from.
Data Management Addresses how to improve data quality, evolve data assets such as master data and test data, and govern data activities within your organization. The data management group will provide data guidance, such as naming conventions and meta data regarding legacy data sources, to all delivery teams.
Enterprise architecture Addresses strategies for collaborative and evolutionary exploration, potential modelling, and support of an organization’s architectural ecosystem in a context-sensitive manner. The enterprise architects will produce a technology roadmap that delivery teams should follow and be a good source of development guidance (such as programming guidelines, user interface conventions, security guidelines, and so on).  Delivery teams will provide development intelligence (metrics) and feedback pertaining to the usage of key architectural components and frameworks to help inform the decisions of the enterprise architects.
IT Delivery Addresses how to develop solutions in a disciplined agile manner.  This includes the four lifecycles – basis/agile, advanced/lean, continuous delivery, and exploratory – supported but DAD plus the program management blade (effectively a large team following one or more of the lifecycles). There will be dependencies,both technical and functional, with other delivery teams (not shown in the diagram).  These dependencies between teams must be negotiated and managed appropriately.
IT Governance Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance). The IT governance team will provide guidance to all IT teams, including large delivery teams.  This guidance typically focused on financial and quality goals as well as any regulatory constraints where appropriate.  Delivery teams will provide development intelligence to the IT governance team to enable them to monitor your team and provide informed guidance to it.
Operations Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations. Your operations group will provide operations intelligence (metrics) to IT delivery teams, in particular around the usage of systems and features that a team is responsible for.  This enables the IT delivery teams to make informed decisions regarding the value of delivered features.
Portfolio Management Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT  portfolio. Your organization’s portfolio management activities will provide the initial vision and funding required to initiate a program, as well as ongoing funding for the program.  It will also provide guidance, often around management and governance conventions, to the team.  IT delivery teams will make their development intelligence (metrics) available to the portfolio management team to help inform their decisions.
Product Management Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line. The Product Management team will provide a business roadmap and stakeholder priorities to all IT delivery teams, including programs.
Release Management Addresses strategies for planning the IT release schedule, coordinating releases of solutions, managing the release infrastructure, supporting delivery teams, and governing the release management efforts. Your program will release solutions into production via your organization’s release management strategy.
Reuse Engineering Addresses how to identify and obtain reusable assets, publish the assets so that they are available to be reused, support delivery teams in reusing the assets, evolving those assets over time, and governing the reuse efforts. All IT delivery teams should reuse existing assets – such as services, frameworks, and legacy data sources – whenever appropriate.
Support Addresses how to adopt an IT support strategy, to escalate incidents, to effectively address the incidents, and govern the IT support effort. Your support/help-desk team will provide change requests, including defect reports, identified by end users to all delivery teams.  These change requests are in effect new requirements.

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with enterprise architecture and reuse management are fulfilled by a single group.  In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team.  Some organizations may choose to have a separate group for each process blade.  And of course the organizational structure will evolve over time as your various teams learn how to work with one another.  Every organization is different.

Program Management and DevOps

A common question that we’ve gotten is how program management is affected by DevOps. For example, you see in the diagram that Operations, Support, and Release Management (amongst others) are shown as things that are external to Program Management.  Remember that the focus here is on process, not on team organization.  For example, in organizations with a disciplined DevOps strategy in place it is very common to see program teams taking on the responsibilities of operating and supporting their own systems in production, and of doing the work to release their solutions into production.  In organizations without a strong DevOps mindset (yet), you are likely to find that operations, support, and release management are done by separate groups outside of your program team.  Context counts, and it’s good to have a process framework that is flexible enough to support the situation that you find yourself in.

Related Postings

Posted by Scott Ambler on: July 07, 2015 02:56 PM | Permalink | Comments (0)

Disciplined Agile Program Management: A Goal Driven Approach

This posting, the latest in a series focused on a disciplined agile approach to program management, overviews the activities associated with program management. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy.  The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog we present the goal diagram for the Program Management process blade and overview its process factors.

The following process goal diagram overviews the potential activities associated with disciplined agile program management.

Disciplined Agile Program Management

The process factors that you need to consider for program management are:

  1. Allocate work. Work items must be allocated to delivery teams, or to open source efforts in the case of programs which include internal open source components, throughout the lifecycle.  The type of work and the focus of the sub-team are the primary determinants of how work is allocated.  However, team capacity and load balancing concerns, for example a team has run out of work or a team currently has too much work, will also be considered when allocating new work.  Work allocation is the responsibility of your product owners although team capacity planning and monitoring is typically performed by the program manager and team leads.  Regardless, these activities should be performed collaboratively by the available people at the time.
  2. Prioritize work.  The work performed by the teams – including new requirements and fixing defects – needs to be prioritized.  There are several ways to prioritize the work, such as by business value, by risk, by severity (in the case of production defects), or by weighted shortest job first (wsjf) to name a few strategies.  Prioritization is an ongoing activity throughout the lifecycle and is the responsibility of your product owners.
  3. Plan program.  Traditional programs are often planned on an annual or even ad-hoc basis.  Agile programs, at least the disciplined ones. tend to be planning on a rolling wave basis.
  4. Organize teams.  There are three common strategies for how you can organize delivery teams within a program – feature teams, component teams, and internal open source – each of which has advantages and disadvantages.  In addition to delivery teams, in a large program you are likely to find the need for leadership teams – the Product Owner team, the Architecture Owner team, and the Product Delivery/Management team – made up of the product owners, architecture owners, and team leads from the delivery teams respectively.  These leadership teams are responsible for work/requirements coordination, technical coordination, and management coordination within the program respectively.
  5. Coordinate teams.  There are several ways that the sub-teams can coordinate with one another.  For example they could choose to have cross-team coordination meetings (also called a Scrum of Scrums (SoS)); they could visualize the work through task boards, team dashboards, and other information radiators such as a modeling wall; they could choose to have “big room” planning sessions where all team members are involved or “small room” agile modeling sessions where a subset of people are involved; or even traditional (or agile) checkpoint meetings.  All of these strategies have their advantages and disadvantages, and all can be applied by the various types of teams mentioned earlier.
  6. Coordinate schedules.  There are several strategies that a program can adopt to coordinate the schedules between sub teams.  The easiest conceptually, although often hardest to implement in practice, is to have all sub-teams on the same cadence (e.g. every sub-team has a two week iteration).  This is what both SAFe and LeSS prescribe.  Another option is to have multiplier cadences where the schedules of sub-teams align every so often.  For example, we once worked with a large program where some sub-teams had a one-week iteration, some had a two-week iteration, and a few had a four-week iteration.  We’ve also seen another team where sub-teams had one, two, or three week iterations that provided alignment of iteration endings every six weeks.  Most common, although rarely discussed, is for sub-teams to have disparate cadences.  This is guaranteed to occur when teams are following different lifecycles (remember, the DA toolkit supports several).  For example, when some sub-teams are following the Scrum-based agile/basic lifecycle that has iterations, yet other sub-teams are following the lean or continuous delivery lifecycles that have no iterations, then you have an alignment challenge.  Or if you have sub-teams adopting any iteration length they like (we’ve seen some programs with sub-teams with two, three, four and sometimes even five week iteration lengths) then they also in effect have disparate cadences.
  7. Schedule solution releases.  Programs need to schedule their own releases, in accordance to your organization’s release management strategy, which involves coordination between the sub-teams.  When the cadences of the sub-teams are (reasonably) aligned then it is easier to coordinate production releases.  For example, when all sub-teams have two-week iterations (or at least the sub-teams with iterations do) then they could potentially release into production every two weeks.  In the case of multiplier cadences, there is the potential to release into production each time the iteration endings align.
  8. Negotiate functional dependencies.  An important responsibility of the Product Owner team is to manage the functional dependencies between the work being performed by various sub-teams.  There are strategies to manage dependencies between two agile sub-teams, between an agile sub-team and a lean sub-team, and even between an agile/lean sub-team and a traditional sub-team (this isn’t ideal, but sometimes happens).
  9. Negotiate technical dependencies.  Similarly, an important responsibility of the Architecture Owner team is to work through technical dependencies within the solution being developed by the program.
  10. Govern the program.  The program must be governed, both internally within the program itself while still operating under the aegis of your organization’s overall IT governance strategy.  Program-level metrics, particularly those tracking the progress of sub-teams and the quality being delivered, are vital to successful coordination within the program.  Sub-teams should also be working to common conventions, ideally those of the organization but in some cases specific to the program itself (perhaps your solution is pioneering a new user interface look-and-feel or new data storage conventions).  Programs, because of their size and because they are usually higher risk, often have more rigorous reporting requirements for senior management so as to provide greater transparency to them.  The implication is that a program’s dashboard often has a more robust collection of measures on display.

How Scaling Affects Program Management

Although program management primarily addresses the team size scaling factor, your tailoring decisions will still be affected by the other scaling factors:

  1. Geographic distribution.  Chances are very good that large teams will also be geographically distributed in some way.  There are two flavors of this: Are teams geographically distributed (e.g. in different physical locations) and are people within a team geographically dispersed (e.g. people are working in cubes, on different floors, in different buildings, or from home)?  Both add risk. Coordination within the program becomes more difficult the more distributed the teams are, and more difficult within teams the more distributed the people are.  Distribution hits the leadership (the product owner team, the architecture owner team, and the team lead/product delivery) teams particuarly hard because members should be located with their delivery sub-teams but also need to work regularly with their counterparts located elsewhere.  The implication is that the team may require more sophisticated tooling to enable collaboration and more importantly be prepared to invest in travel regularly to foster better communication between disparate locations.  Furthermore, when your stakeholders are geographically distributed it may require your Product Owners to get support from agile Business Analysts in the various locations to help elicit requirements from them.
  2. Compliance.  Compliance, either regulatory compliance required by law or self-imposed compliance (i.e. CMMI-compliancy), will definitely have an effect on your approach to program management.  In fact, the larger the program the more likely it is to fall under regulatory compliance due to the greater risk involved. Regulatory compliance generally requires greater governance both within the program and outwards facing as well.  Under some regulations your coordination efforts will require proof that they occurred, such as some form of meeting minutes that capture who was involved, the decisions made (if any), and action items taken by people.  Compliancy may also motivate more sophisticated approaches to capturing requirements by your Product Owners and to documenting technical concerns by your Architecture Owners.
  3. Organizational distribution. The larger the team, the more likely you are to involve contractors, consultants, or even to outsource portions of the work.  When external organizations are involved the Program Manager will likely be involved it the contract management effort, which in turn may require assistance by the team leads.
  4. Technical complexity.  The larger the team, the more likely it is that they are taking on greater technical complexity.  Or, another way to look at it, greater complexity often motivates the creation of larger teams to deal with that complexity.  Greater technical complexity will motivate greater attention to architecture and design, thereby motivating more regular collaboration of the Architecture Owners.
  5. Domain complexity.  Similarly, team size and domain complexity tend to go hand-in-hand.  Greater domain complexity will require the Product Owners to work in a more sophisticated manner and may even motivate them to get support from agile Business Analysts (or junior Product Owners as the case may be).

Concluding Thoughts

In some ways “program coordination” is a more accurate term than “program management.”  Unfortunately “program management” is a far more common term within the IT community so we have decided to stick with it.

Our next blog posting in this series will describe the workflow of program management with other key IT activities such as portfolio management, enterprise architecture, and IT delivery teams.

 

Related Postings

Posted by Scott Ambler on: July 03, 2015 05:53 AM | Permalink | Comments (0)
ADVERTISEMENTS

Mediocrity knows nothing higher than itself, but talent instantly recognizes genius.

- Arthur Conan Doyle