In general, we need to ensure we have coverage of the 5 main stages in delivery (Prep > Design > Engineer > Test > Operate), therefore, the project team should look like the following:
-
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, formulate the backlog in a typical project. 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 skillset 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 fulltime 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 Dev Engineers.
In addition, we should also have the following roles that interact with the team:
-
Planner: The planner will quite possibly work across a number of different sprint teams. The scrum master should be tracking budgets, timescales and unblock impediments. They also liaise with the product owner.
-
Product owner: This is normally the 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. 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 deliverables. 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!
The T-Minus-15 methodology encourages the following values within a team:
-
Be transparency: 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 accountability: 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.
-
Recognise success: It’s important that team members are recognised for their good work. We introduce the Karma points awarding method.
-
Solve problems: 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.
-
Deliver high-quality high-value (HQHV): Deliver solutions to the business that are of high-quality and high-value using the principle of little-and-often. 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 instil these values in your team. Lead by example and demonstrate these values personally: Be transparent with your team and the customer, be accountable, recognise 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!
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 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.
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 upskilling the team, it would be good practice to carry out a skills assessment and from this look to implement a training program.
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.
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.
Positive karma is a concept that refers to the idea that good deeds and positive actions will bring about good things in return. In the context of team building, positive karma can be thought of as a way to build trust and respect among team members.
In our team, we recognize others’ help and success by awarding karma points to each other. These points can be redeemed for hardware (screens, headsets, etc.) or days off, innovation days working on open source projects, or meals out with colleagues.
We review these karma points every week in our team meeting to celebrate successes and recognize contributions. This system has helped us build a culture of collaboration and support that has made us more productive and effective.