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.
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:
- Where are you deploying to?
- What affects release cadence?
- What release cadence choices do you have?
- What do we recommend?
Where Are You Deploying?
There are several target environments that you might choose to deploy to. These environments include:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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)?
- 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.
- 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 teams, dependencies 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
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
This is common for infrastructure systems, such as a database or transaction managers, that have many other systems highly dependent upon them
When it comes to releasing your solution, we have several recommendations for you to consider:
- 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.
- Release internally very often. This is your opportunity to get good at releasing your solution, at squeezing out the cost and the risk.
- Release externally as often as possible. The faster and more often you can release into production the more competitive your organization will be.
- 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?
- The Release Management Process blade describes the issues surrounding releases in a multi-team enterprise environment.
What is the point of the retrospective?
The retrospective is one of the most important ceremonies in all of agile. This is the time the team spends together to assess how they are working together and define steps to improve that process. It needs to be a “safe place” where people are able to speak openly and honestly. This is their opportunity to air their dirty laundry and work through their inter-personal issues. This is a time of growth for the team and for the team to take ownership of improvement. The team lead will facilitating the retrospective and should manage the interactions to keep the environment safe.
Define the Team
If the retrospective is a team ceremony, then what do we mean by team? The team includes: the team lead, the architecture owner and all other members that actively contributed to meeting the deliverables for the iteration. This includes: developers, testers, BAs, QAs, or other specialists such as technical writers, database engineers etc.
What about the Product Owner (PO)?
The PO is NOT a member of the team. They certainly interact with the team but they do not contribute to meeting the deliverables for the iteration so they are not a member of the team. They are not allowed to participate in the planning poker for the user stories for the same reason. The team votes because they are on the hook for delivering based on the sizing and the estimates but the PO is not on the hook, so they don’t get a vote.
Should the Product Owner participate in the retrospective?
In general, I would start by including the PO in the retrospectives because the team does have to learn and adjust to working with the PO. Keep in mind though that the PO may come and go but the team should stay together so it is most important that the team works well together. As a coach, I usually talk to the PO beforehand to say that they are an invited guest and that it is a privilege to be part of the meeting so they should act accordingly. I have been in many situations where the PO was welcomed at the retrospective, and felt left out if not included. I favor building trust between the business (the PO is their representative) and IT (the team). Including the PO in the retrospective can help the PO assimilate with the team.
I have also had several situations where as the coach I had to ban the PO from the retrospective because they were too commanding and disruptive in the meeting for the team to have an effective retrospective. I have also seen many situations where the PO is also the resource manager of members of the team (which in itself is not recommended). Having managers in the room can definitely have a dampening effect on the member’s willingness to be open and honest about problems and solutions.
If the PO doesn’t participate, at least as an observer, the team runs the risk of having to “sell” the cost of their improvement actions (against other backlog items) after coming up with them. Hopefully the PO is engaged enough with the team to understand its weaknesses and support improvement in those areas whether then attend the meetings or not.
Retrospectives are about improving the process, and a non-trivial part of that is optimization of collaboration between the PO and the team. I would suggest that the team should decide whether or not to include the Product owner.
What about the Stakeholders?
The retrospective should absolutely be a closed door session for the stakeholders since the retrospective must be a “safe space”.
There was a twitter debate lately that talked about a team being subjected to “a drive by criticism from 2 PM’s during a Retrospective”. This is a good reminder why we constrain attendance. The “safe place” is affected by the presence of people with positional authority, potential agendas or other implicit impact. The team may decide to invite such people – usually to ensure that they are communicating improvements needed that are beyond their locus of control. Having outsiders as guests at the retrospective will change the dynamics but at least it is a team decision to do so.
It is very important that the team own their process. If they’re uncomfortable that someone is in the room then that person should be asked to either change their behavior or leave (perhaps to be invited back in the future). The coach should always be thinking along the lines of “do we have the right people in the room” and then act accordingly
Isn’t agile all about transparency?
There was a twitter debate lately that centered on transparency. I believe that transparency is a key element to making agile successful. I’m all for transparency in everything about agile; EXCEPT the retrospective! Sometimes you need to have a family meeting outside of the public eye and that is the retrospective. The retrospective is all about resolving your issues in private so that you can present a united front to the rest of the world. To use a sports analogy, an NHL coach doesn’t invite the business (fans) into the dressing room between periods. There are lots of other places for transparency; the retrospective doesn’t have to be one of them.
The output of the Retrospective
While the actual retrospective meeting is closed to other observers, I would suggest that the action items coming out of the retrospective need to be made public and posted as an information radiator for everyone to see. The changes are more likely to get implemented if the team sees them every day. The team may also want to “radiate” their improvement actions on their dashboard.
The actions and results of the actions may also be shared with other teams through what is often called a Retrospective of Retrospectives. I encourage teams to only choose one or two areas for improvement at a time to provide focus and make meaningful progress.
In this blog posting we describe four general release management strategies that support DevOps. These strategies, from least effective to most effective, are:
- Release windows (slow cadence). A release window is a period of time during which one or more teams may release into production. A release slot is subset within that release window (and may be the entire window) during which a team may deploy their solution into production. For example, your organization may have a policy that production releases occur between 1am and 5am on Saturday evenings (the release window) and that up to four releases may occur during that window (the release slots). In lean terms, a release slot is effectively a Kanban card that allows a team to deploy. Release windows tend to align with periods where system usage is lower, although in the modern world of global 24/7 operations these periods have all but disappeared. With a slow cadence approach to this strategy the release windows occur far apart, as seldom as once a week or even longer. The advantages of this approach are that it provides a consistent release cadence to business stakeholders and it provides consistent release date targets for delivery teams. The primary disadvantage with slow cadence release windows is that they become bottlenecks for release management processes that need to support multiple teams. There are only so many release slots available during each window and this number can be easily exceeded, forcing teams to aim for a future release window. This problem becomes exacerbated when teams start to move to a continuous delivery strategy.
- Release train. The idea with a release train is that every team involved with that “train” has the same release cadence – for example this train releases once a quarter, or once a month, or even once a week. This strategy is commonly used in large programs, or teams of teams, where the individual teams are each working on part of a larger whole. Having the common drumbeat of a release train provides a consistent release schedule for stakeholders and serves as a rallying point for development teams. The train metaphor works quite well in practice. If your team misses the release date, if you miss the train, then the train goes on without you and you need to wait for space on the next on. Dependencies are also respected. For example, if several components need to ship together they must all go on the same train (similar to a family taking a trip together). The primary disadvantage is that development teams are constrained to a common release schedule, making it difficult to support lean or continuous delivery strategies. A potential disadvantage is that release trains may also suffer from the bottleneck problems of slow cadence release windows.
- Release windows (quick cadence). To support continuous deployment, particularly across many delivery teams, you will need a large number of release slots. The implication is that you will also likely need more release windows more often. The advantage of quick cadence release windows is that they are less likely to suffer from the bottleneck challenges associated with slow cadence release windows and release trains.
- Continuous release availability. With this approach delivery teams are allowed to release their solutions into production whenever they need to. In many ways this is simply an extension of the release window strategy to be 24/7. This is the only strategy that truly supports continuous delivery. To make it work a host of DevOps practices are required, such as fully automated deployment, fully automated regression testing, feature toggles, self-recovering components, and many others are required.
Our experience is that most enterprises today employ a slow cadence release window approach although are starting to evolve into the quick cadence version of this strategy. This is usually motivated by the adoption of agile techniques by solution delivery teams and more often than not by continuous delivery practices. We also see large programs take a release train approach, a strategy pioneered in the 1990s by large software companies such as Microsoft and Rational that sold software suites comprised of many products that needed to be shipped together. In recent years the OpenUP and SAFe frameworks have popularized the release train strategy. The strategy of continuous release availability is commonly used in advanced DevOps organizations such as Etsy and Amazon.
An important point to be made is that there are several options available to you, each of which has its advantages and disadvantages. No single approach is perfect, and no single approach works in all situations. You not only need to have choices, it’s good to have choices.
The next blog posting in this series continues with more release management DevOps strategies.
There is no such thing as a “best practice”, except perhaps from a marketing point of view. All practices (and strategies) are contextual in nature. In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death. Two of the philosophies behind the Disciplined Agile Delivery (DAD) framework are that choice is good and that you should understand the trade-offs of the options available to you. In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.
Let’s work through an example. A hot button for many software developers are strategies around cost estimation, typically used for budgeting and forecasting purposes. In the DAD framework initial estimation is addressed by the Develop Initial Release Plan process goal, the goal diagram for which is shown below. As you can see with the Estimating Strategy factor there are several options available to you. We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range. The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list. Your mileage may vary of course.
The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual. One of the reasons why the DAD book is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the framework. As you can see, there are advantages and disadvantages to both strategies. You can also see that there are situations where each strategy potentially makes sense. Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).
|Formal point counting||
|Educated guess by experienced individual||
There are several reasons why DAD’s goal-driven approach is important:
- It makes your choices explicit. If your team wants to truly own your process then it first needs to know what choices are available to it.
- It makes it clear that practices are contextual in nature. No practice is perfect for all situations, every single one has advantages and disadvantages. Are you choosing the ones that are most appropriate for your situation?
- You can have more coherent discussions of the trade-offs that you’re making. We have endless religious battles in the IT industry around process-related topics. This often happens because people choose to focus on the benefits of their favorite practices and to downplay the disadvantages (or worse yet are oblivious to them). To help your team move to more effective practices it’s important to recognize the trade-offs involved with each, to then discuss them rationally, and then decide to adopt the strategy that is most viable given your situation. Note that this doesn’t necessarily mean that you’re going to adopt the best practice from the start, but that instead you’ll adopt the best one that you can right now. Later on, perhaps as the result of a retrospective, you’ll decide to make improvements to your approach (in the case of process factors where the strategies are ranked by effectiveness, your team may choose to adopt a strategy higher in the list).
- Improves the effectiveness of retrospectives. During a retrospective it is fairly straightforward to identify potential problems that you’re facing, what isn’t as easy is identifying potential solutions. You can improve retrospectives by having these process goal diagrams available to you to suggest potential strategies that you should considering adopting.
- You can avoid reinventing existing practices. Many very smart and very experienced people have found ways to deal with the same challenges that you’re facing today. Furthermore, many of them have shared these strategies publicly. If you don’t know that these strategies exist you are at risk of wasting time reinventing them, time that could be better spent adding real value to your organization.
- It enables scaling. Teams in different situation will make different process decisions. Although teams at scale, perhaps they are large teams or geographically distributed, will follow many of the same practices as small co-located teams they will also adopt a few strategies that make sense for them given their situation. DAD’s process goals provide the insight that teams need to understand how they can address the challenges associated with the scaling factors that they face.
For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read. The New Deal for Software Development provides some interesting insights as well.
In addition to the general DevOps strategies and development-focused DevOps strategies we’ve described previously, there are also several technical strategies that support the operations-aspects of DevOps:
- Solution monitoring. As the name suggests, this is the operational practice of monitoring running solutions and applications once they are in production. Technology infrastructure platforms such as operating systems, application servers, and communication services often provide monitoring capabilities that can be leveraged by monitoring tools (such as Microsoft Management Console, IBM Tivoli Monitoring, and jManage). However, for monitoring application-specific functionality, such as what user interface (UI) features are being used by given types of users, instrumentation that is compliant with your organization’s monitoring infrastructure will need to be built into the applications. Development teams need to be aware of this operational requirement or, better yet, have access to a framework that makes it straightforward to provide such instrumentation.
- Standard platforms. Software development practices, such as continuous deployment and initial architecture envisioning, are enabled by consistency within your operational infrastructure. It is much easier to deploy to a handful of standard hardware configurations than it is to a myriad of unique ones. It is easier to deploy when there are consistent versions of infrastructure software (e.g. operating systems, databases, middleware, and so on) deployed across your environment. For example, all instances of your Oracle DB are 22.214.171.124, you don’t have 126.96.36.199, 188.8.131.52, and 184.108.40.206 installed in various places. Furthermore, it is much easier to make architecture decisions when there is consistency of infrastructure software packages in the first place. For example you standardize on Linuz for your server operating system, you don’t also have Windows, z/OS and others also in production (and if you do you’re actively retiring them).
- Deployment testing. After a solution, or an update to a component of your operational infrastructure, has been deployed you should run a quick set of tests to verify that the deployment was successful. Were the right versions of the files installed where they need to be? And were they deployed to all appropriate servers? Were database transformations applied successfully? Did the appropriate announcements, if any, get sent out? Did the overall deployment process run within the desired time frame?
- Automated deployment. Deployments should be automated, not manual. This increases the consistency of your deployments and supports the practice of continuous deployment. Part of your automation effort should be to support both self-recovery and self-testing as native aspects of your deployment strategy.
- Support environments. Anyone doing solution support, even if it is the development team itself, is likely to need an environment in which they can reproduce problems that end users experience. There are several options available to you:
- Production. In some cases your production environment is sufficient, although many regulatory regimes, particularly life-critical and financial-critical ones, will not allow this.
- Pre-production test sandbox. Some support teams will find that they can use their pre-production test environment to try to simulate production problems. The advantage is that you don’t put production at risk when trying to reproduce problems, the disadvantage is that you the test environment will be different than production and as a result you may not be able to simulate all reported problems.
- Support sandbox. Some organizations choose to have a specific environment set up to enable support staff to simulate production problems. This strategy has the same tradeoffs as using a pre-production test sandbox plus the additional cost and maintenance associated with yet another environment.
In the next blog posting in this DevOps series we will explore solution support strategies.
In a previous blog posting we overviewed the concept of Disciplined DevOps, which is the streamlining of IT solution development and IT operations activities, as well as supporting enterprise activities. In this blog posting we begin to overview strategies that support DevOps. This posting overviews general strategies, and future postings will describe development, operations, release management, data management, and enterprise architecture strategies.
There are several “general” strategies that support DevOps:
- Collaborative work. A fundamental philosophy of DevOps is that developers, operations staff, and support people must work closely together on a regular basis. An implication is that they must see one other as important stakeholders and actively seek to work together. A common practice within the agile community is “onsite customer,” adopted from Extreme Programming (XP), which motivates agile developers to work closely with the business. Disciplined agilists take this one step further with the practice of active stakeholder participation, which says that developers should work closely with all of their stakeholders, including operations and support staff–not just business stakeholders. This is a two-way street: Operations and support staff must also be willing to work closely with developers.
- Automated dashboards. The practice of using automated dashboards is called IT intelligence, effectively the application of business intelligence (BI) strategies for IT. There are two aspects to this, development intelligence and operational intelligence. Development intelligence requires the use of development tools that are instrumented to generate metrics; for example, your configuration management (CM) tools already record who checked in what and when they did it. Continuous integration tools could similarly record when a build occurred, how many tests ran, how long the tests ran, whether the build was successful, how many tests we successful, and so on. This sort of raw data can then be analyzed and displayed in automated dashboards. Operational intelligence is an aspect of application monitoring discussed previously. With automated dashboards, an organization’s overall metrics overhead can be dramatically reduced (although not completely eliminated because not everything can be automated). Automated dashboards provide real-time insight to an organization’s governance teams.
- Integrated configuration management. With an integrated approach to configuration management (CM), development teams not only apply CM at the solution level as is customary, they also consider production configuration issues between their solution and the rest of your organization’s infrastructure. This can be a major change for some developers because they’re often used to thinking about CM only in terms of the solution they are currently working on. In a DevOps environment, developers need to be enterprise aware and look at the bigger picture. How will their solution work with and take advantage of other assets in production? Will other assets leverage the solution being developed? The implication is that development teams will need to understand, and manage, the full range of dependencies for their product. Integrated configuration management enables operations staff to understand the potential impact of a new release, thereby making it easy to decide when to allow the new release to occur.
- Integrated change management. From an IT perspective, change management is the act of ensuring successful and meaningful evolution of the IT infrastructure to better support the overall organization. This is tricky enough at a project-team level because many technologies, and even versions of similar technologies, will be used in the development of a single solution. Because DevOps brings the enterprise-level issues associated with operations into the mix, an integrated change management strategy can be far more complex, due to the need to consider a large number of solutions running and interacting in production simultaneously. With integrated change management, development teams must work closely with operations teams to understand the implications of any technology changes at an organization level. This approach depends on the earlier practices of active stakeholder participation, integrated configuration management, and automated testing.
- Training, education, and mentoring. As you would expect, people will need help to learn and adopt your DevOps strategies.
- Continuous improvement. Disciplined agile teams strive to learn from their experiences as well as from others so that they can continuously improve the way that they work together, including how they approach DevOps.
- One team. An important aspect of the DevOps mindset is shifting away from a “them and us mindset” to an “us mindset.” We all work together as a single, streamlined team. An extreme form of this is the “you build it, you run it” philosophy where there are no separate development, operations, data administration teams but instead product teams who are responsible for the entire lifecycle of a product.
Our next blog posting in this series will overview development-oriented strategies.
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 Delivery framework.
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.
- 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.
- 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.
- 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.
- 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 framework. 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.
- 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.
- 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.
- Flexibility. A fundamental concept of the DA framework 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 framework.
If you’re looking for a good DAD coach, consider contacting us at Scott Ambler + Associates. We’d love to help.
Looking for some great DAD video content? Trying to find just the right video to show your boss why moving beyond Scrum to DAD makes sense? Well we are happy to announce that there is now a DAD YouTube Channel which can be found here: https://www.youtube.com/channel/UCcWJ20C86Mzxcsqb73AReHQ Subscribe to keep up to date on the latest DAD talks and webinars. There is also a new link to this channel at the DAD blog website on the sidebar.
We are looking for multilingual presentations so if you are aware of any let us know. For now we have added a talk in Russian.