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

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 Portfolio Management

We recently published an article describing how the Disciplined Agile Delivery (DAD) framework is being extended to cover Portfolio Management activities.  The following diagram depicts the DAD goal diagram for Portfolio Management, and as you would expect your organizations has a range of options to choose from.  In this diagram we use the term endeavor to refer to a project, product, or experiment.

Disciplined Agile Portfolio Management

The article describes each one of these process factors – Identify Endeavors, Explore Potential Endeavors, and so on – in greater detail.  A future version of the article will describe the strategies/practices associated with each factor.  We have also included a high-level workflow diagram, see below, to overview from the point of view of the Portfolio Management process blade how it fits into the rest of the Disciplined Agile (DA) toolkit.

Disciplined Agile Portfolio Management

An interesting aspect of the flow diagram is that it shows the relationship of Portfolio Management to other IT Plan activities.  For example, Enterprise Architecture provides a Technology Roadmap and Product Management provides a Business Roadmap and an indication of stakeholder priorities – all critical information that are inputs into the efforts around prioritizing potential endeavors.  The point is that this diagram reflects workflow, not organizational design.  For example, in some companies there is no Product Management team, instead responsibility for the Product Management activities are spread out amongst several teams.  A common strategy is to have the Portfolio Management team responsible for understanding stakeholder priorities and the Enterprise Architecture team responsible for the business roadmap.  Another approach would be to have the Portfolio Management team subsume both of those activities.  A third approach would be to have three teams, one for each of Enterprise Architecture, Product Management, and Portfolio Management.  Different organizations will make different organizational design decisions, and of course these decisions will evolve over time.  As always, context counts.

I hope that you find the more detailed Portfolio Management article to be of interest.

Posted by Scott Ambler on: January 25, 2015 09:16 PM | Permalink | Comments (0)
ADVERTISEMENTS

"Don't let school interfere with your education."

- Mark Twain