Craft Team Goals— DevOps

Part II is here

I am personally passionate about delivering products and features that help customers. I had a lot of times when I was excited to go to work and make things happen (sometimes we had really hard deadline unfortunately).

As a team lead, it is very important to get team excited about their day to day work and help team see how their work contributes to broader objectives. But how to motivate them? Crafting challenging and exciting goals, and have a goal-alignment discussion with team.

I truly believe DevOps helps team make difference. We, as a team, have been embracing DevOps culture and doing DevOps practices (we are a cross functional build-and-run team doing a lot of testing, automation, monitoring, support, 3 times production deployment a week these days compared to 1 production deployment every fortnight a year ago, etc), and there is still room for us to improve and be more efficient.

As a team that continuously looks for better ways of working and being more efficient, we recently got together and had a few discussions, shared our ideas and created a plan and a few actions on how we could be a better team together by doing truly DevOps.

If you are a team lead and have tons of thoughts and things you want to do, I suggest, instead of asking team if they like your ideas and do what you suggest (because you are a lead, people likely to agree or afraid to speak up), you listen and ask open questions so that team decides what they think, not they are told, can be done differently (see here about my ways of working).

As a lead, you always think big but you also need to be patient and understand you cannot achieve all of those great things overnight. As an Agile team, we take baby-steps and small experiments, and more importantly, continuously improve.

Let’s get started (and more will be coming in the next a few weeks).

What’s DevOps

In this digital world, delivering software faster helps us be competitive. DevOps is a culture and a set of practices that help business effectively, reliably and continuously deliver software for customers.

There are five DevOps pillars

• Reduce organization silos
• Accept failure as normal
• Implement gradual change
• Leverage tooling & automation
• Measure everything

In this post, I am going to focus on how we, as a team, reduce silos within team. There will be a future post about how to reduce silos between teams which get involved to deliver software.

Our Team

Our team is a cross functional build-and-run team and has Product Owner, Business Analyst, Delivery Lead, Developers, QAs, Security and DevOps. We discuss requirements, come up with design and solutions, write code, do testing, do production deployment, monitor and support production.

Ways To Reduce Silos

We looked at, within our team, who and what’s involved to deliver a set of changes and values, and how we can minimise hand-offs or avoid throwing stuff over the wall. We focused on two main silos that have potential hand-offs, requirement gathering and development.

Requirement Gathering

As a team, we want to solve right problems. Giving/Throwing solutions and asking team to deliver them does not create team engagement (team becomes order takers then they will be lack of ownership) and does not help solve problems (a team of problem solver vs a single problem solver).

Problem-led team culture. For any large piece of work that requires more thoughts, for example solution design, architecture changes, .etc, we will take a step back and ask what the problems are, why they are worth being solved, what success criteria are and potential solutions so that everyone understands problems and shares their opinions and solutions from their perspectives. Especially, this is a very important skill for developers and testers because, as developers and testers, we are NOT writing code and doing verification but we are essentially solving problems. It also helps build trust and collaboration, and share learning, for example, developers and testers understand business problems, business analysts understand solution and complexity of implementation and scope of work, etc.

You build it and you run it culture. Being a build and run team, we need to know how our software behaves in production, i.e. healthy, and whether it solves the problems. We have been having our application monitoring using various tools and we agreed that we will keep doing this by making sure requirements include monitoring part, for example, changes are required to collect metrics, set up alerts and dashboard, etc.

Development Practice

“Hey Eric, I have deployed changes for Jira card 123 to testing environment, can you test it?” Does this typical hand-offs sound familiar to you? If this happens, it is an opportunity to break silos between developers and testers, and avoid hand-offs between them. This typical hand-offs usually mean

• Testers are quality gatekeepers
• Testers are go-to person when anyone wonders if changes can be deployed
• Testers have less time to contribute automated testing and have to perform manual testing (this is also a risk and not sustainable because all the knowledge is in testers’ head) given the developers to testers ratio and pressure on frequent release
• Testers are bottleneck and there are a lot of changes awaiting for testers to test rather than continuously deliver changes, which implies more delays and risks (WIP limits may help)

The answer is obvious and is often talked about but, from my experience, it is really hard to achieve because it requires culture and mindset changes.

How do we make quality assurance team’s responsibility so that team, instead of individuals, has ownership on quality?

Team defines acceptance criteria and how to test. In order to get fast feedback on the quality of changes (traditionally, the feedback is delayed until failed test cases are found by QAs which causes unnecessary back and forth between developers and testers), requirements should include acceptance criteria independent of implementation against which everyone can write tests. The acceptance criteria is a joint effort between developers, testers, business analysts and security if required, testers play a VERY important but slightly different role as a coach to shape/design the acceptance criteria. Team defines what types of testing is required (see an example of type of testings here) to cover the acceptance criteria. This helps team build trust and upskill. In practice, it is also worth having different roles working on different types of testing, i.e. another developer or QA working on the unit tests, integration tests, or manual tests. It is also worth trying to have pair programming between developers and QAs so that the changes are transparent and everyone understands the scope of impact, etc.

Breaking silos is NOT about making certain roles redundant or stepping into someone else’s work, but is about building trust, sharing knowledge and team work (as opposed to what individually achieve).