What to do when you don’t know what to do AKA how we help newly formed teams at Redgate
This post is all about how my role (Development Managers) work with Tech Leads (The people who manage our development teams) in making sure a brand spanking new Redgate development team gets started in the right way.
We’ve got some experience of doing this (Rightly and less rightly ☹) so the Dev Manager group decided to get together and agree a rough guideline set of principles to provide to teams who are just starting out, in effect this is a guide for teams who don’t necessarily know how to get started.
BIG IMPORTANT CAVEAT TO ALL OF THIS****
This is absolutely not about us telling teams what to do, we think of it more as the combined wisdom of the Dev Managers who have done this many many times before as agile coaches, scrum masters, delivery managers etc. where we’ve seen things work well (Or even not so well).
We encourage our teams to decide if they want to use any (Or all) of these guidelines, but if they don’t we’ll be looking to them to explain what they’ve replaced it with. We also suggest these practices are used as just a starting point. You’ll have seen my previous blog post about how Redgate does agile here and as a result we don’t do agile ‘by the book’. Instead we encourage teams to continuously improve which means its highly likely teams will quickly evolve from the starting suggestions we provide to them below.
The List
- A goal (short or long term) just something that you can all agree you’re trying to achieve, hopefully this will be captured in the OKRs you have, but if you don’t have these yet at least agree something you want to achieve. Without this it’s likely you’ll all be pulling in different directions.
2. A planning session — You’ll have seen those cat posters with some witty or inspiring piece of drivel on them about ‘reaching for the stars’ so us saying ‘Fail to plan, plan to fail’ might sound like we’ve gone full-on cat posters. Sadly, it’s true. Without a plan the A team wouldn’t have escaped all those locked barns and without a plan your team won’t get much further than breakfast. So, you need a good planning mechanism to allow the team, your Product Manager, you and your stakeholders to agree the work that needs to be done and prioritize it. Both the Scrum and Kanban methods have useful versions of these that will help you break down the work into useful chunks that can be iteratively built and released.
3. Scrum or Kanban? — Both of these methods are really useful to development teams and contain a helpful set of frameworks you can use or tweak to help your team get a bit of structure to their work. For most standard dev teams, we’d recommend starting with Scrum first and using a 2-week sprint mechanism to provide some stability. You can always tweak these things later. If your team is being formed more to provide product support or is in an explore stage for the early development of a new product then Kanban might be a better option to select.
4. Stand-Ups — these are the daily plan session for your team, the basic structure is to talk about what you did in the time since the last stand-up, what you plan to do before the next one and any impediments preventing you from doing the latter. There are loads of ways to make your stand-ups ‘stand out’ (pun intended) from the crowd so don’t be afraid to experiment.
5. A review/demo session — We have a division wide show and tell, but you get just 8 minutes to talk about all the awesomeness your team has done over the last 4 weeks, that’s even less time than Mark Hamill had on screen in the Force Awakens. So, you should have some sort of demo/review session with your team, Product Manager and stakeholders at the end of each iteration to show them the work that the team have done. It’s a great way to get some real time feedback and for the team to see just how much progress they’ve made. The important thing is that this work does not need to be finished, it can be work in progress.
6. A retrospective — To retrospect or not to retrospect, that is the question. So, said Hamlet — or something very close to this. We on the other hand think retrospectives are incredibly important to the health and effectiveness of your team. If your agile house was on fire and you had to grab just one item from it, we’d recommend it be this one. Your retros are the opportunity for the team to reflect on the great, the good and the stuff to think about next time. A great retro will give the team an opportunity to introspect on the work, to gather some data and insights and then agree some actions to take forward. There are many examples of retros you can use OR if you don’t feel ready to do one yourself, ask a trusted colleague to help run it with you/for you.
7. Whiteboards — board space is really useful to help plan, walk through ideas, track the work or share knowledge. Boards can be electronic or physical, but as a once great pop singer sung ‘let’s get physical’… Physical boards encourage collaborative discussion and act as information radiators (Yes, we really did just say that), electronic boards can sometimes lead to accountability issues i.e. I’ve raised a ticket in Jira so its someone else’s problem now. If it doubt, draw it out!
Do these things help?
We like to think so. As I mention above, these are absolutely not cemented for every new team that forms, instead they act as a simple starting point when a team may have just formed and doesn’t necessarily know what to go after first. So having a clear goal (Or North Star) to aim for is important to provide that sense of purpose to a team (Especially in the very important first few weeks of forming — see the Tuckman model).
What we especially love to see is where a team starts to evolve beyond these practices, that could be changing the agile techniques they use, experimentation with approaches such as a zero bugs policy, daily retros, release trains, TDD, BDD, trunk based development etc. etc.
But surely there’s more to it than this?
Sadly there isn’t. At least not for us.
We’ve tried a number of different approaches with newly formed teams, some of which really didn’t help teams get started very well and created dysfunction that could have been avoided.
Simply going in and telling a team what they need to do doesn’t play to the servant leadership aspect of our role as Dev Managers, leaving a team to it feels a bit like ‘sink or swim’ and helicopter management of a team where we swoop in to save a team from themselves creates a dependency model which becomes hard to break. Instead we simply provide some suggested stabilizers for a team to try (Or not) and make sure we are on hand to offer coaching and support to them frequently in the first few important weeks after forming.
What do you think?
We know this model isn’t perfect and won’t work for everyone, so what ideas do you have for helping a new team start on the right foot? Comment below or tweet us to let us know your thoughts.
