Sharing IT Best Practices with youSharing IT Best Practices with you
This article describes some of the most important deliverables of a DevOps planning.
| A funnel is a metaphor used to indicate a selection pathway. The graphical representation is a funnel. There are more ideas than can be realized. As an idea gets more shape and the business case becomes clearer, the idea drops into the funnel and finally gets picked up to be planned in the road-map. The mission, vision, business goal and strategy to realize these are the main driving factors of the funnel. But also aspects that the DevOps organization needs to realize faster time-to-market or higher SLA norms are driving factors. |  |
| A roadmap is an approach to describe a realization path of a product or service. A product may include an information, application or infrastructure component. A product can be used to offer a service to a customer. The roadmap shows a timeline along which the most important functionalities have to be realized are plotted. The entire portfolio of products and services to prevent bottlenecks has to be taken into account. |  |
Release planning is the basis for the product backlog. The release plan contains the epics that have to be realized. The epics represent the items on the product portfolio. The next release is described in more detail by detailing Epics into features.
Within DevOps, often the Lean principles are used. One of the most appealing is flow. A DevOps team should deliver products by working in a particular cadence with no waiting times and no repairs. Therefore, a maximum time to market is realized with the least cost and the desired quality.
Within DevOps, the pull mechanism is employed that states that the flow is controlled by demand and not by supply. Thus, within supply no stockage is available.
These terms indicate that choices have been made during the realization that do not deserve the beauty award. The product and / or service is released but require a further redesign to make it future proof. In the worst case, it is a band-aid solution.
This concept describes the idea that the realization of a product or service can take place from coarse to fine. In this way, the realization of ideas in the funnel, roadmap planning, release planning and sprint planning is completed.
More and more organization use Agile principles to create or change the service offering to the business. In many organizations, the product backlog is used as a starting point to collect the features and write them in a user story format. DevOps teams can then realize these features and deploy the created and changed objects in to production. This may be valid for small changes like content management changes. However, for complete new services this approach does not work well in practice. There is a need to have a functional decomposition based on an architecture approach. Often this approach is not appreciated and the slogan “up front definition is not done” is used often. This article explains the benefits of the functional decomposition based on funnel management, a road-map and a release planning.
Many organizations expect from a DevOps team that the planning only consists of completing the product backlog by the product owner. The top of the product backlog is then refined and contains the highest priority. More downwards, the pieces are bigger and have less priority. In that case, the slogan is often used “up front definition is not done”.
In these organizations, you also see that architecture is only considered per sprint and is formulated incrementally and iteratively. There remains only a kind of solution architect that is directing the DevOps team for the changes that are at hand in the sprint. And often there is not even a role for architecture.
For many simple products and services that need to be realized, this may be sufficient. For complex products and services involving more DevOps teams, or even a complete program has been organized, this is no longer a realistic approach. There must be a functional decomposition.
An anti-pattern of a funnel approach is an organization in which development teams receive in each sprint new and changed assignments because something has to be realized fast. In this case funnel management does not exist, even no flow exist. In fact, these organizations do not have a DevOps control from a mission, vision, business purpose and strategy. And if there is a direction, then the DevOps teams are disconnected from this direction.
In such a situation, it is important to recognize the benefits of funnel management. The main benefits are located in:
Funnel management is for some organizations just a matter of implementing it. Other organizations need a transition strategy. It is important to especially determine why it is necessary to interrupt the sprint and to avoid the flow. A first start may be to distinguish two types of DevOps teams. One team is only driven from the funnel and gets via a roadmap and release planning work while the other team gets only ad hoc business-like incidents, emergency cases, ad hoc developments etcetera. This creates an opportunity for at least one DevOps team to demonstrate the benefits of DevOps.
A road-map is drawn up per product or service. The simplest way to compile a road-map is to draw a diagram with two axes. The vertical axis is the stakeholders and the horizontal axis the quarters in a year. Next, each cell can indicate which functionality for a stakeholder is realized in what quarter.
The classification of functionality and quality in blocks per quarter sounds simple. But that’s just a step too fast. From architecture, it is important to check whether the order is logical. There are always certain aspects that need priority because these conditions are preconditioned, such as security in the form of authentication, authorization provisioning, encryption et cetera. However, usually these are standard features that can be used.
Different it is with the interfaces between the other products and services. Each product and service has its own road-map. The sum of these road-maps must be overall a harmonious whole. As a product or service occurs in multiple chains, the planning of the road-map will be more difficult. Therefore, road mapping and funnel management without architecture is impossible.
A release planning is quite easy to realize when the road-map is already set up. The elements of the future functionality remain vague. The actual benefits are described in the detail before the first release. Although DevOps uses a continuous pull mechanism with a steady flow, a functional decomposition in the form of release planning is very important.
An anti-pattern is an incremental and iteratively generated application whose new features cost more time and quality is deteriorating. This is because the new features do not fit properly with the existing functionality. Often there is no more time for refactoring, where old products and services are re-designed. Release planning can only reserve time to include refactoring of products and services in the planning, as from road-map planning.
Another anti pattern of release planning is the introduction of technical debt. By including in the funnel and road-map aspects that are necessary for a good DevOps process and the product / service architecture, technical debt can be avoided. By incorporating architecture through the entire life-cycle from idea to deployment through architecture, countermeasures for technical debt can be taken into account.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.