DevOps Secrets: The A-Team

Team Make-Up

Our scrum team need to be able to autonomously get from idea through to production. Therefore, we need to ensure the team possess the skill set to cover of the 5 areas of Prep > Design > Engineer > Test > Operate.

First we Prep which is the initial discovery stage to start building the backlog, with a structure of Features and Stories putting as much clarity in as we can.

Once we understand the clients requirements, we can start to Design the solution. There will be many elements of the design such as UX/UI, workflows, solution design, architecture design. Remember though, don't go nuts on documentation no-one cares to read: "working software over comprehensive documentation".

Once we're clear how the solution will work and we're clear what the requirements and associated acceptance criteria is, we can Engineer and build the solution. It's "Engineer" rather than say "Develop" as with the principles of DevOps means that Operations Engineers are involved (such as writing infrastructure-as-code templates) as well as Software Engineers and we may be implementing low or no-code solutions that are increasingly more available to businesses.

Before we can deploy to production, we of course need to Test the solution against the original requirements. We want to ensure that we are delivering high-quality high-value solutions to the business over quantity.

Once testing has been carried out and any remediation work undertaken to ensure the solution is fit for purpose, we can deploy (on demand) to production and put the solution into Operate.We want to move our iterative updates into production little and often over big-bang launches. Putting into production also means we need to consider if there are user guides, training and other tasks to ensure the solution is successfully adopted by the business.

Therefore, to get our solution through these stages from Idea through to successful adoption by the business, the project team should have a team make-up something along the lines as follows:

§ Prepper: This is the analyst who will liaise with the customer, populate the initial product backlog, and ideally be able be able to put together wireframes, information architecture and formulate the backlog in a typical project (hence not "just" an business analyst). They will also be hands on during the project delivery and help ensure the quality of the solution delivered that it matches the requirements.

§ Designer: Dependent on the stage of the project, and type of project, you may need Solution Designers (Architects), UX/UI Designers, Data Designers (Architects/Scientists). It’s quite possible that in a smaller team the Solution Designer also has the skill set to act as the Prepper as well.

§ Engineer: This person will be responsible for implementing and building the solution according to the product backlog. You will have Dev Engineers (or software engineers) as well as Op Engineers (operations) and Release Engineers, the latter may or may not be full-time on the project. You could also categorize your engineers as Junior and Senior/Lead. The release engineer is responsible for maintenance of the branches, ensuring successful build and releases and creating release notes.

§ Test pilot: They should be involved throughout the delivery of the project. They put together the test plans from the product backlog and carry out testing (manual and automated if possible) of features as they are delivered. On average you should have at least 1 test pilot full time for every 4 Engineers.

In addition, we should also have the following roles that interact with the team:

§ Scrum master: The scrum master helps the team above achieve their goals. They should also be tracking budgets, timescales, unblock impediments and liaising with the product owner.  A scrum master could possible work across a number of teams.

§ Product owner: The product owner has the vision and is normally a project stakeholder (client side). They are responsible for prioritizing the work and adding clarity when needed . For more information on this role, see: https://www.scrum.org/resources/what-is-a-product-owner

For small teams, you may have to have one person covering multiple roles. Just ensure that everyone has clarity of what their role is and areas of responsibility and that they are 100% committed to the project!

One of the first roles to go is often the Test pilot. However, if we want to ensure you are delivering quality value to the business, don’t underestimate the importance of thorough testing – engineers are not known for making great testers! If I can’t convince you otherwise, at very least, ensure that you are peer reviewing/testing and not getting engineers to test their own deliverable. Engineers will instinctively only think to test the routines they know they have written the code to handle. Don’t blame them … it’s human nature – just ensure someone else is testing their code!

Team Values

The T-Minus-15 methodology encourages the following values within a team:

§ Be transparent: You’ll read in the course of this book how everything is very open. The product owner (customer) has open access to your backlog, developer comments, and the Team collaboration area. Even a large part of the estimate process is done with the client.

§ Be accountable: We also assign responsibilities to specific people. Initiatives and Master Features are owned by the Architect, whereas the Features and User stories are owned by the Engineer to deliver.

§ Be bountiful: It’s important that team members are recognized for their good work by their peers. Be bountiful in your help and praise of others.

§ Be a problem solver: Being a member of the team, you should be a problem solver. You should be pushing things from left to right. At whatever level, whether that’s fixing Bugs, Delivering Features, Delivering Initiatives, or alike, you are overcoming challenges and solving things, not passing the buck for someone else to figure out. This is a “get it done” mentality and certainly not a “finger pointing” culture.

§ Be a student: Always aim to be learning and improving. The marketplace is moving fast and you need time to be once step ahead. Teams need to allow each other time for learning and self-improvement. The principles of DevOps can be taken to a personal level for iterative self-improvement.

§ Be courageous: Be free to autonomously make decisions to determine the success of the project, but also free to learn from your mistakes.

You will notice that many of these values would need to be adopted by the organisation in order for the individual teams and their members to also be free to adopt them. But ultimately, it should lead to the team delivering solutions to the business that are of high-quality and high-value whilst at the same time enjoying the work and learning from the experience. Our target here is not “lines of code”, it’s tested, working, solutions. Make sure the business know about the hard work you are delivering.

Engineers don’t just “throw” functionality over the fence to the Test Pilot(s). Test Pilots, don’t just feedback “it’s broken” without giving clarity to what exactly went wrong with clear steps to reproduce and perhaps even doing some research into what might have caused the failure. Preppers, make sure you have a nicely organised backlog with clear requirements and acceptance criteria. Scrum masters, don’t just play the “management” role with a pointy stick to make your team work faster - get involved into resolving blocking points and reducing unnecessary workload for the team. Product owners, turn-up to meetings, help clarify your needs, help prioritize workload and don’t just say “I MUST HAVE everything”.

As a manager, try to think creatively about how to instill these values in your team. Lead by example and demonstrate these values personally: Be transparent with your team and the customer, be accountable, recognize success in your team and award accordingly (Amazon vouchers, words of recognition and encouragement, bonuses, whatever works for your team), get stuck in and be part of solving problems, and ultimately, ensure the team are delivering high quality value to the business!

Team Recruitment

When recruiting for this A-Team with shared values, remember there is a tide of technology and best practices, so look for place an importance of aptitude to learn rather over skills that can be learnt. But know where your team has a skills deficit and recruit to improve this where possible. You will need to determine:

• Do they have aptitude to learn new skills?
• Do they bring skills we need to the team?
• Do they share our values?
• What are they going to need to learn?
• Will they fit well into the team?
• Does the role match what they are looking for?
• Can they hit the floor running (once they’ve read this book of course!)
• Are they better than me in a certain area? *

* This was something I always look for when recruiting, I personally enjoy working with people where I learn something from rather than feel threatened that they are better than me at something.

Aptitude over knowledge: During the interview process, utilize strategies that look for aptitude over skills. For example, you can implement online aptitude tests or (a more fun method) play "20 questions" during the interview process.

To play “20 questions”, let them know you will be choosing an object on a your phone that they will hold up to their head and they will need to guess the object. They can ask you any question that you can answer “yes”, “no” or “maybe” to try and work out what it is. Rather than 20 questions, they actually get 5-minutes. Let them know even the interviewers will be having a go (it’s only fair if you make them sit there with a phone to their forehead!).

Although unusual in an interview setting - it’s a great way to see how they react to unusual situations. It’s also very applicable to a good developer that needs to be able to narrow down the range of possible causes for a bug, or an analyst that is trying to work out exactly what requirements a customer has.

Team Skills

Although some scrum teams aspire to have all team members be able to pick-up and task (whether that be development, testing or operational tasks), we still believe there is value is the team having specialities and experience in particular areas. Having said that, there some benefit in having a team with a T-shaped skill cross-section. That is, where there is depth in an area with the ability to collaborate across disciplines with team members who have deep knowledge in another area other than their own.

To facilitate the up skill of the team, it would be good practice to carry out a skills assessment and from this look to implement a training program. Consider how you can measure the skills of the team to demonstrate the iterative learning and growth of the team.

Of course – part of the training plan should be taking time to read and review this book! But you can also implement other training such as by using tools such as Pluralsight and in person training.

Remote working

Many teams now work remotely with geographically dispersed which can be challenging if the team are not collaborating effectively across time zones, cultures, and languages. To build a GREAT team, ensure the following are adopted in addition to the other ways of working identified in the T-MINUS-15 methodology.

Time zones: Get your team working in the same time zone. Best to do this from the start of building your team rather than trying to transition to this. There’s no more of a “blocker” than team members who aren’t available for that ad-hoc call and having to put work items off until the next day.

Daily stand-up attendance: Don’t try to split the daily stand-up for members of the team in different time zones. Keep to one daily stand-up and insist on everyone attending. Referring to the working hours above, ensure that it is near the start of everyone’s day.

Full-time staff: Always opt for full-time staff rather than multiple part time staff when possible. For the reasons above, you want people to be available for those ad-hoc calls.

Video conferencing: When having conferences, make use of video and good software. We use Microsoft Teams which is great for conferencing with the ability to create specific Team areas to store documentation and links relevant to that project. You can also setup conference calls with video and recording capabilities. But there are plenty of alternatives out there as well such as Slack.

English: If you’re reading this, I’m going to assume that the language of your business is English. Therefore, even if you team members first language isn’t English, all company meetings should be help in English – you’ll be impressed by how quickly their English improves with team members where English is not their first language.

Geographical location: In today’s age, with a “all companies being a software company” and the tools available to us, it’s certainly possible for all staff members to work from home. However, there is still a valid argument for your A-Team to be located in a common location. My preference would be a location that offers good value for money, but also where you can hop on a plane and be sat next to them after a few hours flight. This also has the benefit of a similar time zone that is only a few hours different for everyone working in the same time zone as mentioned above. Certainly, if they at least work in the same city and can meet up several times per week this has benefits of improved collaboration.

Ad-hoc conferencing (and innovation hour): If team members are on the same project, then encourage just opening ad-hoc conferencing where they can keep the line open and re-create that “same office” feel. This helps team bonding, improves members English if not their first language. I’ve worked on projects where we kept this open all day, cracked on some tunes, had small talk and ultimately very effective in getting things done.

Meet-ups: Ensure that the remote team are meeting up at least yearly as budget allows. Again, this facilitates team bonding.

Team Collaboration & Knowledge Management

Leverage collaboration tools that integrate with your toolchain. For Microsoft DevOps, the natural choice would be Microsoft Teams.

Then invite your customer to participate within the Team! There is very little reason to need a private team chat for a project that a client is not privy too (Microsoft Teams now allows for private channels).

If you still think you need a collaboration group (team) with the client not involved, then your demonstrating that you quite likely do not believe in what value you can offer to the client. Resolve this first. You should be confident that all in the team can communicate with the client – do not be the bottleneck.

Choose your communication and knowledge tools wisely. Enough tools to do the job, store requirements, designs, chats, conferences, etc., but not too many disjointed tools that don’t work together with documents and knowledge never to be found again!

What makes your ideal "A-Team"?

The above article is from the forthcoming book "T-Minus-15: Secrets of an Elite DevOps Team". If you would like to be informed of the release or be in with a chance of obtaining a free copy for review please go here: