Disciplined Agile

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.

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.

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.

This posting, the first in a series, overviews a disciplined approach to DevOps.  It begins by defining DevOps, no small task given the continued debate within the DevOps community, and then described a disciplined approach to DevOps.

Defining DevOps

For our purposes we propose the following definition:

DevOps is the streamlining of the activities surrounding IT solution development (dev) and IT operations (ops). 

Figure 1 below summarizes this idea, showing how the development and operations groups within your IT department begin to breakdown the barriers between them that inhibit effective collaboration.  In organizations that have not yet adopted a DevOps mindset we say that there is a “DevOps gap.”  This gap results in lengthy solution deployments and hence higher costs to deploy; a long mean time between deployments (MTBD) which is often measured in terms of months; reduced market competitiveness; and reduced ability to govern your IT efforts due to lack of real-time intelligence.  When organizations close the DevOps gap, by adopting strategies described later in this article, they effectively address these challenges and more.  They do this by adopting a mindset that promotes collaborative, learning-centric ways of working that are supported by agile practices and automation.

Figure 1. Closing the gap between IT software development and IT operations.

Defining Disciplined DevOps

What does it mean to take a disciplined approach to DevOps? It requires discipline to do the things that are good for you that you may not normally choose to do.  Given this, we propose the following definition:

Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.

To understand the difference, let’s work through the scope implications of what DevOps could mean to your organization.  Figure 2 depicts an initial strategy for scoping your DevOps efforts, basically rethinking the interactions between your Development teams and your IT Operations team.  Notice how in Figure 2 we’ve started to use the term “IT Operations” and not just Operations.  This is because many organizations choose to distinguish between their IT operations activities and their business operations activities (such as selling, distribution, marketing, and so on).  Of course IT operations exists to support business operations.

Figure 2. An initial view of DevOps.

Some organizations will start with the strategy of Figure 3, particularly when there is a separate group responsible for managing the release/deployment of systems into production.  These Release Management teams are often, but not always, a subgroup of your IT Operations team.   Product companies that are creating solutions for the marketplace will typically have a separate Release Management team because the release effort includes both IT release activities, in particular releasing updated solutions into production, as well as customer-facing release activities (such as marketing, sales, and so on).  A disciplined DevOps strategy streamlines both the IT and the business aspects of your Release Management activities.

Figure 3. DevOps with an explicit Release Management activity.

Although Figure 3 is clearly a step in the right direction, it isn’t complete.  A Disciplined DevOps strategy will streamline the supporting activities performed by your Enterprise Architecture and Data Management teams.  Enterprise architecture activities that support DevOps includes the definition, support, and evolution of technical and business roadmaps which guide the efforts of the rest of the organization.  This in turn supports the creation of a common and consistent technical infrastructure within your production environments, enabling common DevOps practices such as continuous deployment, automated end-to-end regression testing, and operational monitoring.  Supporting data management activities include the definition, support, and evolution of data and information standards and guidelines; the creation, support, evolution, and operation of data sources of record within your organization; and the creation, support, evolution, and operation of  data warehouse (DW)/business intelligence (BI) solutions.  All of these activities will be described in greater detail later in future blog postings.

Figure 4. Disciplined DevOps – An enterprise view.

All three views are valid, your organization needs to decide which one is most appropriate for them given their current situation.  Figures 2 through 4 have been presented from the point of view of a potential DevOps maturity model – you could start with the initial strategy presented in Figure 2, then improve it to address release management (Figure 3) and finally evolve your strategy to address other IT activities such as enterprise architecture and data management (Figure 4).

In following blog postings we will show how DevOps strategies are explicitly addressed by the Disciplined Agile (DA) toolkit, thereby taking some of the mystery about how DevOps works in practice.

We are often asked what makes a Disciplined Agile (DA) coach effective.  The features to look for in a DA coach include:

1. People skills.  First and foremost, effective DA coaches need solid people skills.  They need to be prepared to work with a wide range of people coming from different backgrounds, with different learning preferences, and with different learning goals.  As a result DA coaches need to be empathetic, patient, respectful, and open-minded.
2. Experience.  Good coaches understands the situation that you face, and more importantly understands how to guide you to tailor your strategy.  Effective coaches have many many data points from their experiences over the years, and as such they can recognize patterns quickly and provide appropriate advice to those their are coaching.  We’ve seen people who are very good agile coaches for small, co-located teams get into serious trouble the first time they need to deal with scaling factors such as large team size, geographic distribution, or regulatory compliance.   We’ve also seen good development team coaches flounder when they first start to address, in a meaningful way, the Agile IT issues faced by organizations applying agile across their entire IT department.  This is one of the reasons why we suggest that Transformation coaches be Certified Disciplined Agile Coaches (CDACs) as they need significant experience and knowledge to be successful.  The implication is that when you’re hiring a coach, make sure they’ve worked in environments similar to yours otherwise you run the risk of paying for their learning experiences.
3. Pragmatism.  As Mark Lines astutely pointed out a few months ago, DA is pragmatic agile.  Effective DA coaches are willing and able to work closely with the people that they’re coaching, providing practical advice that they follow themselves. They also like to have real-time measures that reveal how their team(s) are doing, enabling them to make fact-based suggestions to help their teams.
4. Knowledge.  It’s reasonable to expect a DA coach to be very knowledgeable about DA and agile in general.  Development team coaches are at least Certified Disciplined Agile Practitioners (CDAPs) and better yet CDACs.  To earn a CDAP you need to have at least two years agile experience, clearly a bare minimum for someone in a coaching role, and be able to pass a challenging test which explores their understanding of the DA toolkit.  CDACs need to have five or more years of experience and must pass a board-level interview.  These are meaningful certifications that people must work for to earn, and are a clear indication that holders of such certification have the requisite DA knowledge.   Transformation coaches, who coach an organization’s executive team through the process of transitioning to agile, should be CDACs.
5. Skill.  Development team coaches must be skilled in fundamental agile techniques such as regression testing,  continuous integration (CI), iteration/sprint planning, look-ahead modelling and planning, requirements envisioning, and many more.  A good team coach should also be skilled in “advanced” agile techniques such as test-driven development (TDD), behaviour driven development (BDD), and continuous deployment.  Transformation coaches should be skilled in organizational change management as well as the fundamentals of IT-level activities such as enterprise architecture, data management, operations, portfolio management, and others.
6. Leadership.  In addition to solid people skills, good coaches often need good leadership skills too as they need to be adept at convincing people to follow their advice.  Team coaches will often be Team Leads, or at least be working closely with the Team Lead, to help lead the team in making the “hard decisions” required to successfully learn the agile mindset.
7. Flexibility.  A fundamental concept of the DA toolkit is that you need to tailor it to meet the needs that you face.  The implication is that DA coaches need to be agile to go beyond the advice in prescriptive methods such as Scrum or SAFe.  Instead of working from a prescriptive playbook, DA coaches will leverage DA’s goal-driven strategy to help guide teams make process-oriented and organization-oriented choices that are right for them. In short, just because someone has several years of Scrum coaching you can’t count on them having the background to be a good DA coach because they may only understand Scrum strategies and not the full range of agile and lean strategies supported by the DA toolkit.

When it comes to organizing large or geographically distributed agile teams many people will tell you that there are two strategies, taking what is called a component team approach or taking a feature team approach.  Many people will tell you to take a feature team approach over a component team approach, but the fact is that both strategies has advantages and disadvantages and neither is right for all situations.  Furthermore, those are the only two strategies as you will soon see, although to be fair they are the most common two.

This article explores the four basic strategies for organizing agile teams.  We compare and contrast these four strategies in Table 1 below, in accordance to the “it depends” philosophy of the Disciplined Agile Delivery (DAD) framework.  Our goal is to make it clear that you have choices when organizing agile teams, and that you should understand the trade-offs that you are making with each choice.  You will also find that you want to combine strategies, and in fact most large agile programs that we’ve seen do in fact do this.  The four strategies are:

1. Component teams. With this approach each sub-team is responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams.  Because component teams are effectively organized around your architecture you will need to invest sufficient time up front to identify that architecture.
2. Feature teams. A feature team is responsible for implementing a functional requirement, such as a user story or use case, from end-to-end.  This is often referred to as implementing a vertical slice of the solution.  Sometimes a given feature team will focus on the requirements for a single line of business (LoB), such as brokerage or life insurance within a financial institution, enabling them to gain expertise in that LoB. Other times a feature team will take on requirements specific to a given application or system within your organization.
3. Functional teams. Some large teams will be organized by development function – there is an architecture team, a development team, a testing team, a deployment team, and so on.  Each team focuses on their specialized function and hands off their work to other functional teams.
4. Internal open source teams. Sometimes a component or subsystem will be developed via an open source method, even though all of the work is private to your organization.  Developers from other teams voluntarily work on the component to evolve it over time.  When Scott was at IBM he saw this strategy work in practice for several important components reused within several IBM products.  For some detailed thoughts on strategy, read Reuse Through Internal Open Source.

Table 1. Comparing the team organization approaches.

I recently wrote a detailed article summarizing my thoughts about Geographically Distributed Agile Teams.  The article addresses a series of questions that I suspect you’ll find interesting:

1. What does it mean to be geographically distributed?
2. Are agile teams geographically distributed in practice?
3. How does geographic distribution relate to other scaling factors?
4. What are the potential benefits of geographic distribution?
5. What are the risks associated with geographic distribution?
6. How do we address those risks?
7. How do we organize a geographically distributed agile team?
8. How does geographic distribution affect tooling?
9. Is geographic distribution a good idea?
10. Where do we start?
11. What other resources exist?

I hope you enjoy the article.  Feedback is always welcome.