What Is A Team?

In general, Agile fundamentally, and Scrum in particular, relies for success on self-organizing teams. The eleventh of the principles behind the Agile Manifesto states that "the best architectures, requirements, and designs emerge from self-organizing teams." Empowering the team is one of the seven principles of Lean. One of the central Scrum patterns is 'Stable Teams.' But before we get on to the notion of empowerment and self-organization, maybe we should first sort out what a team is? There might not be a term in English that is more abused than 'team.'

Improve your operations and optimize customer value with Agile & Scrum

Real Teams

I think every manager I've ever spoken to has talked about their "team." Still, very often, they refer to individual, discrete reports that never talk to each other and sometimes don't even know each other. So what kind of "team" is that? It isn't one, of course. So what do real teams look like?

Fortunately, some work has been done on this that we can leverage. J.R. Katzenbach and D.L. Smith, in their book, The Wisdom of Teams: Creating a High-Performance Organization, define a team as "...a small group of people with complementary skills, committed to a common purpose, performance goals and approach for which they hold themselves mutually accountable." Now, these authors weren't looking at Agile development teams or, by and large, product development teams at all. Mostly they looked at management groups and found that many groups that called themselves teams were not real teams, and many didn't describe themselves as teams at all - hence the need for the definition they give. However, if you follow Scrum, the attractiveness of this definition is obvious.

Scrum Teams as Real Teams

First, "small group": Scrum teams range from 5 to 11 persons if you include the Scrum Master and Product Owner. If you're interested in the dynamic role of the Product Owner, then check out CSPO Training. Next, "complementary skills": Scrum's development teams are cross-functional. They include all the skills necessary to deliver the product. Then we have "committed to a common purpose, performance goals...": Scrum teams are guided by a product vision maintained by the Product Owner and set their own performance goals each Sprint in the form of a Sprint Goal. They exhibit collaborative behaviors ("common approach") to achieve their goals and hold themselves mutually accountable for their work. This is sometimes called the 'musketeer approach' ("all for one and one for all").

Importantly, Katzenbach and Smith explain that their definition of a real team is not just a list of characteristics but is, in outline, a description of the discipline groups must perform - a daily diet if you will - if they are to grow to become a real team. You don't get real teams by decree or by flicking a switch. The process is a journey that requires patience on the one hand since it takes time and investment on the other because a conscious effort to form real teams is required.

So, what are the groups that are not yet real teams? The book describes the notion of a working group - a collective whose performance requirement is no more than the total of their contributions. It is only when the needed performance level is a whole more significant than the sum of its parts that a real team is required. And the journey is not free of risk. Since we were children at infant school, all of us have been judged as individuals. The same was true when we went to junior, secondary, and college. We are typically assessed for our performance at work as individuals. If we've been judged relatively, then at least we have a sense of our destiny being in our own hands. But when you are assessed as part of a team, you are being asked to give up some of that control and to put your fate in the hands of others - the team. This requires considerable trust, which does not come overnight at that level. It needs to be earned through experience.

Team Performance Curve

Consequently, when working groups are put into "teams," their performance often drops. They have no sense of a common purpose and still work individually rather than collaboratively, but now the overhead of team meetings hinders their productivity. They are pseudo teams rather than real teams. The Wisdom of Teams depicts the journey graphically via The Team Performance Curve (below). Groups that understand they have a common purpose, at least, but have not yet developed the collaborative skills to achieve it are called potential teams in this graph. They look much more like teams, but their performance level is no better than that of the working group. The biggest gain in performance is when the potential team transits to a real team. When real teams go beyond that definition, and members have a deep commitment to each other and the goals they are trying to achieve, then real teams can become genuinely high-performing teams. Often, they outperform comparable other teams and do so to the extent that nobody anticipated beforehand. Every Agile team should aim to become a high-performing team.

Assessing Agile Teams

Teams, let alone high-performing ones, need thoughtful investment to become real teams. The challenge for Agile adoption is how best to target that investment. Agile is, after all, a paradigm shift from how products have been traditionally put together. Learning Tree's PMI Agile Certified Practitioner training can be an excellent fit for those bringing their organizations into the Agile state of mind. By definition, it involves disruption of the organization at some level. There are trade-offs. Organizations need to decide how much cost and pain to endure to achieve their business goals through Agile. This is where the self-assessment of Agile teams comes in. By first identifying the goals to be achieved, realizing why they are essential and determining how to recognize when they have been achieved, high-performance team coaches can identify what level of "Agile Fluency" the team or teams need to get there. Then, working with the teams to perform a gap analysis, the coaches can help organizations focus, laser-like, on the next steps the teams need to take on their high-performance journey. On the resources and support they need from their management.

Investing in Agile Teams

Putting together an investment plan for Agile is non-trivial. Most organizations need expert help from outside first to shape the initial plan and later to assess its impact and outline the following steps to be taken based on that data. Ultimately, these coaching skills need to become embedded internally as a Certified Scrum Professional. In the meantime, some facilitators can use various models and techniques to help organizations and teams self-assess. The advantages more than outweigh the cost of external consultancy. A single team that "breaks even" in terms of delivery of value with its salary cost of, say, PS600,000 p.a will, by improving by a mere 5%, add PS30,000 of value every year. And with a more substantial improvement of between 10% and 20%? And over five years? And with multiple teams? Millions could be added to the balance sheet.

Do the maths. Invest in your teams.

Learning Tree's expert Agile consultants can provide services to help organizations and teams self-assess to identify their next steps forward. Tools range from simple questionnaires to the complete application of the Agile Fluency^TM diagnostic. For an initial chat call

Lean into a more responsive development process with Agile & Scrum Training and Certification. Available In-Person, Online, or as Private Team Training!

This piece was originally posted on Dec 18, 2018, and has been refreshed with updated styling, links, and media.

Written by Alan O'Callaghan

As mentioned in a previous post on the value of Scrum certifications, I became a Certified Scrum Product Owner (CSPO) in May 2011, some thirteen years after I first engaged with Scrum. The reasons as to the delay in gaining certification were outlined in the previous article. But why CSPO certification? Why not Certified ScrumMaster (CSM)? CSM is, by far, the most popular entry certification available from the Scrum Alliance. This might be because, if you have only a nodding acquaintance with Scrum then it’s the one new role that you will almost certainly have come across. The Product Owner role is also the newest one in Scrum. The ScrumMaster and Development Team member roles have always been there. To be honest, if I had applied for certification in the early years of the Scrum Alliance then I, too, would probably have opted for CSM. ScrumMaster was the role I played first when using Scrum, and is still the one I’ve played most in Scrum Teams I’ve been involved with. I have since added CSM to my CSPO and Certified Scrum Professional qualifications, by the way – so it is not because I have underrated the ScrumMaster role in any way. So why was CSPO certification my first choice? My main reason for becoming a CSPO was that I had realized in the interim, when Agile entered the mainstream, that for Scrum to be sustainable over time the Product Owner role is probably the most important one to get right. Is the CSPO the “One Wringable Neck”? As far back as 2007 in his book The Enterprise and Scrum, Ken Schwaber had written about the Product Owner having the “one wringable neck” in the Scrum Team. I don’t think for one moment that he was suggesting that the Scrum Team as a whole was not collectively responsible for the success of their product. A team wins together and loses together, as any team sports coach worth his or her salt will tell you. Schwaber was, however, trying to draw attention to the special responsibilities of the Product Owner within the Scrum team. Let’s list them briefly. Product Owner Responsibilities • is responsible for the Return on Investment (ROI) and the Total Cost of Ownership (TCO) of the product • has the job of ensuring the value of the delivered product is at maximum • must optimize the value of the work performed by the Development Team • manages the Product Backlog, and orders the items within it to-to-bottom • must make the contents of the Product Backlog available, and in a way that they can easily understand • makes decisions about when to release increments of the product to the customers • is the only person who cancel a Sprint Strategic Significance of the CSPO Taken together, these responsibilities add up to some very serious strategic implications. The Scrum Guide puts it this way “For the Product Owner to succeed, the entire organization must respect his or her decisions….No one is allowed to tell the Development Team to work from a different set of requirements (other than those represented in the Product Backlog – AOC), and the Development Team isn’t allowed to act on what anyone else says”. Think about it. The Product Owner is the person who tells the Development Team what to do. It is through her management of the Product Backlog that she does this, in the main. The Product Owner spends a lot of time and effort working with the customers and other stakeholders to understand the relative value of the different requirements represented in the Product Backlog, and orders them accordingly. Of course, business value is not the only driver. Technical dependencies between different items – or stories if that is how the Product Backlog Items are represented – must be taken into account, too. Another factor to be considered is what the system will look like at the Sprint Review. A good Product Owner will always try to have the Team present a small and skinny version of the evolving system at the demo, and this might cause some lower value items to be promoted higher in the list than they might otherwise be. Other roles, including ones outside the Scrum Team such as managers and customers, will of course have input, but the decisions about ranking the Product Backlog Items are in the end those of the Product Owner and the Product Owner alone. The importance of is that at the Sprint Planning meeting, the Product Owner will agree with the Development Team on a Sprint Goal – the target value to be achieved by the end of the iteration – and the Development Team will “snap off” from the top of the Backlog the number of items it forecasts it can develop in the timebox that will meet that goal. A Combination of Traditional Roles So clearly the Product Owner is a role that not only has something of the traditional Product Manager about it, but also a bit of Project Manager stuff, too. She or he cannot tell the Development Team how to do their work, nor can the Product Owner dictate how much work the developers should do (only the Development Team itself can do this in Scrum), but every time she reorders the Product Backlog she is telling them what needs to be done, because it is the top-ordered items that will be worked on next. And non-one else, no-one but no-one, can tell the Development Team to do anything differently. Now add to this the fact that the Product Owner is acting as a proxy for the customer during the Sprint, making herself available to the rest of the Team as needed, and you can see that the role sits right at the centre of the communication pathways and collaborative actions that have to happen for the product to succeed. Maybe to say the Product Owner is the one wringable neck isn’t quite right. A better way of putting it might be that if any team or organization fails to grasp the importance of this role, if they don’t get it right, or if they make the wrong personalities Product Owners, then everyone’s neck is on the chopping block! CSPO Certification Revisited If certification is justified at all – and I believe it is – then certification of Product Owners is critical, not just for individuals who want to embellish their CVs, but more importantly, but for their employers whose organization’s future is, perhaps, being put on the line by their adopting Agile. One issue is that, like the CSM qualification, CSPO can only be gained by attending a certification course delivered by a Scrum Alliance Certified Scrum Trainer (CST). Except that the CST must themselves hold a CSPO certification – and only a minority of this relatively elite group are also CSPOs. It is hard to find appropriate courses. Fortunately, Learning Tree has teamed up with CSTs to provide exactly that service. Course 1814 Certified Scrum Product Owner is taking enrolments now. If you are a practising Product Owner who is not yet certified you should register for this 2-day course as soon as possible to get certified. If you are a Scrum Team member in another role, or are outside Scrum Teams but are impacted by their work in any way, then alert your Management to this opportunity to get your organisation’s Product Owners qualified. And don’t forget there are now nearly thirty Agile courses in the Learning Tree catalog to support the skills development of all your Agile professionals. This includes courses that provide CSM Certification, SAFe Agilist Certification, APMG’s Agile PM Practitioner Certification and prep you for PMI’s Agile Certified Practitioner (PMI-ACP) exam. We look forward to seeing you on course with us soon!