How to create an Agile or DevOps team: the human journey

The nature of transformations, whether they be digital, agile or both, involves moving people out of their comfort zones.

For me there are clear similarities on the journey to mature agile and DevOps practices. When reading the following three statements, consider where your current comfort zone is, and how you would feel like going beyond this to achieve increased business agility:

• I know what I will be doing for the next 18 months (Waterfall)
• I know what I will be doing for the next Sprint (Scrum)
• I do not know what I will be doing tomorrow. I will just pull the next ticket from the queue (Kanban).

Now repeat this exercise with the below statements related to the DevOps journey, and you will start to appreciate the parallels:

• I just write new code (Waterfall)
• I write automated tests first and then new code (Test Driven Development)
• I write tests, then code and am now responsible for supporting live systems (DevOps).

DevOps toolchains are big!

Not so long ago, you could have a successful software engineering career being knowledgeable on a modest sized stack of tools, whether they be Java or Microsoft based. Now the expectations are much greater.

When I interview software engineers and they ask me, “what stack do you use?” I am always hesitant in my answer, for fear of scaring them off with the potential learning curve they will face.

The reality these days is that the DevOps toolchain covers a large number of technologies to support; plan, code, build, test, release, deploy, operate and monitor. To some this may represent an exciting opportunity to grow and challenge themselves, but for many the DevOps learning curve can be significant.

The story is the same for would-be agile practitioners, and is nicely summarised by Ken Schwaber and Jeff Sutherland in The Scrum Guide when describing the dominant agile methodology scrum as being “lightweight, easy to understand and difficult to master”.

Development is a team sport

This is an important phrase to remember. It acknowledges that the days of hero programmers that understand intimately the whole codebase are numbered, due to the scale and complexity of modern platforms. Collaboration is more critical to success than ever and the term ‘citizen developer’ captures the right mindset.

So, please remember personnel should not be expected to be alone on the knowledge acquisition path, it requires a team effort to be truly successful, and a support network will help sustainability.

Understand who you take on the journey

So, the pertinent question is how can we remove the anxiety for those upskilling in DevOps and agile? Before I answer that, take a look around your existing department, and ask yourself what is the average age amongst your teams? The larger your department, the more likely it is to be staffed by experienced individuals. This could well translate to an average of around 20 years’ experience.

These are individuals who are at a phase in their lives where family commitments are a prominent factor in the free time they have for education, whether it be children or older relatives (or both!) to help look after. So, how do we create a learning culture that both inspires them to grow and meets their needs?

7 learning culture ideas

1. Lunchtime learning

Speaking as a former techie, we love pizza and fizzy drinks. If these are freely provided by the boss, then you can virtually guarantee you will get a decent attendance to a lunchtime session! These are an excellent way to help staff find the time to learn at work.

The most effective approach I have seen, is to allow the freedom for someone to present on any IT topic they like. Do not limit the sessions to a technology the company already uses or aspires to use, as this is an exercise in inspiring personnel to learn, not just closing gaps in your skills matrix. A monthly frequency is a suitable start, and a mixture of presentation styles is to be encouraged, to prevent the event becoming stale. It is also a great opportunity to grow your confidence in presenting.

2. Hackathons

This is where a group comes together with the express objective of producing some tangible software at the end. Again free food and drink is a suitable motivator and the opportunity to collaborate with others outside their immediate team, is an attractive prospect to many.

One word of caution, please do not place too much pressure on attendees to produce refined results, as they are generally fuelled by goodwill. Hackathons can form part of your innovation strategy, but a way to put everyone off the idea is to give the message “we will occasionally have a hackathon and everyone can be innovative in a limited time window with lots of expectations placed on the event”.

3. 10% time

One straight from the Google playbook: factor in 10% learning time to your sprint capacity planning. Encourage teams to utilise this, ideally with a focus on closing specific skills gaps that exist in the team. After that give them freedom to explore what they like.

We all have different learning styles and being too rigid with the areas to explore can turn people off. One consistent piece of feedback your Scrum Masters may hear in retrospectives is “we ran out of time for 10% learning”. This can be a positive sign of the dedication of the team to achieve the Sprint goal.

Good practice and a solution to this dilemma is to have a soft finish for sprint, a day before the sprint ends, encouraging the team to not take it to the wire, and allowing everyone a day of upskilling.

4. Innovation sprints

If you want innovation to be systematic and in theory free, why not let staff bank their 10% time over a number of sprints and then allow them to work for a whole week on something innovative? This could mean they get to work with developers outside their immediate team, which encourages cross-pollination of ideas and practices. It also provides respite from the treadmill of continuous development of a single product over an extended period.

The Scaled Agile Framework (SAFe) has also incorporated this approach with the Innovation and Planning (IP) Iteration that occurs every Program Increment (PI).

5. Wiki

A well curated Wiki for your technology estate is an excellent investment in knowledge collateral for a department. A sound beginning point is to think about the new starter journey to becoming a productive coder, and what information and resources would be valuable to them.

The key message here is that this is a resource for all and an open source culture of contributing should be promoted. Also, imagine having to switch working between multiple products, and the benefits of reducing the time it takes to relearn the designs and patterns before you can make meaningful changes.

6. Share articles

Articles are accessible in length and can inspire deeper insight. Rather than spam your colleagues with interesting reads, why not maintain a Wiki page with links and a quick summary. That way you can start to organise and further enhance the learning opportunities.

7. Webinars

My personal solution to being a time strapped parent and needing to learn lots of new tech, was to ditch the 600 page long IT books and start watching training videos on YouTube or the platform of your choice.

The beauty of this approach is if you struggle to understand the material, you simply try another trainer who can explain it to you more clearly, or is aligned with your preferred learning style.

Increased responsibility

Having explored ways to create a learning culture and acquire tech skills for DevOps, we next need to consider another comfort zone shift with the increase in responsibility of the individual. The expectation now is that programmers no longer just write new code, but also support the live systems.

Now we start to appreciate that whilst the benefits of DevOps to the business are obvious, behind this there will be a stretched developer, who may not be so convinced. There is also the simple fact that the market demand for DevOps skilled individuals outstrips the supply, so how do we source the right people for the DevOps challenge?

Pay special attention to looking for the following qualities in prospective recruits.

7 Recruitment ideas

1. Mindset

The right mindset is imperative to the success of DevOps. With the right aptitude, acquiring tech skills is just a matter of time, but not having a learning and growth mindset is a much bigger hurdle to overcome.

2. Self-directed learners

“What is the latest tech book or blog you read?” is an easy starting point to explore any evidence of proactive learning. Knowledge of online technical resources is another good indicator.

3. Team player / citizen developer

Is the candidate a team player? This is a standard area to explore when discussing their achievements and contributions. Do they operate beyond the team construct?

This is also a useful way of understanding if they consider the bigger picture of software platform development, and how the department’s goals are met and not just the individual team’s goals.

4. Community activity

Do they attend conferences and engage with the technical community in general?

5. Github / Stack Overflow

Is the candidate active on Github or Stack Overflow? This is a solid question to explore.

6. 12-18 months to become fully productive

How long until my new recruit is productive? This is a legitimate question to ask yourself. Be realistic in your expectations, bringing new talent in inevitably slows your team down in the short term, as existing team members devote time to the successful onboarding.

The Tuckman cycle of Forming, Storming, Norming, Performing, Adjourning needs to be observed also. The only shortcut I recognise is bringing someone in who has worked with some of your team before. A  ballpark estimate is 12-18 months to be fully productive. It is worth remembering even experienced coders may be new to agile and DevOps ways of working, and everyone has to learn your company’s set-up and understand the context.

7. Graduate scheme

Graduates present a great pipeline for talent. They are open minded and thirsty to learn. I have been highly impressed with how quickly they can become productive developers.

There is plenty of evidence on the benefits of pair programming, and indeed a fresh pair of novice eyes can be beneficial in challenging some of the ingrained habits more experienced coders have accumulated over time.

For those out there concerned about training someone up to eventually have them leave, remember it will be a testament to the quality of your culture and ways of working whether they stay or not.

Summary

Having explored the parallels between DevOps and agile transformations, we can now recognise the importance of a learning culture for sustained success, and keeping pace with changing technologies.

We have also seen some practical tips to recruit talent in a high demand market. Good luck with your journey to creating high performing teams!

Mark Bentley
Agile coach
Airbus