Introduction
Decades ago Toyota coined a phrase that represents its culture “Great people make great products” [Ohno13]. This represents a human-centered approach focused in developing people’s talents so they can build awesome products using their creativity and motivation.
Toyota among other things was the first automaker that didn’t thought that the key in its production process were the processes, tools, raw materials or capital; instead they trusted and empowered its people so they themselves discover how to do their work better and better.
The Toyota Way has been tried to be imitated in many countries and industries with different levels of success, but there is simplify one ingredient that can’t not be copied and that it’s the Toyota people.
Similarly Scrum is emphatic about saying that the Scrum Team must be self-organized, empowered, motivated, with individuals that are not right at all times and where is safe to experiment so true learning can occur constantly.
In a way a Scrum Master wouldn’t be doing anything that a coach in Toyota has not done before, the substantial difference though is that software is not directly comparable to manufacturing. There is however a principle that can be extrapolated from Toyota: leaders as teachers and coaches that serve the teams.
The Self-Organization Panacea
Self-organization is not good for everybody because not everybody likes the idea of not having a manager that tells what to do at all times. In fact, I’ve encountered in some teams that they feel intimidate by the responsibility of making their decisions and I’ve have even observed a team asking back for a manager to direct them.
Something that helps to mitigate the initial fear to self-organization is clarifying that not because the team will self-organize will lack leadership, is just that leadership will be granted by the team to and individual based on her/his knowledge, charisma and respect. This is a deviation from the tradicional hierarchical structure that dictates team members who they must follow.
In a self-organized team it’s very common to see that team members tend to listen and follow a fellow team member that carries knowledge, learned something interesting and wants to teach it, or came up with an innovative solution to a complicated problem.
Consequently can be said that leaders still exist in a self-organized team but their leadership rotates and is recognized based on their own merits.
The Challenge of Constantly Self-Organize
When the initial fear to self-organization has been overcome the next challenge presents: how to keep the team self-organized. It’s very human to get back to old bad habits as soon as we encounter problems with the new approach, even if we know that old good known is bad. I’ve seen cases in which upper managements gets impatient and decides to revert to command-and-control leaving people confused and even killing morale.
Something that helps to keep self-organization alive is to have a highly motivated team. From this perspective if motivation will positively impact in self-organization we can infer that we need to star looking at techniques and approaches that can help us to keep the team motivated.
Daniel Pink [Pink11] presents a model based in three pilar that according to him if cultivated successfully can really keep individuals motivated; these pillars are:
- Autonomy
- Mastery
- Purpose
I have experimentally applied this model in software development teams and I can say that its works and not only helps to motivate team members but also enables a true learning environment.
Myths About Self-Organizing Teams
Self-organized teams has been associated with many myths that of course are not factual. The following is a list of the more common ones that I’ve heard/observed over the years:
| MYTH | REALITY |
| Self-organizing teams don’t know how to do a retrospective. | This problems is not exclusive from self-organizing teams, that is why teams need a designated retrospective facilitator (Scrum Master) |
| Estimations from self-organizing teams are the worst | There is no solid statistical information that proves or disproves this claim. Further, there is no direct correlation between self-organization and estimates precision |
| Self-organizing teams accumulate more technical debt because there is no single responsible for code quality | Self-organization in combination with mastery, pair programming, test-first development and other practices can improve code quality and knowledge inside the team |
| In a self-organized team when someone quits all hers/his knowledge is gone | The risk of loosing knowledge will be always present and is even worst with siloed knowledge. Self-organization tends to break those silos of knowledge because it allows better and more horizontal communication |
| Self-organized teams are dangerous for organizations because they can evolve into unions and call on strikes | If workers conditions are not fair then there will be always the chance that workers self-organize in unions but this has nothing to do with self-organized Scrum Teams. Organizations should not use this as an excuse for not trying Scrum, instead they should look at this as a symptom of other dysfunctions. |
The Scrum Master as a coach needs to help people in organizations to start questioning these myths and maybe discovering some others that they have in their own context. By questions myths people start thinking why they believe in something that is not factual and that opens the door for other positive changes.
Team Dynamics
Let’s start by differentiating a collections of individual from a team; a team has synergy and creative power that is far superior to a group’s of individuals that recently met.
Teams that jelled and act like a cohesive unit share some characteristics such as:
- Leaders are from the team and leadership rotates on-demand
- The team is well equipped to deal with internal conflict
- All team members can voice their opinions without fear to be bullied or criticized
- Working agreements are known and followed by all team members
- Team members share goals and motivations
- Team members held each other accountable for performance and commitment
- Long lived team with the same team members for years
- All team members are full-timers
And if we talk more specifically about and Agile Team we can say that it should have key attributes like:
- Working agreements that are constantly inspected and adapted by the team itself
- Awareness of the limitations, competencies, capabilities and fears of each team member
- Effective and efficient collaboration among team members
From Homogenous to Diverse Teams
Typically when new teams are form upper management tend to make them homogenous en terms age, gender, work and academic background, system of beliefs, etc.
Against common belief homogenous teams tend to lack self criticism and creative thinking, they experiment more instability and conflict and ultimate disband faster than heterogeneous teams [Pfeffer06].
A more promising alternative is to form team which diversity in mind. Gender diversity is a great starting point toward heterogenous teams.
Starting by gender diversity other options can be considered next:
gender —> age —> ethnicity —> academic background —> etc.
A word of warning, heterogenous teams needs to be co-located so they can jell [Larman10]. Empirically I can state that heterogenous globally distributed teams consume a lot of time in trying to communicate effectively and that eventually affects the product.
The Obsession to Measure Team’s Performance
One of the most effective ways that I know to kill colaboración and transparency in a team is just by offering individual incentives, because those incentives are normally focused in increasing individual performance at the cost of team’s performance.
Performance can not be easily measure with just one metric and any metric that upper management decides to use can be gamed and it’s even worse when bonuses were offered.
On the other hand, things like work stability and a fun working environment tend to foster collaboration and camaraderie among team members. Work stability is fundamental because the type of work that a team member does will change over time, and because of cross training and self-organization team members will be require to do more than type of work.
Working agreements that promotes respect, learning and constant collaboration have an overall positivo impact on the team’s performance.
Shared goals and benefits with the organization have also a positive influence in performance. By shared benefits I meant to say that team members feel really rewarded when they build a product that is successful in the market, but then the organization should also considered sharing the gains from the product with the team.
Building New Teams
Teams are not form over night, in fact there are studies that identified several stages that a team would need to pass before being consider a real team.
If we talk about forming a new team from scratch the firs step is of course recruiting. What I’ve seen working better for recruiting developers is that during the interview the candidate actually writes code.
Some variations might include pair programming with he candidate or coding katas. The key point is not to loose sight of what we’re after with this interviews and the is seeing how the candidate can solve problems by coding solutions.
It’s feasible to build a productive team with excellent developers but is far more costly and sometimes even impossible to build such a team with developers that don’t know their own craft [McBreen01].
Definition of Done Created by the Team
One of the characteristics of a self-organized team is that they have the responsibility to create, together with the Product Owner, a Definition of Done that can be used to qualify all Product Backlog Items as truly done.
There is sometimes confusion around the Definition of Done being static or dynamic, in actuality it is dynamic and will be perfected Sprint after Sprint. Actually a recurring topic during the retrospective is that teams feel that their Definition of Done needs to keep evolving.
The Definition of Done should be constantly changing as a reflection of the continuous improvement (kaizen) culture of the team that aims to have a Definition of Done that is good enough to allow the team to take Product Backlog Items all the way to production in the shorter time possible.
Making the connection with Toyota, the Definition of Done is like a check list that a car has to pass so it can be considered shippable and sellable.
Continuing with this analogy, we could see each individual car as a product formed by thousands of parts where each individual part needs to meet the Definition of Done.
There are couple of ways that I use for representing the Definition of Done:
- A flipchart with all the steps of the Definition of Done listed on it
- A matrix where rows are for Product Backlog Items and columns are for the criterion on the Definition of Done. This matrix can allow to see which PBI has meet what criterion or vice versa.
The Value of Engineering Practices
A very simplified way to assess the capability of a team is by looking at how much its team members know about eXtreme Programming and how they use its practices.
For the many practices described in eXtreme Programming [Beck04] there is no prescribed order in which a team should start adopting them. However, I consider tome of them essential:
- Continuous Integration at smaller and smaller intervals of time in the main line [Kim16]
Following the XP mantra: Divide —> Conquer —> Integrate
- Collective Code Ownership allowed by Feature Teams que knows the feature code in all layers and components. Notice that is not only about having cross functional teams but also cross component teams [Larman10]
- Refactoring constantly improving the code internals without disrupting the output [Kerievsky04]. It’s easier to refactor when you have test built that can be execute and validate that the output has not changed. From a Lean perspective refactoring could be understood as something connected to kaizen ultimately reflected in the code
- Simple Design that means keeping the systems design within the limits of comprehension without adding extra architectonical complexity [Fowler02]
- Test Driven Development which out of all XP practices is the more difficult to internalize and master because it requieres a lot of study and discipline; furthermore, this requires that developers think of code in a way they are not naturally used to do (this often time generates resistance) starting by thinking and programming the test and working in very short cycles [Beck02]
The practices described above must be applied correctly and with discipline so the team can be able to produce clean code that can be put into production in very short periods of time, this can enable immediate feedback from users and stakeholders than can really see working software. The former is aligned with Lean thinking that says that the more that we incentivize the flow of parts the more that we are reducing the throughput time.
If we think in scaling and now we have multiple teams (more than eight teams and each team with seven to nine developers) it’s even more important that all teams follow XP practices like TDD, continuous integration and simple design so we can avoid the pitfall of ending up with a huge code base that nobody understands.
Conclusion
We live in an era where all simple software that could have been possible created by a solely developer has been already written, thus is important to acknowledge that software now and in the future will come from teams that need to discover how to collaborate more effectively.
Because software development requires a high level of creativity and that is tightly connected to motivation and commitment, it’s extremely relevant that the Scrum Master learn about techniques, tools and paradigms that can help her/him to better serve the team.
A final recommendation, discovering techniques, tools and paradigms shouldn’t be a path only the Scrum Master walks, on the contrary should be the whole team that embarks in this journey of learning.
Bibliography
Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill
Pink11 Pink D., 2011. Drive: The Surprising Truth About What Motivates Us, Riverhead Books
Pfeffer06 Pfeffer J., Sutton R., 2006. Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management, Harvard Business Review Press
Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional
McBreen01 McBreeen P., 2001. Software Craftsmanship: The New Imperative, Addison-Wesley Professional
Beck04 Beck K., Andres C., 2004. Extreme Programming Explained: Embrace Change, Addison-Wesley; 2nd edition
Kim16 Kim G., Debois P., Willis J., Humble J., 2016. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, IT Revolution Press
Kerievsky04 Kerievsky J., 2004. Refactoring to Patterns, Addison-Wesley Professional
Fowler02 Fowler M., 2002. Patterns of Enterprise Application Architecture, Addison-Wesley Professional
Beck02 Beck K., 2002. Test Driven Development: By Example, Addison-Wesley Professional
