Due to the great 2019 Post-Superbowl “Snowpocalypse” which has just started to thaw in Seattle, I wanted to pull forward one of my planned posts aptly named “‘Storming’ your Development T
I’ve had the honor of being part of many development teams in my twenty-year career of professional software development. They all had a similar structure, with common titles we’re most familiar with in scrum: Scrum Master, QA Lead, Lead & Sr. Engineers, Product Owner, Business Analyst, etc. People in these teams have had
Early in my career, I was introduced to the Tuckman stages of group development. This can apply to your sales team, your restaurant team, your family, and yes, your software development team. Regardless who they are, if they’re operating in a team
Interestingly, in discussing this topic with my wife (and chief blog editor) we realized how directly this applied to our own family dynamics perfectly. We are a blended family – I brought one of my own, she had two, and we’ve made two together. When we recently added our new baby and the rest of the “team” has flipped out. More on that below…
In the Forming stage, your team is either new entirely or has added a new team member or members. Yes, that’s right, just adding a single resource to the existing team can change the overall dynamic greatly. There’s an old saying “Adding people to a late project makes it later” and it’s absolutely true. During this forming stage, the team is learning: who to trust, who they can go to for help/advice, and subtly feeling out the skills, competencies, and attitudes of their teammates. Work will get done in this phase, though not nearly as fast as it will in a fully developed delivery team.
This phase is one of the hardest phases to escape from, but properly managed, it’s where the strongest bonds are formed. The team starts to develop a dynamic – hierarchies are naturally formed based on either titles/authority (lead/senior/junior), skill levels, or natural leadership ability. Persons not contributing 100% will be quickly identified and initial assumptions will be validated. More often than not, teams can get stuck in this phase. One team I was in spent nearly a full year in this mode until significant and drastic changes were made, including a planned reset back to Forming. This included both rethinking the code and replacing personnel (getting the right people on the bus, in the right seats, all steering in the same direction.)
Things are hopefully starting to smooth out here. The norming phase is generally where team members are starting to align with the strategy fully and embrace the common goal. A cadence develops and the team becomes self-supporting and often self-policing. It’s perfectly normal for scrum calls to include a bit of (polite) verbal pushing and shoving as team members have earned the right to call each other out on performance boundaries. If someone is “mailing-it-in”, the team will know that by now and can hopefully self-organize to address it. This phase isn’t generally as long as the others. You’ll know it when a project starts to feel like it’s coming together. It’s very important here to set the tone and expectation of quality as it will be baked into the next level and harder to improve upon (without going back to the beginning.) Beware though, this is exactly when management, timelines
It’s pretty interesting as an engineer when you first find out that teams just don’t get hired/assigned, arrive and start to produce at 100% together (though wouldn’t that be nice!) Managers aren’t there to make your life difficult and they see these team dynamic changes happening. In a “performing” team, features are getting developed, tested, and released quickly and with very high quality. Engineers and QA don’t fight or use blame as a tool – they are aligned strategically and take care of each other. In the best teams, the scrum call is something people look forward to as much as the iteration demo – where they can get help if needed and possibly brag about their most recent accomplishment.
It’s no surprise that teams that work together often or have worked together in the past will normally have shorter cycle times. I have often received unsolicited offers from prior colleagues when they have a new project that needs a strong team. Having strong bonds formed up previously between team members is like reassembling a jigsaw puzzle for the second time – you tend to know which pieces fit well and where you’re going to have to do some trading with the pile.
In an upcoming article, “Turning a weakness into a strength,” [link TBD], I’ll be covering in more detail how even a wet-behind-the-ears junior developer can have a greater impact on team velocity and performance than a grizzly veteran lead engineer. The one thing I have learned, is the longer you stay in the storming phase – the LESS productive you will be on the other side. Team wounds heal slowly, and as a leader, manager, or even as a junior team member you must help address it quickly – even if you have to show them this blog post 🙂
As for our toddler – she is the one who is adjusting to the new team dynamic the most in our household. She’s definitely regressing and there’s no unit test or automation that is passing anymore during the build process here. She went from being nearly potty trained to us shopping again for diapers in bulk. She went from never using a
P.S. Have you had a similar work or family experience with this model? Did you know that it existed before and what was to come? Drop a message in the comments below and help others!
P.P.S You’re seeing this message as you’re viewing the blog post on TheNetGuy.com. I publish here first – usually a week or two ahead of time. Then Medium and then LinkedIn every Sunday at