There are a lot of different projects vying for attention on our backlog. It can be difficult to make progress through any one project, the end is never in sight, and new projects keep on coming.

This causes headaches for everyone in the production line, from those coming up with ideas, who simply cannot get their new idea worked on, to project managers, seeing their project stretched out for months due to capacity constraints, and to developers and QAs, who cannot figure out what they should be doing next.

My company wants to change the way it delivers software and infrastructure locally and at a group level. Is Dev Ops the right approach? This article looks at some of the problems that a backlog with more than one priority can cause and examines how Dev Ops might solve these issues.

In particular I want to see what can be done about the frequent issue of figuring out what project we should be spending time on next. We often juggle different projects to keep Project Managers happy. The knock on effect is constantly having to make major context switches. Both issues cause delays in getting software into production.

Prioritising

One of the biggest problems is that we have multiple projects competing for the same small amount of resources in each sprint. Project managers understandably want to make as much progress on their own pet projects as possible, but this can cause contention within our development teams.

Consider a sprint with two user stories that appear important but are in different projects. Can the team make the call as to which one is of higher priority? At best they can do so after some discussion, or at worst they need to ask somebody external to the scrum team. We have had issues where such questions were posed but did not get answered for weeks.

We can split the development team up so that some team members work on one and others on another, however, this can also cause problems. Work may get bogged down on a story and the developers ask their colleagues for help? Should they drop the other story or continue? Again the team has to expend mental energy figuring out what to do.

To make matters worse, project managers want the teams to start the estimation process for future work. Should this be prioritised above delivering stories?

Keeping a scrum team’s objective clear and unambiguous will reduce the amount of cognitive complexity that is involved. Our development teams might work better if we were able to complete a single project or feature before moving onto the next thing.

Context Switching

A knock effect to dealing with a large number of projects (or even just more than one) is that team members are required to context switch multiple times per day.

There is ample evidence that multi-tasking is not an efficient way to get things done. While it might feel like lots of progress is being made, in reality, devoting the time to a single task is going to allow more significant progress on the issue.

Consider again the team that has two user stories under development in different projects or code bases. After working on their own piece of testing or coding they then need to context switch to the other project to complete a code review.

That’s not all that needs to be dealt with. Add support for a busy production environment, future project work that require analysis and estimation, and management or support for the current round of user acceptance testing (UAT). These are stories that the team completed in previous sprints. This is a lot of things to juggle.

With monthly releases, our lead times to release “Done” code is between three and six weeks. We have had times where we needed to debug or change three different versions of the same code: the production version, the version in UAT and the next development version. This form of context switching is caused primarily by this extended lead time.

I want to reduce the context switching if possible. Less simultaneous projects is a good start. We should also be attempting to complete UAT much earlier to the time the development is done.

I’ll discuss focusing on automating those tests so that the feedback comes even earlier, for example, shortly after the code is committed, in a later article. It is a key part of Dev Ops and will have a high impact on reducing the amount of context switching we have to deal with.

Dev Ops encourages the principles of focusing on one issue at a time and seeing it all the way to production in the shortest amount of time possible.

Project Manager Stress

We are constantly pressured by project managers to give estimates and plans so that they can figure out when a project is going to be delivered. They have to line up many things that are outside of the scrum teams: approval from executives, external vendors, subject matter experts and business test users, to name a few.

If a project is up against another one of equal size and importance, they will both be worked on in parallel, under our normal operating process. This means that they will take longer to get into production.

Our process is streamlined enough to ensure the most important elements get delivered first, but it still can cause headaches. Often the last few deliverables get dropped when their value is reassessed compared to newer projects.

What we miss out on by allowing this to continue is the missed opportunity being more flexible than our rivals. The opportunity cost can be high.

Dev Ops can help us focus on one project at a time, getting the most value add features delivered quickly. This still allows new projects to surplant old ones where the remaining deliverables are less important. The aim is to reduce that “getting started” latency that adds to the time to get to market.

Dev Ops Focus

Taking the advise from The Dev Ops Handbook, I think we need to change the make-up and focus of our teams, perhaps starting with a single scrum team. If we give them a clear focus, a single goal, so that they never have to question what the next most important thing is, then we reduce or remove the problems related to questions about priority and context switching between projects.

We want the team to work on one thing at a time, getting it from idea into production, and allowing time after release to ensure that monitoring is effective, or to make any further adjustments or re-factorings that are necessary so that the code is easy to maintain.

To achieve this goal, the first thing is that we should ensure that the team sits together. They need to have a shared space for meetings in and around their workspace allowing impromptu discussions to take place whenever needed.

If part of the team is remote, we have to rely on technology to solve the separation issues. An on-line chat room that facilitates team chat is a must. Video calls are also helpful – seeing team mates eye to eye helps with communication. Give the team some license (and budget) to try out new things to reduce the impact of being remote.

A key goal of sitting together is to create a shared purpose, but another thing that this can achieve is to free the team of their former duties. Let them concentrate just on the project at hand. Relocating business users away from their regular team throughout the project allows this disconnection from day to day tasks.

There will be occasions when this is not possible. If former duties cannot be simply dropped, set a fixed amount of time per week when they must sit with the development team. For example, the product owner sits with the team on the first and last day of every sprint. Potentially they can have the biggest impact at planning, review and retrospective meetings. They should also attend the daily stand-up.

Depending on the project, we will need to include the following in our team: developers, QA, a business analyst, a dedicated project manager, a product owner or a subject matter expert, a member of the technical architecture group, an executive (or their nominee), someone from operations, someone from Information Security.

Some of the above will not be needed at all times, but need to be accessible. For example, an architect may be necessary at the design stage of a new project and at regular intervals to check on progress. A single architect may be able to work with one or more teams by dividing their time.

However, the requirement to sit in the same physical area as the team, and get involved face to face is still there. Create a hot-desk seat where they can sit with a laptop. If they are remote, make sure they use the same on-line tools that the team use.

How does this help priority or context switching?

All of the above is for nothing if the team does not work on a single goal at a time. That takes care of context switching and priority.

Couldn’t we do that without sitting together? No. Under the usual setup, it takes too long to get responses from the necessary parties. The reason for having the business users, who are driving the change, sit with the team, is to speed up the pace of the requirements gathering and analysis phase, and to get their feedback regularly during development through ongoing demonstrations.

Instead of having a meeting, generating some actions and then going back to the business as usual tasks, the team begins work on the actions immediately.

Instead of a follow-up meeting, the developers can simply turn their heads and ask direct questions. The focus of the subject matter experts is to be there to answer these questions, which keeps up the pace of development.

Frequent demonstrations and feedback are also enabled by being able to do things right then and there when they are ready. Booking meeting rooms trying to round up everyone is overly formal; simply grab them when they are back at their desk.

Having architects and operators there also helps to get the team thinking in terms of the bigger picture and how the new code will fit into the existing IT systems in terms of release and maintenance. I’ll discuss in later posts how their input to the team will increase the pace of development.

Going back to our goal for Dev Ops, we want to reduce the lead time and deliver value adding software regularly to production. This focused team, with everyone working to the same objective is sure to reduce the time between the idea generation and release.

What if the subject matter expert is not available?

The Dev Ops transformation process for our organisation should start small to ensure it gets done properly. Start with a single development team. Until there are a few success stories it may be difficult to get adequate resources assigned to multiple teams. Start by looking out for those that are eager to get involved. Do their pet project first and make sure that it can add real value to the business.

If the team is successful with reducing the lead time to develop and release new ideas, this is going to get noticed. The hope is that there will eventually be a queue of business users waiting to get time with the development team.

We want to train the business to get into the mindset that if they can commit time to the development team, then they will get rewards – high quality, value-adding software – within a short time. Quality time in, quality product out.

There are going to be times when a high profile user cannot sit with the team. It may make sense to work on building up the infrastructure in those circumstances. The team should have a road map of where it wants to get to, then just take the next item on the list.

This could be to experiment with new or different technologies, clearing off technical debt, or improving the continuous integration flow, perhaps by building up acceptance tests that remove the need for manual testing.

As regards technical debt, The Dev Ops Handbook advises no less than twenty per cent of a team’s development cycles be spent on this sort of work. The longer you leave it the bigger a challenge it will be when you finally have to tackle it.

Focusing on single priorities, one at a time, and getting them to completion, will clear the decks and allow a period where the team can work on something for themselves.

This might just be when their assigned subject matter expert or product owner takes a vacation. There should always be something lined up and ready to go. Just try to make sure that there is value in doing the work.

Conclusion

Create a focused Dev Ops team that includes all roles necessary. Get them to sit in the same location during the development (or provide adequate software for remote working). Allow them to focus all their time on the project (or at least specific time on specific days with no excuses for absence allowed).

Let them do their work and prove that teams with a clear goal, a single priority, and access to everything they need, can deliver high quality, value-adding software quickly, with low lead times, and high user satisfaction.