How did I become a Scrum trainer?

FeaturedHow did I become a Scrum trainer?

After an inspiring journey, I reached a milestone in my life; in July 2017, I became a Scrum.org Professional Scrum Trainer (PST). Why did I want to become a PST? How did I get there?

Why?

In 2011, I was a junior IT project manager in a multinational corporation. Starting a project required building a plan in order to reach a certain unique goal. To make planning easier, I ended up with splitting projects in 3-month horizons, each one leading to the delivery of something valuable for the user. I was told that experience was needed to make plans that could stand the test of time. Splitting projects in multiple shorter-duration efforts came with additional costs in administration and budget request cycles, but I did not care since I was able to provide project members with an environment in which they could achieve clear, shorter-term goals.

2012 was the year in which I discovered agile and Scrum. I started pioneering Scrum together with a couple of colleagues. Looking back, it was really immature and mechanical Scrum, but it provided lessons in team forming and capability building in order to be able to deliver value every two to three weeks. Working in these short cycles with a pre-funded initiative seemed to release people from the administration and budget request cycles, giving them time for creativity and a more relaxed atmosphere that enabled a team to form.

My first true Scrum experience came a year later when I was working as a Scrum Master in a self-organizing team. Cycle times dropped from at least nine months to being able to deploy every week. And quality improved dramatically with the build-in quality control and automation of testing, environment provisioning and deployment. But most importantly, teams were stable for way longer periods of time and it provided numerous lessons for me about team forming and dynamics. It was a team working together that enabled all the breakthroughs in speed and quality improvements.

Working as a Scrum Master in different environments and being able to teach and coach Scrum Masters in their role led to people taking initiative. Not only in their jobs, but in their lives. This truly energized and inspired me to take it up as a goal in life:

Helping people take ownership of their personal journeys

Scrum is something beautiful. It is something I experienced and I’d love for others to have those same positive experiences. When I learned about the possibility of becoming a PST, I immediately subjected myself to the feedback loop of the PST application process.

How?

I started co-training with collegues who were PST already and one acted as a mentor in my PST journey. From the co-training experience I knew that I wanted to become a PSM trainer. The first step was the simplest one from an activity perspective, but it was the hardest one from a mental perspective: writing my job application at Scrum.org. It just takes courage to draft a good letter and press the ‘Submit’ button.

Don’t let fear guide you and know that if you choose to enter the PST application process it is not a zero sum game. To me it felt like starting a Sprint in a series of multiple Sprints. I was able to create my Sprint Goals and to create my own plan in order to achieve that goal. And after a couple of Sprints, I got to that moment that I was proudly able to say ‘my product is finished’ and I was able to join the fantastic community of PSTs.

PST process

If you feel like joining this community, and you have a similar background, don’t hesitate, take your leap, start at https://www.scrum.org/become-professional-scrum-trainer/psm

Feel free to contact me if you want a mentor in this process.

 

Advertisement

What is agile?

What is agile?

I see people still struggling with the concept of agile. Struggling with what it actually is. I see people implementing it as if it is a process or procedure, resulting in mechanical, lifeless structures. So, what is agile?

Agile is not only a working process. Agile is broader than that, it is a definition that defines mindsets, behavior and organizational culture. You cannot implement it, since it defines something that cannot be created:

You don’t create a culture. Culture happens. It is the by-product of consistent behaviour. Real cultures are built over time. They are the result of action, reaction, and truth. They are nuanced, beautiful, and authentic. Real culture is patina.

J. Fried

According to Slack’s Engineering Chief of Staff Nolan Caudill, culture is

Culture – which we understand to mean the systems that dictate how employees relate to one another, the work to be done, and the customers (…)

You can become agile. You can not do agile. Doing agile is pretending. Resulting in the lifeless mechanical structures that I mentioned before. In order to become agile, we need to alter our context in such a way that characteristics and behaviors arise that are fundamental to agile.

We can alter context by:

  • setting expectations
  • recognizing, amplifying, and rewarding
  • demonstrating through the choices that we make, the questions that we ask
  • demonstrating through our own behavior
  • showing how decisions are made, and changing that if needed
  • deciding who to hire

And by doing so we become leaders in the service of the organization.

Bringing the right behavior to light and bringing agile to life was done at Pinterest as follows:

Table

“At Pinterest we bring agility to life at an organizational and individual level through a focus on velocity and flexibility. ‘Organizational velocity’ is about how we can create the conditions necessary to increase velocity. (…) We create the conditions for flexibility through strong shared values that help guide how employees approach and complete their work.”

Sources
J Fried source
Slack source
Pinterest source

 

What is a competent Scrum Master?

What is a competent Scrum Master?

In many classes, I get the question ‘What is a competent Scrum Master?’. It is also a question that I like to ponder in class to check on participants’ understanding of the Scrum Master role.

During enterprise transitions where Scrum is going to be used as the new way of developing complex products, I find it necessary to elaborately explain the Scrum Master role with the accountabilities and responsibilities that come with the role. One of the first things to do is to establish this role in order to help the organisation in starting to use Scrum. This is necessary information to have in order to look for Scrum Masters in the organisation, or even to set up vacancies to attract Scrum Masters to the organisation.

So, where do we start?

Other Scrum Trainers have written about Scrum Master maturity levels (Ron Eringa) and Scrum Master stances (Barry Overeem). I would like to elaborate on establishing something like a competence model for Scrum Masters.

First, I establish four levels of Scrum Mastery, heavily based on the work of Ron Eringa and my own observations of Scrum Master growth.

Scrum Administrator

The Scrum Administrator is not selected out of a pool of job applicants. And most of professional Scrum Masters that are self-employed do not fall in this category. So how do we get them? They are appointed within the organisation. They act as assistants to the team, performing some of the duties of a Scrum Master as a role next to his current role.

Facilitator

After some time, good Scrum Masters that originated from the Scrum Administrator level start to truly understand what ‘self-organizing’ teams entail. The Scrum Master is starting to gain facilitation experience, and is letting go of the command and control mode that is so apparent in Administrators. The Scrum Master now understands that upholding clear boundaries, making purpose clear, and providing for technical mastery to evolve, is the best way to get motivated Scrumteams.

Coach

The Scrum Master is moving into enabling continuous improvement. In previous levels it was more about pushing a change (Administrator) and focusing on inter-team dynamics, this level is more about looking further than the Scrumteam. The Coach is starting to, as the name suggests, coach people outside of the Scrumteam to continuously improve the environment of the Scrumteam with the aim of maximizing performance, quality, and value-based decision-making.

Servant Leader

Ultimately, in my opinion, a Scrum Master is on-stage. He acts as a Change Agent in the organisation, but is also able and willing to do this in other organisations. He is a frequent speaker at events, writes blogs, helps organisations and is an active participant in further developing Scrum.

More information

I have created an overview of characteristics, example behavior, and even a full-swing competence model for the four levels that I described above. If you would like to receive that information, contact me directly at LinkedIn.

 

Starting Scrum

One of the questions asked in my Professional Scrum Master trainings is “What are the steps to take when starting with Scrum?”. Well, those are actually quite simple in my opinion.

  1. Get a clear picture of what the organisation wants to achieve. Why go agile and Scrum?
  2. Define ‘product’. Sounds easy, but in reality it is quite hard to do. Tips: think from the perspective of the customer.
  3. Arrange for Scrum Masters. These people help in transforming your organisation into an organisation fit for the 21st century.
  4. Arrange for Product Owners for the products. General rule: one product has one Product Owner and one Product Backlog.
  5. Identify stakeholders of the Product Owner. Already set up workshops to help the Product Owner form a Product Vision and Product Backlog.
  6. Set up boundaries for the Development Teams. You should have:
    1. A clear organisation vision. Why do you exist?
    2. A product vision corresponding to every product.
    3. General rules concerning Development team size (3-9 people), diversity, kind of work required per product, etc
  7. Let Developers (mind you, we mean product developers, so not only IT guys!) self-organise into Development teams. It’s okay to form multiple Development teams that work on one product.
  8. Do Product Backlog refinement together as Scrumteam to have enough ‘ready’ work to start the Sprint.
  9. Schedule Scrum events.
  10. Start!

The concept of Incremental, Iterative Development is quite old

A class of students is always an interesting mix of people. People who, mostly, did not knew each other before class. And most of the time, something strikes people the most when talking about the background of Scrum and this thing called “agile”. The ones paying the most attention and who are already working in the field for some time start exclaiming: “What I hear now, is nothing new!”

Continue reading “The concept of Incremental, Iterative Development is quite old”

A refinement toolbox proposition

A refinement toolbox proposition

Last July the main theme of Scrum Day Europe was the celebration of 20 years of Scrum. We took a look at worldwide Scrum usage and agile adoption, and what to focus on in, what we called, the next iteration. We see that an agile way of working is being more and more adopted, but we also see many organizations stepping in pitfalls and we even see some dysfunctions. One of those dysfunctions is the inability of Development teams to deliver a releasable Product Increment every Sprint.

Continue reading “A refinement toolbox proposition”

Alignment

Alignment

It is Monday. I had quite a busy weekend so I am still halfway my sleep-cycle as I walk into the office of my client. It is busy, people are shouting, I see some small groups clustered together around their computer screens, making energetic gestured at what is displayed on it.

That weekend, they did a Release. And as many IT companies do nowadays, they release once every quarter. So it was a big release, big bang, lots of software, and one moment of truth. And it did not really work out. Fifty-six priority 1 incidents!

At the end of the week, after many retrospective meetings on the Release with developers, testers, analysts, IT management, architects, and security managers, I come to the conclusion that I need to structure their approach to line them up for Agile delivery. They already have Scrum teams, six of them, working in two-week Sprints, but they still apply a big-project-know-everything-upfront approach to software design and delivery. And Product Owners do not really feel the necessity to create a plan of their own, for their own team.

If you feel pain, go through it. Make the pain visible, ask for help, and solve it together. Do not sweep it under the carpet. This is what I see happening all the time, for instance by blurring the pain by applying tools and processes. For instance, in this Release process, we could have set up a central board, requiring ticked check boxes from all the teams for over 100 items before they are allowed to put anything in Production. Thereby making the problem invisible, most likely even delaying and amplifying the pain, but not solving it.

So step one was to visualize the pain.There are all kinds of issues and a lot of waste in this process, think about:

  • POs without a plan of their own
  • Sprints that contain waterfall blocks of work like “Functional Test x”
  • waste of talent by not letting the Scrum Masters take their role
  • steering on output which makes the teams blindly focus on pushing software
  • no transparency on who is doing what, creating chaos
  • no transparency on what is coming next with respect to planning

This client needed something that finds its origin in visual management, practiced by Lean manufacturers over the world. So we set out to visualize the pain. Together with the IT manager, I arranged for an empty wall of about 3×5 meters big. The place of the wall had to be right next to the desks of all the people who were working on the items that we were going to put on it.

 

Visueel planbord ed2.jpg

Two weeks later, another Monday, we are with the six Scrum Masters, the six POs and two delegates of IT management in front of the newly created 3×5 meter whiteboard. We start with horizontally setting out the timeline on the board. We settle with the first four columns ‘Current Sprint’, ‘Next Sprint’, ‘Next Sprint + 1’ and ‘Next Sprint + 2’.
The next columns are further in time, so we settle on three additional quarter columns, at that time labeled ‘Q2 2016, ‘Q3 2016’, and ‘Q4 2016’.
The last columns get the header ‘Ever’, and we add a ‘Done’ column to be able to show Done stuff.
To complete the board we split it in vertical swimming lanes that each represents a Scrum development team, and add a separate lane for Architecture and Security, since the people working there perform work in the process but are not part of the Scrum teams. We also add a separate swimming lane for Projects, since there are some projects that might or might not impact the Scrum teams, and we want to visualize that.

So, how does this work? We now have a giant planning board. Sticky notes or, preferably, magnetic index cards, are used to show a Product Backlog Item. Color coding is in this case used to indicate the phases of Refinement (New, In Refinement, Refined). Markers on the cards are used to indicate whether PBIs are part of a bigger Epic together, and colored magnets are used to indicate dependencies.

Next, we made some working agreements and introduced two new meetings. First and foremost, since we have top of the line facilitators in the form of Scrum Masters, we choose to let them facilitate the new meetings, so in the meetings the Scrum Masters are always present. Next, the two meetings were planned: a weekly standup meeting at the board with the POs and the chief project manager that coordinates all projects to let them update each other on progress and identify dependencies between PBIs and between PBIs and Security or Architecture. This is just a half hour standup meeting.
The second meeting is a session of two hours that is scheduled bi-weekly. In this session not only the POs and the chief project manager are present, but stakeholders are invited as well, and the CEO is there. This session is mainly used to identify and solve dependencies, and make decisions on ordering items based on value estimates.

Now that we have used this approach for a couple of weeks, I can write about the benefits:

  • There is an operational layer in this approach. It is now clearly visible who is doing what and when. The PO is now planning on capacity of the team which helps in visualizing a realistic planning. If a new item comes in, the PO can say “No” based on capacity of his team, and start the discussion of what needs to move and why, or put the item in a future Sprint or quarter to be picked up.
  • Because it is now visible when stuff and what stuff is coming, architects and security managers can now decide in which team Refinement sessions they want or need to be.
  • By letting the sessions be facilitated by Scrum Masters, you not only get good sessions, but they learn and grow. And because of the type of stakeholders that adhere these sessions, they can identify growth opportunities with respect to an Agile way of working.
  • Dependencies between teams can now easily be identified, which is input for those teams to start up Scrum of Scrums in order to align their work.
  • Dependencies between projects and teams can easily be identified and correctly ordered.
  • Attendees can now have a meaningful discussion on priority of work, taking capacity into account.
  • By making use of the first columns, it becomes immediately clear when a team has not enough ready work for the coming three Sprints. In that case, those boxes are empty immediately triggering a conversation.
  • Decisions affecting planning of other items become immediately visible. The PO for instance says ‘We cannot do that together with this, so choose’, and in face to face conversation with the CEO and stakeholders, they can decide on the best course of action.
  • There is a small step towards celebrating successes, since Done items are visible.
  • Items need to be small. Every item should ideally deliver value, which is not the case. So it triggers discussion on how to slice big Epics in such a way that they do deliver value.
  • If a team is not able to deliver value every Sprint, it is immediately visible triggering a discussion on that end.

The next step is now to incorporate value estimation and ordering on value in these sessions. When the value is put on the index cards of each PBI, it makes value steering possible.

The result is that POs take ownership of their planning and a lot of useful discussion is triggered on how to move from big-bang to Sprint releases every two weeks. And secondly, it triggers a lot of discussion on how to do the most valuable stuff first and how to know what delivers value and what not. And that is exactly where I wanted them to go!

 

 

How to create High Performing Teams, blog #3/3

How to create High Performing Teams, blog #3/3

Now that we know the needs that need to be fulfilled to get High Performing Teams (HPTs) from my previous blog post, let’s take a look at what Scrum Masters or Agile Coaches can do.

Vision

A clear, inspiring and engaging direction or purpose set by the organization was mentioned as a success factor for HPTs. So where can we find parts of a clear vision trickle down to team level?

First and foremost, make sure that development team formation is based on the vision of the organization.This generally holds that development teams need to be formed around specific customer-focused domains (feature teams) instead of based on functional domains or based on IT components (component teams). This way, a team can focus on meeting customer-focused metrics, like number of new clients thanks to the release of a certain new feature. When it is hard for a development team to come up with these kind of metrics it is a good idea to clarify the vision for the team. One way to do this is to redefine the boundaries for the development team together with management and the Product Owner (PO). But please leave the decision on who is in the development team up to the development team.

The PO must also have a clear and inspiring product vision. And he must be able to explain how this vision ties into the vision and goals of the broader organization. Letting the PO practice an elevator pitch, explaining the product vision, is one way to help him. Another way is to help him set up performance indicators (e.g. feature usage counts) for his product.

If the company or the business domain is lacking a clear strategic vision at all, it might be a good idea to help management formulate a clear vision for at least the domain that the scrum team is working in. Make sure the team has a higher purpose than just creating some IT product.

Shared goal

What makes a great team is when the team norms promote a culture of psychological safety where the sum will be greater than its parts – J. Marcus

Explain to the scrum team that there is value in being a team. Not because they are together to finish a certain product, but because they have value to the organization as a unit of people working together to create happy customers.

Derived from this understanding, help the scrum team to create a team vision, like a definition of awesome, and help them distill team values from that vision. When they have a vision and shared their values, they can set out to become a true team. As inspiration for the specific team values, the Scrum values can be used. There are Focus, Openness, Courage, Commitment, and Respect.

Together with the PO, the team is now able to align team vision and team values with product vision and product goals. This is when the how and the what come together.

Feedback on collective work product

Oftentimes we find management focused on the output of development teams. As a Scrum Master it is important to teach them that it is not important to create a lot of output unless it continuously helps achieving excellent outcomes. Working software is the primary measure of progress towards the intended outcome. It is therefore important to define the intended outcome and to continuously check whether that outcome is achieved by what the development team is doing, instead of continuously checking what the output is.

Agile is all about a deep understanding that we cannot fully know what the future will hold, and being honest about that. So teach the PO to work with Minimum Valuable Products and to continuously gather feedback to adjust to a continuously changing environment.

Steer towards a situation in which the team is in a continuous feedback loop with customers, end-users, and stakeholders so they can track their progress and see the results of their collective work product. And the other way around, make sure that the customers, end-users and stakeholders are in continuous conversation with the scrum team to help them steer the product in achieving the intended outcome. One way is to make sure they are in the Sprint Reviews.

Teach the scrum team to use real-world, actual, up-to-date information to track progress towards intended outcome.

Safe environment

The organization should provide for a safe environment. The organization should ideally value mistakes, as long as the scrum team learns from those mistakes. Celebrating learning opportunities and holding inter-company retrospectives on mistakes is a way to express the value the organization sees in making mistakes.

At Prowareness we have made a specific point on the agenda of our monthly Company Scrum meeting. Everybody is able to share the biggest mistake he made, after which we reflect on the learning opportunity. The biggest failure is rewarded with a parking spot all for yourself (which is an actual valuable thing for us) for the duration of a whole month.

Teach the development team the value of having healthy conflicts, and also how to handle conflicts in a constructive way. This helps in achieving a psychologically safe environment for the team.

Having a catalyst in the development team can help in accelerating the growth path of the team towards having a healthy, psychologically safe environment. The catalyst is a person who is willing and able to help the coach.

During the Retrospectives help the scrum team in not only reflecting on the way they build content, but also on how they build a team. Let them express how they feel, let them share developments in their personal life, and plan fun team activities like going to a theme park together. Teach the team how to build effective working relationships.

Individual contribution

Team members should understand that they need to work together to achieve their goals. It should be clear to every development team member what he contributes and what the other members contribute. It should also be clear to the team if and which skills, knowledge or competencies they lack to reach their goals. And they should be empowered to act on that. In the team, every team member should have a place where he can contribute to the team in the best way possible.

Help the development team in achieving this by doing workshops like Journeylines and Market of Skills, and by creating a skill matrix.

Autonomy

The organization should understand that engagement emerges from self-autonomy. In recognition of this, they should delegate micromanagement tasks to the scrum team. The organization should be able to create a compelling vision that enables the team to think about best solutions on how to reach that vision.

The development team is only micromanaged by the development team itself, and every team member is only micromanaged by himself. As a Scrum Master it is important to teach stakeholders and managers on which forms of interaction with the team are effective and which are not.

Celebrate success

Celebrating success is imperative in maintaining high morale. Too often, organizations do not pay attention to achievements and this leads to demotivation and gives a message of not having important goals.

As a Scrum Master it is important to look for opportunities of celebration. Just take a small moment of thanks for small things. Just a come together with the team, having some drinks and maybe sharing a self-made cake. And make sure the PO and stakeholders are informed. For bigger stuff, organize bigger events. Did multiple teams achieve something together, they celebrate together!

Fun

It is important for the team to have a good start. During their first forming phase, it is important to pay attention to getting to know each other personally otherwise it will remain a group of people that are together for the sole purpose of creating a certain product, which has a finite period.

Apart from this good start, it is important to have shared fun experiences to get to know each other better. This is especially true for teams that are normally not physically together. As a Scrum Master, make sure this happens.

Mastery

Passionate development team members might still need encouragement to hone their skills. In organizations, time pressure on delivery (output) might logically have resulted in output-focused team members that are under time pressure. Alleviating the pressure of output steering from those team members is a task for coaches and Scrum Masters.

By moving towards outcome steering, it is also important to teach the organization the importance of improving the software development capabilities. The organization should see the value of spending time on technical mastery, and the development team should be able to make this value clear. One way is to bring the scrum team together in technical-focused Refinement and giving them time to add technical items to the Product Backlog.

What you could do on a bigger scale, is to organize hackathons with multiple development teams, but make sure that the results of the hackathon are used in subsequent prototypes or even products. Nothing is so demotivating as spending 24 hours non-stop on a collective work product that will be tossed out the window when the day is over.

Mini-company

One way to cover a lot of topics that I mentioned above is to turn the scrum teams into mini-companies. Start a Retrospective with the notion that from next Sprint on, the team is a mini-company within the organization.  Ignite this feeling by visually using the mini-company-in-a-company metaphor.

Let the scrum team come up with a company name, and a virtual physical product that they are going to build. The PO is the CEO, with the vision for the product. The development team has the vision of how to achieve that product. This metaphor can be used to foster the team building process.

The development team should do their own marketing and sales. Foster communication with the outside world, they should care for relationships outside of the team. Let them start a blog post in a company newsletter, let them gather information from stakeholders during Sprint Reviews.

Before you know it, you have a HPT and it becomes necessary to think about how to slow them down to prevent burnouts.

How to create High Performing Teams, blog #2/3

How to create High Performing Teams, blog #2/3

The needs that High Performing Teams have

In my previous blogpost, I wrote about the characteristics of High Performing Teams. To come to these characteristics I did a small literature review. For this part, I will establish the needs that need to be filled in in order to enable teams to become high performing.

Remember, I am still talking about a team of knowledge workers developing and maintaining a software product.

Here are the needs:

  • A clear, inspiring, and engaging vision, direction and/or purpose, set by the organization or organizational context of the team. It must be clear to the team how their work and their collective work product contributes to the broader vision, direction, and/or purpose of the organization.
    An inspiring purpose motive not only helps in motivating the team, as is explained by Daniel Pink in his work Drive, it also helps in giving the team direction by means of a pull mechanism. Pushing KPIs generally does not help.
  • A shared team goal that the team itself created. For example, a shared idea of what an ideal team looks like. And, derived from the team goal, shared team values help giving team members direction.
    A shared vision of what an ideal team looks like also helps the team in coming up with improvement initiatives on their own. Moreover, each team member needs a place in the team where they can add the most value. A shared team goal and shared team values help team members think about how they can contribute.
  • Metrics that show a team’s progress towards their team goal and towards the vision, direction and/or purpose of the organization.
    This helps them in establishing a way to measure progress and a way to measure success or failure of the collective work product. Think about number of defects found for IT teams that want to deliver quality, or number of new customers attracted due to the release of a collective work product for an organization that needs to grow its client base.
  •  A shared belief that it is safe to take risks and share a range of ideas without the fear of being humiliated. This model of teamwork is called Psychological safety.
  • An interesting find by Google’s Project Aristotle is that team composition does not play a role in team performance, but psychological safety is of utmost importance. And J. Marcus wrote “What makes a great team is when the team norms promote a culture of psychological safety where the sum will be greater than its parts.”

  • Frequent feedback on their collective work product from engaged stakeholders and/or customers and/or end-users.
    Not having engaged stakeholders is like a pilot continuously flying an empty airliner; it is a demotivator. Conversation with customers and end-users also helps in determining the success of the collective work product. If a team has engaged stakeholders and the organization is able to provide for a safe environment in the context of psychological safety, it enables the team to search for support for their ideas and sharing ideas becomes fun.
  • Time to invest in becoming better. This can be done by giving the team time to do stuff that they want. An example of this is Google’s 20% free time that was given to employees from 2004 to 2012. In Scrum, improvement initiatives that arise from the Retrospective can be estimated and put on the Product Backlog and taken into subsequent sprints.
  • Of course the first line of the Agile manifesto is Individuals and interaction over processes and tools, but sometimes you need tools to enable the interaction. For distributed teams, make sure they have communication tools.

  • Autonomy. Please stop micromanaging the teams and the people in the teams. It is ineffective and demotivating. One of the Agile principles is The best architecture, requirements and designs emerge from self-organizing teams. Moving from Human Resources to People Operations; it helps to delegate more and more responsibility to the team, making it truly self-organizing.
  • Celebrate success. Too often I find teams working really hard on a collective work product, only to jump on the next one without taking time to reflect on their accomplishments.

These are the needs that I managed to extract from my little research project. Please let me know what you think.

In my next blogpost I will continue and derive fields of attention and actions to take for Agile managers and Agile coaches. Please stay tuned!

How to create High Performing Teams, blog 1/3

How to create High Performing Teams, blog 1/3

How to create high performing teams

This is the first blog post in a mini-series of three in which I explore actions that Agile coaches or Agile managers can take to create high performing teams. I focus on high performing teams that consist of knowledge workers creating a software product.

It looks like we are in the middle of a social revolution equal to the scale of the Industrial Revolution of the 18th and 19th century. We’re seeing more and more self-organizing teams that make their own decisions within boundaries set by organizational direction, strategy and/or vision. The benefits seem clear, teams that take ownership simply perform better. But what is exactly the mechanism behind this? Is setting a certain corporate direction and giving freedom to self-organizing teams enough to end up with high performing teams?

To answer that question, I embarked on a small journey of research. In that journey, I explored:

  1. the characteristics of high performing teams;
  2. the needs of high performing teams, and;
  3. actions for Agile coaches or managers in Agile environments to achieve high performance in teams.

The characteristics of high performing teams

When embarking on the journey of identifying actionable items for Agile coaches or managers in Agile environments to create high performing teams, I needed a starting point. So, what are high performing teams and what are the characteristics of a high performing team?

A high performing team is first and foremost a team. The characteristics of a team, as opposed to a working group, can be formulated on the following eight topics, according to a Harvard Business Review article of July 2005 by Katzenbach and Smith:

Table blogpost 1 team vs working group
Comparison of characteristics of a working group vs. a team

 

After looking at multiple sources (source list included at bottom of blogpost), I identified the following characteristics of high performing teams:

  • The team has a specific team purpose that the team itself created
  • The team takes individual and mutual accountability. Each team member takes responsibility for the result obtained by the team as a whole.
  • The team works result-oriented, it is not the individual work product, but the collective work product that counts.
  • The team has open-ended discussion and decision making. There is real working together. The team vibrates with inter-team communication. Team members give each other constructive feedback on the way they work together and on behavior. The team members are not afraid of conflicts.
  • All team members have a place where they can add the most value. Each team member aligns personal goals with the team goal.
  • Leadership takes place within the team; there are shared leadership roles. There is autonomy on task and on group-level.
  • The team makes extensive use of metrics, and takes fact-based decisions. Effectiveness is directly measured by assessing the collective work product.
  • The team itself comes up with improvement initiatives continuously. The team is willing to invest to become better.
  • The team itself achieves buy-in for implementation of innovation or maintenance work items. Team members share their ideas actively and the team cares for relationships outside of the team.
  • Team members are prepared to work together. There are healthy attitudes within the team. There are established rules for their way of working and the team has frequent, fun, team building activities.
  • The team manages its performance. Team members are able to identify the weakest link of the team and act on it, whether it be some process that does not work, or a team member who does not perform. The team is able to solve inter-team conflicts.
  • The team has a will to be technically excellent.
  • As times get tough, working together intensifies. Every team member has a strong loyalty towards the team.

Now that it is clear to what my understanding is of a high performing team, I will extract the needs of a high performing team from these characteristics in the next blogpost.

Sources

  • Van Amelsvoort en Scholtes’ Team Model
  • Tuckman 5 Phases of Team Forming
  • J. Maxwell 17 Indisputable Laws of Teamwork
  • The American Society for Quality’s International Team Excellence Criteria
  • J. Richard Hackman Leading Teams
  • B. Overeem Characteristics of a great development team
  • P. Lencioni Five dysfunctions of a team
  • J.R. Katzenbach & D.K. Smith The Discipline of Teams, HBR July-August 2005
  • NY Times, February 28, 2016 What Google learned from its quest to build the perfect team