If you worked in large organizations you have probably heard about the term "dependencies". I am convinced that dependencies need to be eliminated, not managed. With a help of system diagrams in this article, I will uncover the main reasons why Scrum Teams suffer from dependencies, how they impact organizational agility, and what the fundamental solutions to this issue are.
How dependences inhibit Teams progress
The more dependencies, the less chances the feature will be done by the end of the Sprint. Thus, the more time it takes for the feature on average to go from Product Backlog queue to the market (cycle time). As a result, agility is reduced because the organization is unable to deliver potential value to the market quickly. This causes organizational stress.
A typical management response to organizational stress is "divide and conquer". For instance, if there is a problem with the quality, let's create a separate department “quality control” with set of its own KPIs. Creating new functions, units, component teams and coordination roles, managers strengthen the fragmentation of the organization. More fragmentation leads to even more dependencies.
High average cycle time makes the organization less agile. But Scrum Teams should not have any dependencies!
Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
Scrum Guide 2017
Why dependencies exist
From my long experience working with large organizations I see a few reasons why the dependences thrive:
Imperfect organizational design based on component teams ( "bus team", "analytics team", "Android Team", “integration team”). It causes intensive fragmentation.
Incomplete cross-functionality (lack of one or more skills).
Unreasonable complicated architectural design ( "there are 256 systems in our organization)", which inhibits creation of cross-component and cross-functional Scrum Teams.
How to get rid of dependences
The dependencies issue could be solved in two ways: with quick fixes or fundamental long-term solutions.
The quick fix is to visualize and manage the dependencies. E.g. creating additional coordination roles or using specific techniques ("ropes on the boards"). Yes, it somehow helps to survive and continue the movement. You become an artist of the visualization and dependency management. Your work looks similar to this:
The fundamental solution is to eliminate the fundamental issues completely by:
making the complicated architecture simpler, reducing the number of components
changing organizational design and forming cross-component cross-functional Scrum Teams (Feature Teams)
In this case the board for the scaled Scrum could look much better (no dependencies):
Feature Teams do not need the ropes because there are no dependencies or they are trivial.
Let’s get back to the system diagramming. On one hand, we have a cycle explaining the rise of dependencies, on the other hand it is a quick fix of the problem, then a fundamental solution cycle and the final cycle of forming a culture of managing dependencies when time passes.
The bad news is that a strong culture of “managing dependencies” will hinder the implementation of the fundamental solutions.
The more dependencies the less agile organization becomes.
Dependencies thrive because of the unnecessarily complex architecture, lack of skills, and suboptimal organizational design (component teams).
Creating additional roles and using dependencies management practices do not eliminate the fundamental issues.
Fundamental solutions are simplification of the architecture, Feature Teams and, training people.
Do you manage dependences or want to eliminate them?
So Ralph Jocham and I wrote a book called The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. It took well over a year of many late nights in hotel rooms and early mornings on weekends, but we got it done. It was a lot of work, but very rewarding. Getting your thoughts down on paper is a great way to reflect on and sort out the complicated aspects of our industry. This is especially true when collaborating with a partner, like Ralph. The three Vs of Product Ownership is an example of this and is a major theme of our book — and the topic of this post.
A little background first:
Ralph and I are both stewards of the Scrum.org Professional Scrum Product Owner course. Over the years, we have worked with Ken Schwaber and the rest of the Scrum.org trainer community to redesign and modernize it. Ralph and I have taught the class hundreds of times to thousands of students and thought it’d be a good idea to write a book as an ideal companion to the course.
A theme we consistently see amongst our students and the industry as a whole is that the Product Owner role is rarely understood where many end up as requirements secretaries (scribes) or requirements traffickers (proxies), waiting for their next orders.
Our book aims to fill that gap by bringing empowerment and entrepreneurship to the role. In other words, Product Owners should be initiating innovation and functionality, not just receiving it.
When we thought about what a professional Product Owner needs to do in order to achieve this, we came up with the three Vs — Vision, Value, and Validation:
Vision: the best thing a Product Owner can do to truly take ownership and inspire others is to establish and communicate a clear vision for the Product. Why are we building it? Whose lives will be improved by it?
Value: the best thing a Product Owner can do to move away from a project mindset (time, budget, scope) to more of a product mindset (value to stakeholders) is to define and communicate what success looks like. Is it customer satisfaction? Operating costs? Registrations? How will we measure it? How do we know when the value received no longer outweighs the costs?
Validation: the best way a Product Owner can actively manage risk is to shorten the feedback loop by validating frequently with internal experts and, even better, with the external marketplace. A professional Product Owner knows that the only way to move the needle on any value measurement is to release to customers. Until then, everything is just a hypothesis.
A professional Product Owner embraces empiricism as a way to address the complexity and risk of building something unknown. The three Vs fit perfectly with the three pillars of empiricism:
Vision creates Transparency.
Defining Value provides you with something to Inspect.
Validation causes Adaptation.
Using this simple language and approach to Product Ownership has helped me immensely when working with clients and I sincerely hope it does for you too.
For a deeper dive into this topic, our book dedicates a whole chapter to each of the three Vs along with practical techniques for putting them in place.
We would love to hear your thoughts on the three Vs and our book
Throughout my career I have helped many leaders adapt their style to one that better supports teams reach a high-performing state. Across a wide range of different industries the patterns of high-performing teams, and how leaders help shape them, have some striking consistencies.
I can clearly recall one of the highest performing teams I ever worked in. It was during my first career as a chef. The Head Chef quit, and the owner of The Ruptured Duck (yes, that was the pizzeria name - it was destroyed in the 2011 Christchurch earthquake) asked me if I would take over. I was only 23 years old and felt totally daunted, but figured I had nothing to lose so gave it a go.
Throughout the following two years, I somehow helped shape an incredible team of people who felt they could literally achieve anything. The lines between work and fun blurred. We were all “in the zone” – that incredible space where everything around you seems to fade into the distance and you are utterly present. We were somehow there nearly 100% of the time.
The team could handle massive, unpredictable waves of customers and work under incredibly intense pressure for prolonged periods of time, often during extremely trying conditions. Yet we consistently delivered an incredible experience and regularly had customers commenting how obvious it was that we all loved what we were doing. I would regularly have staff coming to work early, working unpaid, just because they liked being there.
How on earth did we achieve this?
Reflecting back, I can see some clear patterns:
Goal We had a clear objective – to provide the most awesome casual dining experience in Christchurch in a friendly, fun environment.
Leadership: at 23 years old, with less than a year of practical chef experience under my belt, I was not in a position to tell others what to do. I had never done this before, so how could I? All I could do was lead by example. I worked hard and expected others to also. We were largely self-managing.
Culture: we created a culture of extreme teamwork by always having each other’s backs. If the chefs got a lull in: work, we helped the front of house staff, and vice versa. This was never questioned. It was how we rolled. When introducing new staff, we’d focus on the team culture and would only introduce one or two new people at a time. It created trust and courage as a core group value.
Continual improvement: we would hold what I would now call a retrospective every night. We’d have a couple of beers and talk through the how the evening had gone, what worked, what hadn’t and what we could do better.
Transparency the entire operation, kitchen, dishes and all, could be viewed by the public the entire time. Nothing was hidden.
Rapid experimentation – we would constantly try new ideas as “specials”, gaining valuable customer feedback as we went.
Fun – we had a lot of fun together as group.
The result was a team that could turn over an 80-seat restaurant 6 or more times in a single evening without a glitch. That's close to 500 people and we could do this 7 days a week if needed.
Ways of Working
Fast forward to my current world: helping knowledge workers achieve similar outcomes. Radically is helping organisations transform the way they work, applying new ways of working, autonomous teams, a high-performance culture and a relentless focus on customer value.
While the setting is different, the themes are the same. High-performing teams have those same characteristics: goals, appropriate leadership, culture, continual improvement, rapid experimentation, transparency, trust, courage and fun.
A key aspect of this is helping organisations unlearn last centuries management practices.
Ivy league business schools and the big management consulting firms pushed these practices for decades. “Good management” was based on planning, hierarchy and control. The mindset was that the top layers of the organisation would come up with the right strategy, and then the troops would execute. The focus was on coming up with the best strategy (which of course you would need help with) and on execution excellence, namely conformance to plan (i.e. control).
However, with business increasingly operating in a world of unknown unknowns, this approach increases risk, reduces responsiveness and ultimately results in the organisation becoming fragile. To adapt, we have to acknowledge the approach we have used for the last 30 years doesn't work in all contexts, and then explore alternative approaches.
Instead, at Radically we help leaders focus on establishing a clear, compelling vision and then re-thinking how their organisations deliver on this, largely through the exact same characteristics as my Ruptured Duck team. It isn’t about Agile. It is about the mindset, the environment and the culture required for high performance.
Autonomous teams are self-managing. Self-management requires two critical ingredients:
An absence of traditional management.
A light set of constraints. Constraints help balance autonomy with accountability. Constraints might be an iteration, a Sprint Review, a social contract or a facilitated meeting.
An absence of management is important as people cannot self-manage when they have a manager telling them what to do.
For many managers, creating an absence of management is truly frightening. How can you be accountable when the teams manage themselves? How does a manager approach this situation? Do they just let go of everything and hope for the best? We are seeing a lot of people struggle with this.
The art of it is choosing how much space to leave by actively stepping out, in order to allow others space to step in. You can’t just walk away, leaving a gaping hole, and expect everyone to magically self-manage. Yet if you don’t leave enough space, you will prevent them from self-managing.
Young Steve Jobs on how to hire, manage, and lead people - MUST WATCH - YouTube
We ask leaders to move their focus away from telling others how to do the work, to the following three areas (leveraging David Marquet's experiences captaining a nuclear submarine with no knowledge of how it worked):
Clarity – what do you seek? What difference does it make and to who? Why is this important? What does success look like?
Competence – does the team/individual have the competence to deal with this situation (or at least the growth mind-set to learn what is required). Does the structure support them in their level of competence? What help might they need?
Control – delegate control to the people doing the work, once the platform of Clarity and Competence is in place.
This is precisely what I unwittingly established all those years ago as a chef at The Ruptured Duck!
Leadership and Culture
I believe one of the most critical factors for a high performing culture is leadership. The agile community has pushed servant leadership as the answer, but I don’t believe this is correct. I believe situation-appropriate leadership is the right answer.
To help organisations discover what this means, we prefer a discovery-based approach.
We use the Cynefin framework to first establish context. Collectively, we work through what it feels like to work in each of the four domains, what is different about each, and which approaches might work best for each domain. We then work through what sort of culture and leadership style would be required to support this way of working in each domain. Then, we review how we all currently think and lead compared to this.
The results can be quite profound.
These are some of my experiences helping create high-performing teams. What are yours? Have you ever worked in a high-performing team? What was it like? How did it compare to my pizzeria team? What was the predominant leadership style?
When delivering a Professional Scrum Master training or helping clients creating awesome products with Scrum, some people ask me how to adapt (downgrade) Scrum to make it work in their organizations.
My answer is always the same: Scrum will change your organization! Let me explain why it cannot be the contrary.
1 –Hierarchies have been proven to be useful for repetitive work. Collective Genius is required to solve complex problems and deliver value; it’s obtainedthroughintelligent networks of self-organizing and cross-functional teams, linked together by values and accountabilities.
STOP controlling people, start controlling value delivered!
2 – Middle Managers, or other management positions can greatly contribute to the change. All these people have the great opportunity to transition to one of the three roles that Scrum offers: Product Owner for those who like product development, Development Team for those more “technical” (development, marketing, sales, security, quality, etc.) and finally Scrum Master for those who like to coach, teach and help people understand and enact the Scrum Framework as described in the Scrum Guide.
3 – Spending time in figuring out how to reduce risks, predict future outcomes, how to control people isn’t creating value. Instead of making plans, start creating your first increment, inspect and adapt to improve predictability and reduce risks. Scrum is all about useful action… to deliver value.
Scrum is a simple framework to deliver complex products. It helps organizations in their transformation, not the opposite.
Changing Scrum wont help you in: quickly reacting to market changes, reducing your time to market, increasing your company efficiency, having healthier and happier employees and ultimately gain market shares!
We all have a role to play, forget about hierarchies, and think how you can contribute in delivering value to your customers through your products.
As the co-creator of Scrum, Ken Schwaber, wrote on his blog: “Scrum is like chess. You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played or not.”
How do you work as a team to maximize the benefits of Scrum and agility?
Recall that the Scrum Team defines their own process within the boundaries of the Scrum framework. This includes their practices, tools, interactions. This includes how they fulfill the accountabilities of their Scrum roles and how they utilize the artifacts and events.
How does your team determine what to build? How does your team build it?
From the product management practices to the engineering and quality practices. From how your team communicates and collaborates to how they effectively use and grow team knowledge, skills, and capabilities. And much more.
There is a lot going on when it comes to delivering complex products in an uncertain and constantly changing world. So let’s try to simplify and create some focus on tangible actions.
5 Steps to Improve Team Process
Step 1: Increase the Depth and Breadth of Transparency
In order to improve team process, there must be transparency to the process. Scrum provides a minimal level of empiricism if you just “follow the rules.”
But much more is possible when teams truly embrace empiricism. Most importantly, teams must understand how their process is affecting their outcomes.
Here are some questions to explore with your team:
How do we make decisions about what to build in the product? How are those decisions transparent and to whom?
How do we make decisions about how to build the product? How are those decisions transparent and to whom?
How well do we understand team progress towards incremental goals at any given moment? (This could be goals at a daily level, a Sprint level, or longer periods of time.)
For every action we perform, what is the valuable outcome of that action? What could make it more valuable?
How do we build quality into the product? What is the current level of quality in the product? What’s the trend?
What factors have led to successful outcomes? What factors have led to not-so-successful outcomes?
What assumptions are we making? How are we validating those assumptions?
Step 2: Apply Lean Principles Simplified
There are 7 lean software development principles. While they are all useful to understand, I’m all about simplifying. My colleague Simon Reindl introduced me to what he calls Lean Principles Simplified.
These three principles are interrelated. Maximizing flow means we move items (i.e. value) through the process as quickly as possible, without risk to quality and customer satisfaction. Removing waste helps us do this. Waste is anything not adding value to our customer.
Now assess your process through the lens of the Lean Principles Simplified. Seek out signs of waste and opportunities to maximize the flow of value. Some common examples of sources of waste:
Building things customers don’t want/ don’t use
Task switching and distractions
Partially done work
Unnecessary or ineffective processes and documentation
Step 3: Expect Change and Seek Better (i.e. Inspect and Adapt)
The practices and tools a team uses will be influenced by the type of product, the technology platform of the product, the environment in which the product is used, who uses the product and how they use it, regulatory and legal conditions, market trends, changing needs of the business, etc.
So... a lot of stuff. And much of that stuff changes over time. Therefore, it is essential that teams remain vigilant in inspecting and adapting what they are doing, why they are doing it, how they are doing it, and the benefits they are getting from doing it.
New practices and tools are continuously being created and shared in product development communities around the world, so it is important to stay connected and continuously learn.
In fact, teams often need to modify and invent new practices and tools to meet their unique needs. There is no such thing as a best practice when it comes to complex work. The best practice is the practice that works for your team right now in your current situation, and what that will look like a month from now is likely to be different because your situation will be different.
Be part of advancing your field or industry.
Step 4: Focus on Delivering a “Done” Increment
Take steps 1-3 and apply them in the context of delivering a “Done” Increment.
If you are not delivering a “Done” Increment at least by the end of every Sprint, this is where you must focus your attention.
How can you improve your process to get to “Done?”
Well, there are many ways to improve. However, there are some universal things to consider when it comes to "Done." So Simon Reindl and I have narrowed it down to 7 specific areas of your process to explore, applying steps 1-3. These are the 7 areas we use to help team’s start their journey of discovery and improvement:
Small, quick wins are good. You can get solid benefits from easy process improvements. You can even get some benefits from local optimization. Yet there will come a time when you need to move beyond the low hanging fruit. And you will need to seek system optimization over local optimization (which may mean looking beyond your current team/ product constructs).
I will share an example. I worked with a Scrum Team that had no test automation for a large and very complex product. Implementing test automation is a lot of work and has significant costs. Test automation came up as an idea for improvement multiple times over many months, however, they chose to focus on other opportunities to improve quality and reduce waste in their process. And they did improve quality and effectiveness. However, the gains of each improvement were smaller and smaller.
One day they realized it was time to move beyond the low hanging fruit to seek greater benefits. They needed to take on the test automation challenge. And because of their small, quick wins, they had grown a stronger team identity and were ready to expand their range.
Scrum Teams own their process. I cannot emphasize this enough. And when people feel ownership in something, they want to invest in making it better.
Improving team process is an ongoing effort. It never stops.
Does your team consistently build a “Done” Increment by the end of every Sprint? In what ways does your team demonstrate they feel ownership in their process?
What aspects of your team process are not so transparent and perhaps being ignored? What steps do you want to put more energy into to support improving team process?
Time to read: 7 minutes (11 if you watch the video's also)
Often I hear people say that Scrum does not take care of risk: there is no risk log, risk is not on the agenda of the Sprint Review or Retrospective as a standard agenda-item. The Development Teams need to be accountable for the quality of the product and how it's made. That's a risk right there! If there is not one person accountable for quality, being on time, within budget, building the right thing... How is risk managed in Scrum?
I'll break it to you right away. Scrum is all about risk management. Ken Schwaber talks a little bit about it in this short video:
Controlling Risk - YouTube
Risk is personal
First let's think about what risk actually means. According to the Oxford English Dictionary:
(Exposure to) the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility.
That's a very broad definition. Reading it like this makes it also subject to personal interpretation. And I think we all look at risk a little bit different. Risk has also a lot to do with our own personal involvement. If someone I don't know will cross two buildings on just a rope without safety net, that's very risky for that person, but not for me.
That also relates to the work that we do. For some the same project or product outcome can hold far more risk for one than for others in the same project that we do.
Different types of risks
Within work related environments, we usually talk about:
Financial risk - can we pay for it?
Business risk - will it be used? Does it solve the problem?
Technical risk - can it be made/build? (often in relation with finance, when a product becomes possible to build, but too expensive).
Controlling risk with Scrum
Scrum is a very good way of controlling risk in a number of ways. I'll elaborate on these different types of risk in the context of using Scrum.
When we are going to build a new product or change an existing one, we would like to know the costs of or change or innovation. Unfortunately, the complexity of the development of these products causes for great uncertainty and thus makes it difficult to estimate what the costs of a project will be upfront.
This often is a difficult subject for many, because the way we run projects (not using Scrum) is often first establishing scope, finances and resources (what we now call people). With Scrum, some say we skip that phase, but actually, we don't. We build it up empirically, because that's the best way to control the future in complex environments.
However, we are not giving anybody a blank cheque. We define clear roles and responsibilities.
We establish the role of the Product Owner. He or she is in control of the budget and planning of the product.
We establish a self-organizing Development Team of cross-functional professionals who can get the job done, from start to finish.
We ask a Scrum Master to facilitate this Scrum Team to encourage empirical process control and coaches this team to be a little bit better every day.
Then we ask the team how long it will take them to validate the first wishes into a concrete result. The shorter the better, because that saves money, that might otherwise be wasted on building the wrong thing.
Often I advise sponsors of teams like this in an organization to fund just a couple of Sprints at first and look at the results after every Sprint. Have a conversation with the Product Owner and Development Team about the results and the return on investment. This means the costs are pretty predictable. It's the costs of the team + out of pocket expenses for these Sprints.
The sooner the first release goes out to the users, the sooner the financial risk decreases!
Business risk is the risk of people (users) not actually using your product, thus not solving the problem that the product needed to fix in the first place. This happens all the time. And not because our teams are dumb or stubborn, but mostly because a customer really knows what he needs the moment he can actually use the product. Everything before that is useful (Product Backlog refinement, requirements engineering, talking to users, doing surveys etc.) but does not take away the risk of people not actually using your product. Look at this short clip to illustrate:
Eric Ries-Building a Product Nobody Wants - YouTube
Within Scrum, the Product Owner's role is to keep in close contact with stakeholders and the Development Team, so the right thing will be build. Reviewing the releasable increment together with those stakeholders every Sprint and (to speak from Eric Ries perspective) pivot or persevere from there.
The Product Owner is not a business stakeholder, it's not an analyst. It's the business representative in the team to manage and monitor that business risk, to create the best possible outcome.
When I started using Scrum, I remember this was one of the key elements that I liked so much: there is no more "us and them", we work collectively to solve business problems.
Technical risk actually can be sub-divided into two categories:
Can it be build with a good ROI?
Can we maintain the product during and afterwards?
These are important questions to keep asking yourself along the product development effort. Everyday, decisions need to be made by the Development Team if the effort that is put into a certain feature is worth the value to the Product Owner. So communication is key here.
And in second part: being able to maintain the product. Always keep a scout's view on technical issues. What I mean by that is: whenever you encounter bad technical quality, make it (at least a little bit) better.
Now, again, "done" comes into play here. Within Scrum, defining what is meant by "done" is important to be in control of technical risk. This can enhance the quality and maintainability of the overall product.
Technical skills, tools and improvements can be adopted in a good definition of done. The right testing, validation, documentation etc. can reduce the technical risk.
To conclude: the best way to reduce risk in general is: build potentially releasable increments for users.
I remember someone on LinkedIn mention:
The day we started to deliver, people stopt asking about our velocity.
I started out this article with the definition of risk and how subjective it can be. The Scrum values are extremely important to make sure that overall risk is transparant and dealt with at the right time, by the right person, with proportional effort.
Take a couple of minutes to look at these values in respect to risk. What's the effect of these values on risk?
Complex environments are full of risks. You can fear them, analyze them, calculate them. Or you could build the product, inspect and adapt and deliver a done increment each Sprint.
The Times News were on a journey to re-platform their system. While working diligently behind feature flags, using elements of Scrum, it wasn’t clear to the stakeholders the value being delivered and how well the teams were progressing towards their end goal.
After reviewing the portfolio, the programme leadership team (PLT) recognised they needed to strike a balance between moving towards the proposed technical platforming and delivering valuable features for the business and readers.
Rather than dictate to the teams the PLT agreed they wanted to develop a culture of ownership. The hypothesis was: if the teams have some stake in defining the work they will be much more motivated to work on it.
The PLT commissioned a team comprising of the principal engineers and product owners to develop a set of feature proposals that would roughly fit within a quarter and satisfy the aims of the portfolio. The output of these sessions were vision cards and the skill set required to deliver such as iOS, Android, etc.
The temptation existed to take the skills list and feature proposals and redistribute the staff across each. It was so great that an initial model of assignment was created but quickly discarded. The PLT were eager to continue with the principles they had started with and wanted to see how far it could go. If they allowed all the staff to choose their own work assignment would it lead to increased ownership?
Origins of self organising teams
It was recognised that a characteristic of the most innovative organisations was the concept of self organising teams.
“A project team takes on a self-organising character as it is driven to a state of “zero information”— where prior knowledge does not apply. Ambiguity and fluctuation abound in this state. Left to stew, the process begins to create its own dynamic order. The project team begins to operate like a start-up company—it takes initiatives and risks, and develops an independent agenda. At some point, the team begins to create its own concept.
A group possesses a self-organising capability when it exhibits three conditions: autonomy, self- transcendence, and cross-fertilisation.” (Nonaka & Tekeuchi, 1996)
Self organisation in agile teams
This has become the cornerstone of agile teams, especially teams following the Scrum framework, which were an attempt at moving away from Dilbert-esq environments to ones that actively supported engineers.
“Development teams are structured and empowered by the organisation to organise and manage their own work. The resulting synergy optimises the development team’s overall efficiency and effectiveness.
Development teams have the following characteristics:
They are self-organising. No one (not even the scrum master) tells the development team how to turn product backlog into increments of potentially releasable functionality.” (Sutherland & Schwaber, 2017)
Implementing the self organised re-org
To help with the facilitation of the event we organised a first round selection with the product owners, scrum masters and principal engineers. By having these people allocated to the teams for the main event it was felt it would help with the sales pitch and general organisation. These people then identified “vacancies”, essentially the number of developers and associated skills needed to deliver against the vision.
They were also tasked with creating “Posters” capturing the vision, goals, benefits and vacancies for their team to be used at the main event.
Some business constraints were identified; the architecture team needed to remain as is (we had very specialised people in that team who we couldn’t afford to lose); a mixture of senior through junior skills and experience needed to be spread across each team and PLT had final say if we got to a deadlock. We also documented rules of engagement to help ensure the event ran smoothly. We outlined a clear agenda with a set of rules to help the event run smoothly.
We planned to hold the event in a large room with the posters for each team on the walls with each team’s PO to present a sales pitch to the programme about why people should pick their team. The team were then to pick their name card up and find a vacancy in one of the teams and stick their name card to the vacancy.
Kicking off the event was the head of product, who gave a brief keynote describing the need to focus on getting product to market and several key metrics of success. This was followed by a short overview of the event process and the constraints.
Each product owner presented their sales pitch and then the self-organising began. For the majority of people, it was very easy to pick their team and most found a new home within a couple of minutes. Indeed, many people picked as we might have predicted. 3 or 4 proved problematic, which required some difficult facilitation after team members were not able to resolve themselves. Ultimately the PLT had to make the final decision.
There were a number of people who for whatever reason could not be there in person for the event which was primarily planned to be facilitated face to face. Next time we would allow for more preparation for remote staff to understand how they participate.
Continually sharing the vision for the product and the aims of the business is essential as this seems to atrophy in people’s minds over time.
Ensure the skills and minimum number of people required for each team is crystal clear and doesn’t change through the session.
Have a trial run with the scrum masters to help them understand the facilitation challenges specifically around resolving conflicting allocations. Also, a single master of ceremonies would have been advantageous.
This is the second in a series of posts exploring Scrum Mastery. In our first post, we introduced the 4 dimensions of Scrum Mastery. Scrum requires self-organizing, cross-functional, collaborative teams. The success of Scrum hinges on the strength of a team. In this post, we will explore the Team Identity dimension.
5 Steps to Grow a Strong Team Identity
#1 - Appreciate the Individual
Teams are made of people. And it is important to not lose sight of the wonderfully unique, complex people that make up a team, even as we strive to let go of individual ego and focus on team goals and outcomes. After all, engaged and fulfilled people are going to be more creative and productive.
First, recognize that everyone has a unique personality.Personality is the building blocks of who you are, and it is driven by your preferences. This includes communication styles, learning styles, being a lark or night owl, conflict responses, introversion or extroversion, and many more contextual and specific traits. While it is impossible to satisfy all individual preferences on a team, it is important to understand and appreciate the individual preferences, so the group can negotiate and optimize for a given situation. And also appreciate when people are stepping outside their comfort zone for the benefit of the whole.
Second, respect that people are motivated intrinsically. You don’t need to motivate people. Instead, you need to create an environment that encourages intrinsic motivation. People want to choose how they do their work. They want the ability to grow their capabilities and become great at something. And they want to do work that has greater meaning and impact.
A key skill for all individuals to appreciate themselves and each other is emotional intelligence. This involves both understanding and managing your own emotions and being able to recognize and influence the emotions of others. People are a complex mix of thoughts and emotions influenced by the stories we tell ourselves and our perception of reality. These are all jumbled together and constantly changing. Emotional intelligence helps you make sense of all this, so that you can choose how to respond to situations based on the outcomes you seek.
Now that we know how individuals find intrinsic motivation, are impacted by their personality preferences, and how they leverage emotional intelligence in their interactions with others, lets connect this to the team.
#2 - Establish Team Purpose, Team Values, and Team Vision
Why do we exist? (Purpose)
What is important to us? (Values)
What do we want? (Vision)
These three questions guide a team on its journey towards becoming a high performing, collaborative team. This is how you leverage the understanding and appreciation of the individuals to unify around a common purpose, establish shared values that guide you, and create a clear vision for the future state you want to create.
This type of clarity enables effective self-organization and taps into intrinsic motivation.
Establishing team identity is not a one-time team building activity. These are three questions you will continue to clarify and refine. You will use these questions as a team to assess how things are going, decide on next steps, and check that you are still on the path to where you want to go as a team. Over time, individuals on the team will begin to embody these questions and use them intuitively.
#3 - Build a Foundation of Trust
Everything hinges on a foundation of trust. Trust is a willingness to be vulnerable with each other. Some trust is required to show up as your authentic self and let people learn who you are and what motivates you (see #1). Some trust is required to have meaningful conversations about values, purpose, and vision. And trust grows over time as individuals continue to be vulnerable with each other in deeper ways and as individuals take great care with the vulnerability of their team members.
I consider trust the roots of team identity. As the roots grow, the team identity becomes stronger. The team is more resilient and can survive and recover quicker from storms. But it takes time and continued nourishment for the roots to grow.
When there is trust within a team, it is then possible to engage in productive conflict. People are willing to challenge each other. People are willing to challenge assumptions and share their wild and crazy (and possibly brilliant) ideas. They are willing to take smart risks.
#4 - Navigate the Conflict Spectrum
Conflict driven from a desire to “win" or be “right” is NOT productive. Not speaking up because you don’t want to upset others or be perceived in a certain way is also NOT productive.
Productive conflict happens when people are willing to share ideas and perspectives and also challenge each other’s ideas and perspectives, all in the interest of reaching the best possible outcome. This enables creativity and innovation.
You listen to others. Like, really listen. Don’t interrupt. Don’t roll your eyes. Don't start formulating your counterpoints in your head while they are talking. Outcome —> Others feel heard.
You respect other perspectives, beliefs, and ideas. Because you respect them, you can challenge them… in the spirit of finding the best solution for the given situation. Outcome —> Others feel heard and invited to consider alternatives.
You can disagree and commit. Because you feel heard and respected. Because you listened and kept an open mind to alternatives. Outcome —> You can support the direction of the team.
When there is productive conflict within a team, it is then possible to have commitment to team decisions.
#5 - Create Commitment and Accountability to the Team
Commitment shows up in several ways within a team, from the big picture to the smaller decisions that get made daily. Ultimately, this is about alignment between how you are engaging everyday and your team purpose, team values, and team vision (see #2).
One way to support commitment is by facilitating consensus. By consensus, I mean that people can disagree and commit (see #3). Ensure key decisions are made clear at the end of team discussions and that everyone is willing to support them.
Team members must also be willing to hold each other accountable for those team commitments. It can take courage to enter into conflict (see #4), but if you’ve laid the ground work, there will be enough trust and respect and appreciation of the individuals to make conflict productive. When team members are willing to hold each other accountable, they enable higher standards because everyone is striving for the best possible outcomes. This could show up as higher quality, better solutions, greater learning, and more innovation. And ultimately, this enables the team to stay focused on their shared goals and team results.
Growing a strong team identity is an ongoing process. You will likely need to put more energy and time into team identity early in a team’s life, as well as when they confront significant change and challenges. The 5 steps above build on each other, yet they can all be experienced in the same moments.
You can often assess how strong a team is and which of these steps needs focus by how successfully a team fails. Do they learn and grow from it? Do team members enter into productive conflict, holding each other accountable while owning their individual missteps?
Servant-leaders are comfortable with failure, knowing it is a necessary part of innovation, learning, and growth.
Where is your team struggling with their identity? What steps do you want to put more energy into for supporting growth?
The University of Applied Sciences at Albstadt-Sigmaringen (HSAlbSig) is respected for its well-balanced curriculum. However, even the best curriculum can benefit from outside sources and experts. For that reason, the HSAlbSig has been offering seminars and excursions with the Association of German Engineers (VDI) – a well-respected body in the German industry.
The HSAlbSig is realizing that the concepts of agile cannot be ignored in this accelerating world and asked me to provide Professional Scrum Master trainings for the last five years. I turned agile in early 2000 and have been working as an agile change agent at various international blue-chip companies. Since 2010, I have been providing training with Scrum.org in Europe and was personally trained by Ken Schwaber.
The above mentioned intensive training augments the emerging agile material and have led to agile implementations not only in group exercises but also large-scale research projects.After seeing the success of agile, the offered seminars have been extended to include other new agile minded approaches like Design Thinking and UX. HSAlbSig is a great example how academy and industry can benefit from each other and create a stronger, more resilient work-force for the upcoming challenges in today’s world.
Starting as a professional in a non-agile project I was quite unhappy with the existing processes. After having attended the Scrum.org Professional Scrum Master Training with Ralph Jocham at HSAlbSig I couldn’t wait to implement it at my company. Fast forward – our Scrum Teams have grown to over 10 members in China, Poland, USA and Germany. Scrum has become the foundation for our collaboration and product development.
–Marco Stroppel, HSAlbSig
The full-fledged Scrum.org training has seen constant growth and now has a waiting list of students, even from non-engineering departments as well as from other universities throughout Germany.
Nowadays, it seems like every second company is trying to be agile. Thus, information about agile management strategies are inflationary on the internet. However, a lot of these articles and posts are superficial or even incorrect. Having had access to the deep knowledge and experience of Ralph Jocham is worth his weight in gold. I worked with Scrum before, still this training brought my understanding and performance to a completely new level. It solidified my existing knowledge and removed many misconceptions.
You might remember my posts on "Professional Scrum with Kanban - Don't just limit WIP - optimise it! (posts 1 and 2 of 3)".
I used Mike Burrows' Featureban (https://www.agendashift.com/featureban) and Andy Carmichael's additional design, with some tuning. "Daily", team members flipped coins. Heads or Tails, heads was a good day, tails not so good, and people learned to benefit from one of the rules for tails that one could move an item from selected into build. On a given day a PBI could move into selected and build with heads or tails, and then with two heads, could move through Build and Test into Done. In this case, we know that each PBI takes two to three days if there is no waiting. We seemed to get reliable with 2 day cycle time towards the end and it seemed pointless to continue as it was obvious from that point we would stay consistent as long as we did not change policies.
In most of the Featureban simulations in the last two years or so, I added Toyota Kata as the retrospective technique from the 2nd retrospective onwards, inspecting the Kanban statistical trends. I moved on from old official Toyota Kata to a solar system metaphorical equivalent, as it was easier to explain. Why the 2nd retrospective onwards, because in the first retrospective, more than one explicit policy changes usually, and Toyota Kata is about which one biggest obstacle to the target condition will we tackle next, based on reading these charts.
More details on Toyota Improvement & Coaching Kata can be found at http://www-personal.umich.edu/~mrother/Homepage.html. I personally like this video demonstration at https://www.youtube.com/watch?v=5pp8JMD-pWQ&t=0s, thinking about how I can apply it in my context.
Mars - almost impossible perfection vision 5 years + away, the Moon a challenge but doable in 1-3 years, in orbit - doable in 3-6 months target condition but still a stretch
I borrowed the expression "almost impossible perfection vision" from Bas Vodde. It's a disarming phrase. For me, that is getting to Mars, only attainable 5+years away, ok it's impossible for me:).
Toyota Kata my way :)
It's easy for people to brainstorm what "Mars" is for the product. For us, it was average arrival rate=average delivery rate (balanced system with great flow), an average delivery rate for 3 to 4 Product Backlog Items (PBIs) per day and world-beating performance in terms of money value delivered of 10m of your preferred currency. A team in Cincinnati recently broke the record, probably because they were smart but also because they had the advantage of almost two days for a Professional Scrum with Kanban course beforehand ( I know this because my 1st PSK class in Cork got very close (see https://www.scrum.org/courses/professional-scrum-with-kanban-training for the brochure and https://www.scrum.org/classes?type=133&scrumorg_geocoder_postal_state=1 for listed classes).
"The moon" is attainable in 1-3 years and should be a challenge but doable. It's usually a subset of the almost impossible perfection vision. For us, it was not world-beating value (world matching 7.65m would do and throughput average would be 2 per day or higher) but average arrival rate=average delivery rate.
"Getting into orbit" is the 3-6 month target condition that is a stretch but doable. And we ask what is it like on mother Earth right now, that is, what is the actual condition right now. This feels more realistic. So now we have catered for the realists, optimists and dreamers :).
Here is the official version from Mike Rother:
That means we can ask what are the obstacles to the attainment of the target condition, and ask the key question, what is the biggest obstacle right now. Finally, we can refer to the official Toyota Kata cards:
Toyota Kata works! Give it a go. Start with retrospectives and move to daily, twice daily. It's ok for the vision to change. Life changes, business changes, get over it :). Just don't end up playing whack a-mole:).
Here is the old-fashioned version from a previous simulation when we baked Toyota Kata into our retrospectives (2nd retro onwards as Kata is one experiment at a time), plus the Improvement Board tracking al the obstacles we burnt, all out learnings, and next steps:
Toyota Kata Improvement Board from my time before the Kanban Guide for Scrum