Project Management

Disciplined Agile

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

About this Blog

RSS

View Posts By:

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

Recent Posts

Failure Bow: Choosing Between Life Cycles Flowchart Update

Evolving Disciplined Agile: Guidelines of the DA Mindset

Evolving Disciplined Agile: Promises of the DA Mindset

Evolving Disciplined Agile: Principles of the DA Mindset

Evolving Disciplined Agile: The DA Mindset

How Does Data Management Fit In?

Categories: Data Management, Workflow

Key tenets of agile and lean are to work collaboratively and to streamline your workflow respectively. This includes all aspects of your workflow, not just the fun software development stuff that we all like to focus on.  This blog posting explores how Data Management activities fit into your overall process.

In the process flow diagram below we see that Data Management is a collaborative effort that has interdependencies with other DA process blades and the solution delivery teams that Data Management is meant to support. Due to the shortened feedback cycles and collaborative nature of the work this can be very different than the current traditional strategies. For example, with a DA approach, the Data Management team works collaboratively with the delivery teams, Operations, and Release Management to evolve data sources. The delivery teams do the majority of the work to develop and evolve the data sources, with support and guidance coming from Data Management. The delivery teams follows guidance from Release Management to add the database changes into their automated deployment scripts, getting help from Operations if needed to resolve any operational challenges. Evolution of data sources is a key aspect of Disciplined DevOps.

Data Management external workflow

This highly collaborative strategy is very different than the typical traditional strategy that requires delivery teams to first document potential database updates, have the updates reviewed by Data Management, then do the work to implement the updates, then have this work reviewed and accepted, then work through your organizations Release Management process to deploy into production.

In the next blog posting in this series we will explore the internal workflow of a Disciplined Agile approach to Data Management.  Stay tuned!

Posted by Scott Ambler on: May 20, 2017 07:07 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)

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 Enterprise Architecture: Workflow

In this blog posting, the latest in our ongoing disciplined agile enterprise architecture (EA) series,  overviews the workflow of a disciplined agile EA team.  We look at two views of this workflow, from within the team and with other IT teams.

Workflow Within the Team

The workflow within a disciplined agile enterprise architecture team is depicted in the following diagram.

Agile Enterprise Architecture Process

There are four major activities:

  1. Envision initial architecture.  The enterprise architects will spend several days developing initial, high-level models of the enterprise architecture.  This will be a face-to-face, initial architecture envisioning session where the scope is the entire organization, not just a single IT solution.  Ideally this is done in an agile modelling room so as to streamline the communication and collaborative modelling efforts.  Such a room is large with lots of whiteboard space, enabling the team to work on several models in parallel (each of which has its own section of wall space).  The primary purpose of this session is for the EA team to develop a common understanding, at least a high level, of the current state of the enterprise architecture and a vision for how the team would like to see it evolve.  Secondary outcomes include creating some initial artifacts which the enterprise architects will evolve over time, (potentially) meeting one another for the first time, and building bonds between the team members.  Potential challenges to this activity include getting an agile modeling room (you may have to convert an existing room, or accept lower productivity if you can’t get access to such a room) and the logistics of getting the right people together at the same time.
  2. Collaborate with business stakeholders.  On a regular basis enterprise architects work with business stakeholders to understand their needs, work with them to envision the future, and help educate them on the possibilities and constraints of technology.  This collaboration may be in the form of working sessions, presentations, or one-on-one conversations.  These sessions occur as needed and at times it can be difficult to gain access to stakeholders as they are often very busy people.
  3. Collaborate with IT stakeholders.  Disciplined agile EAs will spend the majority of their time, 80 to 90% of it typically, working as members of IT delivery teams.  By doing this they bring their knowledge, vision, and skills to the team in a pragmatic, hands-on manner. On Disciplined Agile Delivery (DAD) teams they will often take on the role of architecture owner (AO).  Enterprise architects will also work with other IT stakeholders, including operations engineers, support staff, the data management team and so on so as to understand their needs.  More on this in the next section.
  4. Evolve architecture assets.  The enterprise architecture team, or at least the portion of the team who is currently available, will meet on a regular basis to evolve the enterprise architecture assets based on their learnings.  A common pattern we’ve seen it for the team to meet every Friday afternoon for two hours where they discuss what they’ve learned that week from working on delivery teams and working with their various stakeholders.  As the result of the meeting several of the enterprise architects may take on action items to update existing EA artifacts.  These artifacts may include EA models, reference architectures, development guidelines, white papers, and so on.  When a new major topic arises, such as the potential adoption of a new platform or a merger with another organization, the EA may choose to schedule agile modelling sessions to explore the topic.

Workflow With Other IT Teams

The following diagram overviews the major workflows that your disciplined agile enterprise architecture activities are 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 Reuse Engineering there is an implied feedback loop from the reuse engineers to the enterprise architects.  Also note that the workflows do not necessarily imply that artifacts exist.  For example, some of the guidance provided by enterprise architects may be discussions with their stakeholders.

Disciplined Agile Enterprise Architecture Workflow

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with EA
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). Enterprise architecture will provide guidance to the IT delivery teams in the form of coaching and mentoring the teams in architectural issues, providing the technology roadmap, and providing development guidelines (such as coding conventions, security conventions, database guidelines, and so on).
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. The continuous improvement activities will provide potential improvement suggestions for improving enterprise architecture efforts.  Similarly, the EA team may have insights to share with the rest of the organization.
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. Enterprise architecture will provide guidance to the data management activities.  Operational intelligence pertaining to production data sources and data activities will be made available to the EA team to support their long-term planning efforts.
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 efforts will provide guidance to the EA team.
Operations Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations. Enterprise architecture will provide a technology roadmap and guidance to the operations efforts so that their efforts to evolve the IT infrastructure reflect the overall organizational strategy.  Operational intelligence will be used by the EA team to provide insights into the effective of various architectural strategies.
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. Enterprise architecture provides the technology roadmap to portfolio management.  The roadmap is used as input into identifying potential business value that could be supported by IT and into prioritization 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. Enterprise architecture will provide the technology roadmap to product management which is an input into evolving the vision for a product and identifying new potential features for products.  Product management provides the business roadmap and stakeholder priorities to enterprise architecture which is used as input into evolve the enterprise architecture.
Program Management Addresses strategies for managing large product/project teams, allocating requirements between sub teams, managing dependencies between sub teams, coordinating the sub teams, and governing a program. Enterprise architecture will provide guidance to large IT delivery teams (programs) in the form of coaching and mentoring the teams in architectural issues, providing the technology roadmap, and providing development guidelines (such as coding conventions, security conventions, database guidelines, and so on).
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. Enterprise architecture will provide the technology roadmap and guidance to the release management efforts so that their planning efforts reflect the direction of the overall organization.  Operational intelligence will be used by the EA team to provide insights into the impact of current architectural strategies on the overall release effort.
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. Enterprise architecture will provide the technology roadmap and guidance to the reuse engineering efforts so that they can better identify potentially reusable assets.  Reuse intelligence will be used by the EA team to provide insights into where to focus technical debt pay down efforts.
Support Addresses how to adopt an IT support strategy, to escalate incidents, to effectively address the incidents, and govern the IT support effort. Enterprise architecture will provide the technology roadmap and guidance to the support team so that they can better understand the overall IT ecosystem and the direction it is going in.  Operational intelligence will be used by the EA team to provide insights into the supportability of the various solutions in production.

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.

Related Postings

 

 

Posted by Scott Ambler on: June 08, 2015 01:44 PM | Permalink | Comments (0)
ADVERTISEMENTS

"The secret of life is honesty and fair dealing. If you can fake that, you've got it made."

- Groucho Marx

ADVERTISEMENT

Sponsors