With the mad rush to Agile, there are a lot of new teams being formed (or re-formed, as the case may be) and launched. When launching an agile team, one thought that consistently comes to mind is, “what are the key areas (that I can count on one hand) to focus on in order to increase the likelihood of their success and duration?” (Often referred to as “critical success factors”, or CSFs)
I’ve drawn on my own experience and that of my colleagues to document what I call the 5 “T’s” - CSFs for agile team startups - which I will address in this article:
1. T-Shaped Skills
When we talk about an agile team, we’re typically (or ideally) applying the term “cross-functional” - that is, a team which has all the skills resident in its membership required to deliver working, quality code at the end of each sprint or iteration. (After all, how else would we measure success with agile?) Since delivery teams are ideally between 5-9 people, it is likely we’ll be looking for team members with more than 1 skill, and preferably a set of skills both broad and deep – hence, the term “T-shaped Skills”.
Given the pace and demand of technology today, a delivery team member’s “T-shaped skillset” must constantly become broader (general knowledge) and deeper (specialized knowledge) as the world of information technology becomes more complex. Challenging as that may be, having T-shaped skills is one of the biggest competitive advantages one can have when contributing value or when achieving your goals.
With the rush to get agile teams rolling, another key question in the minds of leadership is “what kind and how much training, and when?” Quite often there is a wide range of previous training and/or exposure to agile within the technical teams, so there are a couple of good reasons to do some basic training right away with everyone at the outset:
How much is too much?
Teams don’t have to know everything about agile to get started, especially if coaches are engaged – but they’ll need a basic understanding to get started; a 2-3 day basic training or “bootcamp” should suffice. Teams then need to practice the basics immediately as a part of their work, ideally with the help of a coach from elsewhere in the organization or outside if necessary. Having a backlog of features and stories ready when they come out of training is critical, otherwise momentum – and learning - will be lost.
Consistency and standardization
“Agile is simple, implementing agile is hard”
Part of the reason this statement is true is that agile is a mindset with a number of supporting frameworks and methods, and the framework of choice needs to be agreed upon, taught, and followed throughout. It will absolutely help the team if you pick a framework, train on it, and stick to it. Is there a perfect framework? No. Are there good frameworks? Yes, most of them are – and part of the choice depends on the culture of your organization.
Startup vs. ongoing
Once the basics are mastered, teams can then begin to learn the finer points of agile either through ongoing coaching or else additional “point” training on topics such as automated testing, acceptance test driven development, etc.
Basics can be typically be taught in 2-3 days. This is typically a hands-on workshop for the team members, managers, and business owners. It covers definitions, what Agile really is, how to work together, how to define the business value needed, and how to deliver on that need.
Establishing “Communities of Practice” (CoP’s) helps both on the training side as well as the cultural side as you try to engender an agile mindset in your organization. These CoP’s serve as forums to share experiences, discuss finer points, raise questions, and so on. Some companies begin with a generic “Agile CoP”, and then as teams increase in number and in maturity may split into “Product Owner CoP’s”, “ScrumMaster CoP’s”, etc.
Dojos (Startup and Ongoing)
Some companies have started establishing “dojos”, wherein teams are brought to a carefully designed and organized space and worked with intensely over a 4-6 week period to “lock in” skills and practices. An excellent presentation at Agile 2016 about this was delivered by a team from Target Corporation.
Principles vs Practices
Practices are grounded in principles, and in this case the wide variety of agile frameworks and methods are aligned with the 12 principles and 4 values behind the Agile Manifesto. These need to be taught as both the foundation as well as the reference point for teams as they go through their agile maturation process.
The 3rd T is around basic teambuilding, which cannot be overlooked – especially in the technology space. Given the likelihood of multiple locations and even multiple vendors represented on the same team, extra care invested here has significant payback.
(aka “Tuckman’s stages of group development”) ..cannot be avoided. First proposed by Bruce Tuckman in 1965, this represents the stages a team will always go through when it is first assembled. Not only that, any change to team membership forces a team to automatically go through ALL of the stages again – though likely (hopefully) faster than the original pass since some norms will already be in place and a history of performance exists. Understand this principle and it will be your friend.
Teaming agreements are a key part of “Norming” and a useful tool in helping a team move through this stage. Additionally, a well-articulated teaming agreement will aid a team in maintaining a high-performance culture once achieved. A useful “how-to” for developing these can be found here.
Five dysfunctions of a team
Another great tool for both the storming and norming phases is Pat Lencioni’s book, “The Five Dysfunctions of a Team – A Leadership Fable”. Throughout the story, Lencioni reveals the five dysfunctions which go to the very heart of why teams - even the best ones - often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team.
Globally distributed teams represent a very typical situation today with the heavy use of offshore-onshore models. How distance is overcome needs to be carefully thought out and if done right will involve some investment of time and technology to overcome. There are several useful guidelines and approaches covered by Martin Fowler in a seminal article on this here.
A good team needs a target to go after, and for agile teams that is the Product Vision. This is the responsibility of the Product Owner, should be based on clearly communicated business objectives, and if well-articulated will enable the population of a good Product Backlog – from which would be derived each Sprint Backlog. Coaching the Product Owner in development of the Product Vision based on business objectives, and pre-populating the Product Backlog in anticipation of team launch, is critical.
The 5th and final “T” a team should have is time – i.e. an expectation should be set that it will take time to ramp up to a level of high-performance. If the other 4 “T’s” are addressed, then a reasonable expectation is that the team should be starting to “cruise” at about the 3rd or 4th sprint. (If not, please see “5 dysfunctions of a team” mentioned earlier!). This also requires 100% of team members’ time, not 25% or 50% as is often allocated based on more traditional project mindsets and budgeting.
While keeping the 5 T’s in mind when launching your agile team is not a guarantee of success, using them will go a long way towards helping you focus on the more critical success factors of agile team creation. I have found them to be quite helpful when putting together my coaching plans, and I hope you do as well.
- Pat Campbell