Category Archives: Devops

Leading Image

DevOps: understanding the evolution

Many organizations find themselves somehow confronted with the need to change the way their teams are organized and operating. Echoing in the hallways is this idea of DevOps. It sounds promising and has a lot of common ground with Scrum, which organizations are already familiar with. Moreover, it is drenched in Agile thinking. This blog is the first of a few concerning DevOps. In this blog I’ll describe an organizational evolution which frequently ‘’happens” to IT organizations in their journey towards DevOps. Which phase is your organization in and what is there to gain and overcome?

Definitions

Before jumping into the evolutionary path, let’s spend a minute chewing on three DevOps definitions.

DASA: “DevOps is a cultural and operational model that fosters collaboration to enable high performance IT to achieve business goals.” [1]

Humble: “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.” [2]

Len Bass et al. “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality” [3]

As you can see, the definitions have some overlap but aim their focus differently. The term DevOps has not one clear and uniform definition that is shared in the community. Therefore, it is a good practice to find some common ground before starting any discussion on DevOps in your own organization. For now, it is good enough to have a feeling of what a definition could look like.

Scrum
1. Pre-DevOps: Scrum teams

Scrum is still the most widely applied framework which is used to organize software development teams. There is no need to differentiate in level of maturity or quality by teams using this framework. In this phase, teams just focus on getting their next Increment of Done software ready and possible even release it. In the team all capabilities to get the software Done should be present, for example designing, programming, testing & even appropriate documenting. However, these are all capabilities and not roles and they are preferably not tight to only one person. All members are simply called developers and there is a chasm between teams and production environment.

COMMON CHALLENGES: managing external dependencies, including limiting waiting times and hand-overs to other departments for deployments.

Continuous_Delivery
2. Pre-DevOps: CD/CI

Since the Continuous Delivery (& Integration) revolution was ignited by Jez and Farley in 2010, a lot more attention is paid to automate and integrate, test execution, deployments on pipelines and feedback loops. The availability of tools that could execute and monitor these activities via – more or less – user friendly interfaces helped getting momentum. In this phase teams are able to deploy much faster and more reliable to different stages. The long-winded deployment manuals become something of a quickly forgotten past, instead the teams are empowered with new tools.

COMMON CHALLENGES: setting up reliable pipelines, changing existing software with CD in mind, depending on the team that supports the pipeline tooling and operator who execute the deployments to production.

DevOps one
3. DevOps round I: Functional Operations

Coming from the previous phases, teams have a rhythm of delivering working software. They should start to live by the mantra “You build it, you run it”. Teams become more interested in the health and status of the production environment. That is an excellent reason for reaching out to Functional Operations to obtain this – more business – side of the software. New questions arise. How is the software used? Which features are the most valuable ones? What is the logging or monitoring of the production environment telling us? The usual approach to enable this organizational need is by extending the existing delivery teams with people who have this Operational role. Often these people come from a more centrally organized department. In doing so, the teams receive more responsibility in the shape of team members who are authorized to see certain data on production and who have in-depth knowledge of how the software is being used. This Functional Ops-role is embodied by an Ops-Engineer who joins the teams.

COMMON CHALLENGES: embedding the Functional Operators in the team (and not creating a split team), getting the required rights available for more team members, getting all the information from production to the team e.g. logging and monitoring information.

DevOps two
4. DevOps round II: Technical Operations

Once organizations have more than a few development teams, there are usually also some supporting teams around. The latter teams are usually specialized in the infrastructural layers of the software solutions: development machines, testing environments, disk management and operating systems are all good candidates. If such a central team or department is in place, this team is often responsible for the deployments of new software into production. But, the newly empowered teams in phase 2 or 3 have no such need anymore. More importantly, the teams themselves have the technological means to get their new Increment deployed on any stage or server that is required. The next question usually follows very soon: “Who is now allowed to perform the deployment to the production environment?”. This task had been one of the most eminent examples of the segregation between Dev & Ops, but is in this phase integrated into one.

COMMON CHALLENGES: again, embedding new people in the team, especially when mindset between Dev & Ops are colliding.

BizDevOps
5. Post-DevOps: BizPerfSecDevOps?

In order to make teams more and more self-supporting, they need other capabilities, either technical or more business oriented. Depending on the nature of the business and – again – the size of the organization, any of the following experts’ roles could be eligible for the team: DB-admin, security expert, platform engineer, performance engineer, UI/Interaction designer, SEO specialist, business expert.

COMMON CHALLENGES: which extra responsibilities are helping teams to create more value versus which capabilities should remain separate?

Conclusion: How to evolve?

From an organization view point any of the phases described above is just one of the almost infinite amounts of possibilities to get organized. Take a step back and see how your organization is just a collection of people, with skills, tools, tasks, responsibilities and mandates organized in a particular way. We aim to come up with the exact organization that is able to create the most value. In the evolution above there is an ongoing shift in roles and responsibilities to and from teams. The context of the team is very much leading in getting the optimum setup. Longstanding organizational setups and existing boundaries are often hard to get by.

One way of thinking more out of the box is by raising the question: “What if we only had two teams?” or even better “What if we only had one?” This forces you to elaborate on who is allowed to do what and why. This question is applicable in all phases, yet becomes paramount in the last one. Last but not least: don’t get stonewalled by the existing organizational structures and boundaries.

Notes:
1. The aforementioned common challenges are by no means complete.
2. Furthermore, being in a next phase does not exempt you from keeping attention to practices of previous phases (e.g. Scrum).

In the next Blog I will focus on the above used terminology in depth.

References & recommended reading:

[1] DASA: DevOps Fundamentals_Glossary_English
[2] https://theagileadmin.com/what-is-devops/
[3] Bass, Len; Weber, Ingo; Zhu, Liming (2015). DevOps: A Software Architect’s Perspective.
[4] Scrum a Pocked Guide, Gunther Verheyen
[5] Continuous Delivery, Jez Humble, David Farley
[6] The DevOps Handbook, Jez Humble, Patrick Debois a.o
[7] DevOps for Developers, Michael Hüttermann
[8] The Phoenix project, Gene Kim, Kevin Behr a.o.

Filled Under: agile,devops,scrum,software development Posted on: 7 June 2019

Leading Image

Product Owners in DevOps: What dominates your Backlog, Urgent or Important matters?

Product Owners have a great responsibility in prioritizing the work on the Backlogs. Their role can hardly be underestimated. How about some support from the past? Decades ago Eisenhower made a quote on important and urgent matters. His idea has transferred into a matrix used to prioritize personal actions. Can Eisenhower’s priority matrix help Product Owners in prioritizing backlog items? I think so. In this post I will combine Eisenhower’s ideas with those of Agile product backlog management, and a little wild life.

Eisenhower’s matrix
In short, Eisenhower’s matrix focuses on four distinctive quadrants created by the two viewpoints – urgency and importance. The goal is to determine someone’s priorities [1][2].

Urgent matters: require immediate attention. If possible you should act on these matters now. Important matters: these relate to long term objectives and need constant focus. When combined this leads to the following overview and actions:

Eisenhower Matrix

Now let’s transpose these quadrants to backlog management in an Agile environment. All work on the Backlog can be qualified according to Eisenhower’s quadrants. But what is the optimum setup for your Sprint Backlog? Is there any? Based on the model, I will discuss a set of situations which are all taken from projects and teams I have worked with over the years. In these situations, teams are working on Product Backlog Items that primarily originate from one of the quadrants. To make teams easily recognizable, they all have a different nickname which sticks out.

 

1. Orange Firefighters, brave and busy
Agile firefighting dog

If your teams are busy working on the urgent important issues or new work of this category is entered each running sprint, it seems like your devops-teams are firefighting. This is only a good thing when a) there is an actual fire and b) – more importantly – they can extinguish the fire. If this pattern is more the rule than the exception, changes are something is not OK. This could relate to your production environment, either the applications, the infra, people handling it, or all. Try to look for the root causes and fix those, via the regular process of course. Instead of focusing on optimizing the fire-hoses and firemen. Although your teams are working on the top priority work items, there are risks and down sights. For example, every Product Backlog item which is refined or taken in the sprint and pushed out by the orange firefighters, has been a waste of time. Moreover, the company’s short term future may get hurt if this situation occurs for too long a time.

PROS: working on top priority items, CONS: waste in preparation time, pressure within teams, ATTENTION: should not persist for long, focus on fixing root causes!

 

2. Blue Coyotes, opportunistic
Agile Coyote

Sometimes teams are working on urgent but not important issues sprint after sprint. These teams are the so-called coyotes. This scenario also raises an interesting question. Are those issues really urgent? If you and your team tend to say no, there should be a dialogue. Re-discuss these issues with your stakeholders and try to balance them out with your company’s important stories. In practice it is more convenient to work on topics that are urgent to our stakeholders now. However, don’t go for convenient, but invest in discussions and long-term goals.

Okay, so are you done when the answer is yes? Well, sorry, no. If this situation is continues for a long period of time, it could be a sign that you are understaffed. Not working on the important issues, could be a serious threat to business continuity on the long term. Perhaps you can consider to appoint a temporary team that can eliminate the ‘pile’ of urgent stuff, which is in the way of working on the important stories. However, one thing should be in place before you scale up: a clear vision on what is actually important. This may sound like a no-brainer, but more than a few Product Owners are struggling in identifying what is really contributing to the company’s future.

PROS: satisfying to stakeholders, CONS: not working on the long run, ATTENTION: are backlog items really that urgent or is there too much stuff in the way?

 

3. Green Tortoises, steady but a bit boring
Agile Tortoise

The third scenario reflects the mindset of the tortoise. Namely, where the majority of the work directly relates to important backlog items. Good for you, you keep the company or department in business. However, you might be missing out on immediate revenues from low hanging fruit. Why not optimize your SEO rank now and then, or eliminate that bug 80% of your users are complaining about? These small improvements won’t harm the long-term objective and they do give you a change to help users, increase the short-term cash-flow and satisfy a few stakeholders along the way. Like their nickname, these projects or teams can be a bit boring and move slowly towards a certain ‘old age’ or goal. In their journey, they could lose the connection with the rest of the organization when results are not made visible in the meantime. Besides that, if these projects entail migration without new functionalities, also the teams can get bored. They may benefit from the diversion of small improvement stories.

PROS: working on the mission of the company, CONS: in long running projects stakeholders can get detached, ATTENTION: room for quick wins along the way?

 

4. Well… Black Dodo’s
Agile Dodo

If you have teams working on the black stuff, something is off. Perhaps you are way overstaffed, or backlog management is in utterly disorder. Avoid this situation at all costs. When nothing changes soon these teams will become extinct…

PROS: none, CONS: waste of time and energy for all, ATTENTION: immediate action required!

Balancing act, rhythm and focus

Do you feel like you are getting mixed signals now? You are right. This is the arena where great Product Owners can stand out of the mediocre crowd. If they are able to balance the Product Backlog with the stakeholders and find a rhythm together with their team(s) to ensure enough focus, you have a winning combination. Relevant questions to be answered are: Who is your most important stakeholder? And how are competing stakeholders managed? What is most important for the customer and the future of the company?

A predicable heartbeat helps the team and PO in delivering on regular intervals. Yet, it also promotes alignment in the rest of the organization. The characteristics play an profound role in the optimum heartbeat. For example, if you are part of a true DevOps team, you know ad-hoc work (important and urgent issues) will emerge and that is part of your sprint routine. In another case you might have a more component oriented team, building stuff for other teams.

If you only have one development team available, the balancing act of shifting priorities becomes more precarious. The team can feel comfortable working on multiple topics in one sprint and it is not forbidden to do so, as long as there is enough clarity and stories are really Done at sprint’s end. However, most teams benefit from focus during the sprint, so when possible, craft your Sprint goal on one or two categories only. You could for example spend one sprint on urgent matters and the next two or three on the important trajectory. In general, true orange stories are always executed asap. When multiple teams are involved you can have more flexibility and for example rotate duties between teams every few sprints.

Last thoughts

So, Eisenhower can help in identifying certain wanted or unwanted patterns in your current Product Backlog. What it cannot do is provide the ‘correct’ distribution. That task is still meant for the Product Owners and their teams. I am curious, what kind of wildlife represent your teams currently and how is your Backlog setup in terms of Eisenhower’s quadrants?

References

[1] Eisenhower: http://www.eisenhower.me/eisenhower-matrix
[2] Eisenhower: http://www.businessinsider.com/dwight-eisenhower…..
[3] Coyote: https://nl.wikipedia.org/wiki/Coyote
[4] Tortoise: https://en.wikipedia.org/wiki/Tortoise
[5] Dodo: https://en.wikipedia.org/wiki/Dodo

Filled Under: agile,devops,scrum Posted on: 14 April 2017

Mission statement

Setup, guide and coach high performing teams capable in delivering truly great software.

Be Awesome

How? Try to improve something small everyday..... In management, in coding or life.

Learn from anybody

Be aware that every colleague, teammember or friend is capable of something that you are not.

Fail and letting fail

Failure is the only way to success, so fail fast and fail often, especially in software development.