Blog

Introduction

Scrum Mastery doesn’t come from repeating the same practices over and over again and thinking always the same way, instead it comes from doubting your own knowledge and keep learning.

Even if it’s true that constant practice is a path to mastery it’s not the mechanical and repetitive practice that will make a great Scrum Master; the opposite is true though, without practice of any kind there is no way one becomes a great Scrum Master.

Paradoxically only practice without reflection can produce that concepts initially learned deviate from the original form and mutate into something else completely deviated from Scrum.

In order to avoid this deviation from the original Scrum intend a Scrum Master can do two things: actively participate in a community of pairs and keep learning by reading good books.

¿Why are you a Scrum Master?

Asking me this questions over the years I’ve found different answers:

• I needed the job
• For the prestige 
• I’ve been ordered to take the role
• I was sent to a course and took the rol the day after
• By accident 
• Because it was a trendy role
• To be a leader

After answering that question the next questions will require more reflection and analysis:  “do I want to stay in this role?” and base on the answer to that question comes this other question, “do I want to grow in the role?”

Another important question that a Scrum Master should ask to herself/himself is if Scrum values are present and alive in her/his personal life. Preaching Scrum values to the team but not practicing them could produce a fragmentation of the beingness in the Scrum Master.

If as a Scrum Master I talk about values but don’t practice them myself that would be perceived by the team that will question my authenticity and leadership.

Talking about leadership now, in Scrum we don’t favor imposed leaders from above but leaders that emerge from the team and people decide to follow because they want to. This type of leadership is not exclusive from Scrum and there are good examples of organizations that already implement it, organizations like Whole Food, W. L. Gore & Associates, and  Google [Hamel07]. 

The Scrum Master Dealing with Conflict

El Conflict is not an exclusive thing for Scrum Teams or organizations that decided to adopt Scrum. Conflict is in the very nature of human interactions, in all type of interactions that can range from personal to organizational [Kaner07].

Notwithstanding the above, as Scrum Master you need to be prepared to deal with conflicts that can be very destructive and fracture relationships in the team. Generally speaking, conflicts can present characteristics like:

• Emotionality, that means that someone or several in the team yell, make gestures, hit the table and communicate aggressively
• Tone of voice, could be the case that no one is yelling but there is a lot of sarcasm and subtle critique in the communication. It’s worth to mention that is possible to hurt each other’s feelings without yelling or using bad words
• Lack of interest in solving the conflict, worn out relationships present this characteristic,  everybody got used to the conflict and it doesn’t bother them anymore

Once conflict has been perceived, the Scrum Master needs to analyze the causes and what could be possible done to solve it. Taking empowerment into account is not advisable that the Scrum Master deals with the conflict by yelling at people and order them what to do. 

Often times in helpful that the Scrum Master present to the team and the people involved in the conflict what possible reactions they might have, for instance:

• Neglect that the conflict exist by saying things like “here we always yell to each other, is all business but never personal and we’re even friends”  
• Concede  always in order to defuse conflict, conceding could also be symptom of indifference like people saying “do whatever that I’ll do just my part”
• Overwhelme  others using all arguments to always win discussions
• Withdraw from conflict by simply cutting the discussion or by not talking

Even if there is silver bullet way to deal with conflict, the more we learn and study about conflict the better prepared we’ll be to deal with it.

Servant Leadership

There are many types of leadership approaches and the Scrum Master needs to be prepared to adopt that one that is best for each situation. Of all these leadership styles maybe the more difficult to master is the servant leadership because it requires not only conceptually understanding it but also mastering your own ego [Sinek17].

Mastering your hers/his ego is fundamental  if a leader thinks in serving others and help them grow. It also implies acknowledging that the leader no longer grows in the organization hierarchy by instead she/he is more interested in growing internally as a human being.

Even though there is no single metric for gauging how good or bad a servant leader is, there some attributes:

• Think in the others first, and put them before the leader’s self interest or like Sinek [Sinek17] said “let other eat first in an act of generosity and respect” 
• Communicate effectively leaving behind least effective ways to communicate like sarcasm or double meaning; learning how to communicate it’s a journey itself that requires practice and guidance
• Be a systemic thinker that not only considers here and now but sees beyond and anticipates the effects and implications that important decisions will have on people

Similarly a Scrum Master aspires to be a servant leader for both the team and the organization at large; organizations with this type of leaders tend to have deepen and lasting transformations.

Servant leadership again is no silver bullet, instead is just one more valuable tool for unleashing people’s creative power in an organizations that really encourages learning and experimentation.

Like Hamel [Hamel07] stated the future of organizations is uncertain and the more that its employees can learn and experiment the more chances organizations will have to arrive there, wherever the next great product will be.

Conclusions

The Scrum Master learning and growing path never really ends because like Ohno [Ohno13] said is about being a “lifelong student”.

Scrum is a light weight and barely sufficient framework but at the same time invites to walk a path, like a “do” in Japanese martial arts is not about the destination but also about every step that you walk on the path. 

Bibliography

Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press

Kaner07 Kaner S., 2007. Facilitators Guide to Participatory Decision-Making, Jossey-Bass; 2nd edition

Sinek17 Sinek S., 2017. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t, Portfolio; Reprint, Revised edition

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Introduction

Traditionally the  Scrum Master has been described as an impediment remover but this can be exhausting, frustrating and not really something the exploits hers/his full potential. Furthermore, depending on a Scrum Master to remove impediments doesn’t create a culture of self organization inside a team, quite the opposite creates dependency from a critical resource.

Interesting case studies about self organized teams came from unexpected sources like the crew of a nuclear submarine. David Marquet [Marquet13] tells the story of how empowering the crew of a submarine that he was expected to command unlocked submariners true potential and take them to unheard levels of excellence.

In his story Marquet came to the realization that he was not qualified to give orders because he didn’t have enough knowledge about his command, for that reason he had to take the leap of faith and give decision power to his crew. This case study documents the potential of self organization and empowered teams in a completely new domain. 

Inspiring stories like that might inspire Scrum Masters and leaders so they can  start thinking in reinventing themselves as influencers and educators for upper management; like in Marquet’s story upper management involvement is key for changing an organization to Agile.

Organizational Change is Possible

It is possible to change towards flat hierarchy organizations, where also exist empowerment and self organization, without sacrificing profits. As Laloux [Laoux14] documented on his book such organizations exist and they’ve been in business for decades and are still profitable.

In his classical management book Hamel [Hamel07] visionary identified several characteristics that management will need to have in the future if it want to stay relevant, for starters management will have to abandon all dogmas inspired in industrial revolution practices and gravitate towards people oriented paradigms. 

Hamel presents postulates like: “without managers, but with many leaders” that might sound revolutionary and anarchic but in reality promotes the culture of cultivating leaders that like to stay close to the gemba, so they can better understand the work and consequently better support continuous improvement efforts.

The Scrum Master role is not just be one of those leaders but also be the champion and upper management coach that explore how to change management. 

It is important to mention that the sponsor or detractor of organizational change is always the head of an organization, and that is way we should start trying to influence upper management  [Ballé14].

Scaling Scrum

There are several approaches for scaling Scrum, among others: Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), Scrum at Scale and Enterprise Scrum.

My personal preference is for LeSS because of two reasons: one, LeSS was developed by its creators working in real life products with large teams in different countries, and two, LeSS maintains the simplicity of Scrum.

LeSS is Scrum plus a few additions, but at the same time incorporates influences from ally disciplines, lessons experimentally learn and solid engineering practices [Larman08].

The following represent LeSS in a nutshell: 

LeSS principles are summarized in the following illustration: 

Finally this other illustration describes the Sprint cycle in LeSS:

It’s Important to mention that LeSS doesn’t  promotes scaling without control, instead it proposes de-scale Scrum based on the proven fact that a lot of great commercial software has been build by small teams of highly motivated individuals. Having those small teams effectively cooperating in the simplest way possible is the key theme in LeSS.

Conclusions

It’s totally possible to have Scrum working not just for one team but for many, for this to happen a deepen organizational redesign will need to occur and that will require complete buy in from executive level leadership.

Without support from executives change can occur but it will be limited to a team or maybe a few teams, in any case the results will be suboptimal and the risk is that eventually people get disenchanted with Scrum and think that it can not be done at a larger scale.

Scrum hast the potential to be the catalyst that triggers the transformation of the whole organization. The Scrum Master can ignites the transformation but then the  executives of the organization need to be the driving force.

Bibliography

Marquet13 Marquet D., 2013. Turn the Ship Around!: A True Story of Turning Followers into Leaders, Portfolio

Laloux14 Laloux F., 2014. Reinventing Organizations, Nelson Parker

Hamel07 Hamel G., 2007. The Future of Management, Harvard Business Review Press

Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute

Larman08 Larman C., Vodde B., 2008. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley Professional 

Introduction

The Product Owner role is highly strategic as she/he sets the direction fo the product that the development team will build. Often times this role is confused as someone that just writes detailed requirements and pass those to the team.

In other cases the Product Owner role is confused with the Project Manager role that makes sure that things work according to a planed scheduled, ironically meeting the schedule doesn’t guarantee that the product will perform well in the market or even solve a problem for the end users.

In the early days of eXtreme Programming a need was perceived for having in a team someone(s) with business  domain knowledge and that can voice the needs from the stakeholders [Beck99]. Scrum put more emphasis on that need and introduced the Product Owner role and made explicit that the she/he has final saying on the product.

It’s common to hear that the Product Owner’s primary tool is the Producto Backlog; that is factual but simplified to an extreme because there are other tools and knowledge from other disciplines that the Product Owner should master in order to do her/his job. The job of the Scrum Master is having that type of knowledge and guide the Product Owner’s learning via coaching and mentoring. 

Steps for Discovering the Product and the Product Backlog

Before even thinking in creating a Product Backlog there are several steps that often are ignored and because of that teams might end up building the wrong product, building it too costly or building it too late.

The first step is to understand the system in which the product will exit, this means not only thinking narrowly in the product but thinking systemically. It’s vital to understand that is not about saying yes to all client’s request but systemically analyzing all the variables that will influence product decisions [Larman17]. 

The second step after understanding the system consists in identifying what is the problem that the product aims to solve.  From a Lean perspective the product doesn’t really solves a problem, instead will mitigate it and by evolving the product better mitigations will be discovered.

The third step is evaluating with the development team the product technical feasibility; feasibility analysis can also be extended to other areas like finance, legal, marketing and others. A common trap that many teams fell in is to invest too much time analyzing and discussing feasibility instead of start building the product in little increments; it’s worth to remember that Scrum says start earlier and validate the product hypothesis as soon as possible.

The fourth step is discovering what features the product will include, who will be the users, and how they’ll benefit from using those features [Watts17]. The techniques from Innovation Games described by Hohmann [Hohmann07] have proveen to be very valuable for discovering and understanding a product. An important recommendation is to use those techniques in a face-to-face workshop with stakeholders, the Product Owners, representatives from the Development Team and the Scrum Master as a facilitator.

The fifth step consist in putting all product details in a Product Canvas [Pichler10] in which is very useful to include paper prototypes of how the product will look.

The sixth step is to discover the PBIs that will form the backlog and order them. User Story Mapping [Patton14] is my favorite technique for doing the discovery part.

The seventh and sometimes controversial step is to estimate PBIs in the Product Backlog. This is controversial because estimates often times can be interpreted as hard commitments. In actuality estimates are just that estimates that will need to be reestimate as we learn more about the product. Further, and estimate is a placeholder that remembers us that we need to keep talking and refining our understanding about a PBI.

The eight and last step is to define the product strategy [Pichler16], that has a very important component that is the Release Plan that defines how frequently the team intends to ship releases out of the door. The Release Plan must also include other important events that need to happen in alignment with the development of the product, event like a marketing campaign milestones, provisioning IT infrastructure, legal contracts, etc.

Lastly, whichever product that has been discover, alongside its backlog and Release Plan, will change in order to accommodate to market conditions and other forces. This is completely expected and should be embraced as the whole point in being Agile is adapting the product as we build it.

Thinking in the Backlog as a List

One of the recurring themes that I’ve observed in many organizations is the over complexation of the product backlog concept.  Agile Lifecycle Management electronic tools add additional terminology, interface and options that one needs to learn before even attempting to create a backlog.

Some Project Managers also contributed to the confusion thinking in the backlog like a new unidimensional version of a tradición Gantt chart where they can still apply technique that they know. 

Richardson [Richardson05] bring some light by pragmatically presenting the backlog in an analogous way and connecting it to a grocery shopping list.

Following that train of thought a grocery shopping list has characteristics such as:

• Publicly visible and available meaning that there is no secret Product Owner’s list, instead there is a list that everybody in the Development Team has access for editing but only the Product Owner can change the order of the items
• Prioritized using several criterion besides only estimates for duration
• In a timeline  that implies that the items in the list can be completed in weeks or months but definitely not years. If the team runs out of time items in the bottom of the list might be sacrificed
• Active and not static that means that the list will change over time to reflect the most current learnings of the Development Team, the Product Owner and the stakeholders
• Measurable in a way the some qualifier can be applied to determine when an  item is completed or not
• With a clear purpose that assure that if we’re implementing those items is because they’ll be part of a product that will be shipped, not just implementing items that may end up archived

Tools for Keeping the Product Backlog

Nowadays in the market you can find several electronic tools ranging from the ones that present a simple online task board to the ones that are part of a larger ecosystem with traceability across multiple tools.

A common feature in the majority of this tools is that they seem to be oriented to generate reports for upper management with metrics and indicators, and tracing back the work to who in the team is doing (or suppose to do) what.

Another characteristic of these tools is that they don’t allow a great degree of experimentation because they were designed as out of the box solutions that include terminology and standardized processes. Going back to Toyota roots is good to remember that we want tools that allow experimentation and continuos improvement in the tools themselves and in how the teams uses them.

Taking the above into account, a very simple alternative is to use Google Spreadsheets for keeping the backlog and a wiki for capturing additional details about PBIs. Even if this idea seems too amateurish it respects the principle of simplicity, saves costs, promotes experimentation, reduces the learning course and facilitates communication.

It is not just my personal experience observing good results with the tools described above but also authors like Larman and Vodde [Larman10] have observed the same at a much larger scale.

Including the Product Owners in the Team

Ideally Product Owner should be a full time member of the team but things like outsourcing and offshoring have distorted that.

If the Product Owner works for an organization that hires another organization abroad is highly recommended that she/he travels at least once a month to work and spend time with the remote team(s).

Having physically present the Product Owner is very valuable especially in the Sprint Review, the Sprint Retrospective and the  Sprint Planning that will come the day after. 

If the Product Owner participates in the Sprint Retrospectives she/he will be able to hear first hand about the problems and inefficiencies that the team suffered during the Sprint and also contributing her/his point of view. 

Similarly by being present the Product Owner will be able to learn in all sincerity how her/his work is perceived and think in what corrections she/he might need to do to better interact with the team.

Another benefit of having the Product Owner in the room is hearing from someone that is more connected to the business, and that can provide a different perspective about what to improve.

Conclusions

Product Owners have the potential to reshape the industry with new and innovative products but that is unlikely to happen if Product Owners lack an Agile mindset along side with an entrepreneurial spirit and solid knowledge about their business domains and the techniques and tools of their craft.

Practical experience is esencial and I consider that for a Product Owner having the opportunity to work in several products, one at a time, in a time horizon of let’s say five years is more enlightening that just writing user stories for the same product during the same period of time.

Finally it’s worth emphasizing a fundamental concept: the Product Owner role and in fact the idea behind having a Scrum Team is having a highly effective and motivated team that builds a product that can have a positive impact in the market.

Bibliography

Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Watts17 Watts G., 2017. Product Mastery: From Good to Great Product Ownership, Inspect & Adapt Ltd

Hohman07 Hohman L., 2007. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional

Pichler10 Pichler R., 2010. Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional

Patton14 Patton J., 2014. User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Richardson05 Richardson J., Gwaltney W., 2005. Ship it!: A Practical Guide to Successful Software Projects, Pragmatic Bookshelf

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

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

Introduction

One of the more popular titles out there is “Agile Coach” and prove of that is the number of job seekers that have it listed in her/his profile, but then there is a much smaller number of people that know what this implies and the qualifications of a good coach.

In Toyota a coach was a mentor that knew the different types of work so well that can teach others and even replace workers. Further, a coach needs to return frequently to the gamba to work and stay real and by doing this keep improving her/his technical skills [Ohno13].

From a different school of thought comes the notion that a “professional coach” doesn’t need to know the business domain in order to do an effective coaching intervention. This school of thought focuses in polishing coaching skills applicable to any context.

My personally postulate is that a Scrum Master must align with a coaching school or approach that allow her/him to know three facets: the work, the human and herself/himself.

Respecting the Client’s Agenda

A coach should prioritize the client’s agenda over hers/his, this means that the client’s problems, concerns, ideas and opinions take precedence over the coach’s [Kimsey11]. If the client is wrong, at least from the coach point of view, the job of the coach is help the client discover why she/he might be wrong and start exploring alternatives. 

I’ve encountered situations in which and Agile Coach or several of them got hired to transform an organization and they star by telling team members that everything they’ve been doing is plainly wrong, that they did Agile wrong. This approach not only generates resistance from the coachees but also contradicts the principle of respecting the client’s agenda. 

Furthermore, what stated above might create the illusion that there is only one good way to be Agile and the the Agile Coach holds the keys for true agility. Of course this is just illusion and even contradicts the agile principles that promotes discovery, experimentation and respect for humans. 

Maintaining  Neutrality

I’ve observed that in many cases the Agile Coaches became the new version of the  managers obsessed to get results at all cost, this maybe happened because organizations paid coaches for results and misunderstood Agile as a management tool good for getting faster results by putting extra pressure on people.  

Even if the client’s agenda might be about going faster, increasing productivity and get 110% of each team member; the coach’s job will be remain neutral and help the client discover other options for getting the result following different paths or even better helping the organization to better define its systemic goals.

Neutrality would also need to be present when the teams want to focus on technical work that not necessarily contributes value or keep insisting in using inefficient engineering practices;  again the idea is that the coach shouldn’t tell people that there’re wrong but help them instead discover that they could be others better ways to work.

Coaching Stances

Coaching stances are diferente operating modes for a coach, depending of the coachee and the situation the coach will need to change from one stance to another.

Lyssa Adkins [Adkins10] identified the following stances:

• Coach as a Mentor 
• Coach as a Facilitador
• Coach as a Teacher
• Coach as a Problem Solver
• Coach as a Conflict Navigator
• Coach as a Collaboration Conductor 

Each of these stances has its own characteristics that need to be know and master by a true Agile Coach.

Logically a coach has talents and personal preferences that will make her/him gravitate  more towards one stance but that is no excuse for not knowing, practicing and being proficient in all stances. 

In fact, a skillful Agile Coach will be able to naturally switch stances depending of the situation and the context.

Coaching Techniques

There are several professional coaching organizations that have identified and developed several techniques for one-on-on coaching, team coaching and even organizational coaching. Personally I consider that is a good thing to first have abroad knowledge of the discipline of coaching and then  specializing and excelling in a few things.

Some of my favorite coaching techniques are listed below:

• Active Listening 
• Powerful Questions
• Reflection

Beyond those techniques I think that their effectiveness is directly correlated to the degree of self-awareness that the Agile Coach has been able to developed.

Conclusions

Coaching is an exiting field and has many applications in an agile team where individuals need to interacted frequently and effectively. Thus is expected that the demand for Agile Coaches tend to rise in the coming years as Agile will keep getting more and more traction. 

Nevertheless, embarking in the Agile Coach journey requires a lot of personal commitment and self discipline for first learning about yourself and then about coaching.

As Lao Tzu said it “Know yourself and you will win all battles”.

Bibliography

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Kimsey11 Kinsey-House H., Kinsey-House K., Sandahl P., Whitworth L., 2011. Co-Active Coaching: Changing Business, Transforming Lives, Nicholas Brealey; 3rd edition

Adkins10 Adkins L., Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, Addison-Wesley Professional

Introduction

The Scrum Master work often times requires that she/he facilitates discussion among developers and a key component of that is that the discussion stay focused, productive, short and in the right level of energy and respect.

The facilitator rol as such has a lot to do with helping the conversation flow without monopolizing it and imposing her/his own conclusions. Very frequently a facilitator has to resist the temptation to tell the team what to do and how.

Other times facilitation has more to do with breaking the silence by making a question that generates valuable discussions [Schein13]. In occasions facilitation implies making that uncomfortable question that no one wants to ask.

Whichever is the situations, the Scrum Master needs to be prepared and have in his toolbox techniques, tools and knowledge that allow she/he to act as facilitator of the communication both inside and outside the team.

To Be or Not To Be on Agreement

Often times a developer or several developers might not be on agreement about technical aspects of the work and in the best case scenario disagreement is voiced and worked out somehow; in a not so good scenario, disagreement is there but nobody says nothing about it and the team is a collection of individuals with fractured opinions.

When facing disagreement a very common reaction is to fear it and neglect or ignore it, this means trying to live in an “artificial harmony” state in which everybody seems to be on agreement and seems not to divergent opinions.  The problem with “artificial harmony” is that is a symptom of a dysfunctional team [LencioniI02]. 

Like in sports and other domains  having a dysfunctional team rarely conduces to productive work. Seems counterintuitive but actually talking about disagreements clears the air for the team and enables it to achieve better performance.

If we see it from a different angle, discomfort is part of team dynamics. In fact, discomfort is the basis upon which dialog emerges and that in time triggers creativity and buy in.

Expressing the former in a simple model:

Divergence ——-> Groan Zone ——-> Convergence

The job of the Scrum Master as a facilitator is not to prevent that the team enters the “Groan Zone”, on the contrary, the Scrum Masters helps the team to safely enters the zone, stay there for a while and then leaves with an agreement that was reached using converging thinking [Schwarz16].

It’s important to notice that convergence doesn’t necessarily  implies that the best solution has been found or that the team has all correct answers, it just creates a hypothesis or presents an idea that needs to be validated by trying it. Needless to say, if the hypothesis or idea doesn’t provide good results when implemented then the team repeats the cicle and tries one more time.

Techniques to Help Convergence

Often times teams can engage in heated debates that can last minutes and even hours; the conversation can be valuable but is still hypothetical until teams start actually working in implementing something. Speaking in Lean terms,  abstract conversations and debates are too far distant from the gemba.

These are some basic techniques that can be very useful to help the team converge and reach agreement:

• Fist of Five where five fingers mean totally in favor, one finger means totally opposed and three fingers mean go with the room and support what the majority decides 
• Dot Voting is a technique that requires that each individual on a team cast her/his vote using a dot next to the option or alternative that she/he supports; votes are casted on a easel pad or whiteboard
• Majority Vote consist in allowing everybody to vote on options and whichever that get more that 51% of the votes wings, this technique can work well with large groups and even electronic tools can be used to cast votes. A general recommendation is not to have too many options 
• Decider Protocol requieres that someone formulates a motion, someone else seconds it and then everybody needs to vote the motion raising hands; the team decides how many votes are needed to pass the motion

It is not advisable that the Scrum Master make business or technical decisions without deep knowledge about the discussion topic. However, there are exceptions in which the team can not decide regardless of several attempts and facilitation techniques.   In extreme situations like this the Scrum Master may decide to switch stances and vote to break the tie.

Listening Facilitation

Taking a step back, in many situations facilitation is needed because people in the team are just not listening to one another and even if they’re listening they’re not understanding what the others are trying to say.

Kaner [Kaner07] proposes several facilitation techniques that can help the team to better listening, these are some of them:

• Stacking means defining a sequence for people to talk one after the other so not everybody try to talk at the same time
• Paraphrasing someone talks using similar words and then asks the person who originally presented the idea if it has been well captured
• Drawing people out helps not only who wants to propose and idea or voice an opinion but also who listens
• Making the space for people in the team that hasn’t talked, talked too little or got interrupted. This technique is specially valuable to help introverts to ask questions or present ideas

Listening techniques are vary handy tools in the Scrum Master’s repertoire because they facilitate the communication process and help to build understanding.

Conclusions

It’s factual that one of the facets of a Scrum Master is being a facilitator but is also true that this is not the only facet and that even though is important should not consume all her/his time and energy. Ideally the Scrum Master should aspire to cultivate a culture of self facilitation inside the team. [Hackman02]. 

Facilitation starting from listening or even better from effective listening is one of the best tools that a Scrum Master can use to help the team converges on an idea, decides to experiment and ultimately validate it.

Bibliography 

Schein13 Schein E., 2013. Humble Inquiry: The Gentle Art of Asking Instead of Telling, Berrett-Koehler Publishers; 1 edition

Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition

Schwarz16 Schwarz R., 2016. The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Coaches, and Trainers, Jossey-Bass; 3rd edition

Hackman02 Hackman R., 2002. Leading Teams – Setting the Stage for Great Performances, Harvard Business Review Press

Kaner07 Kaner S., 2007. Facilitators Guide to Participatory Decision-Making, Jossey-Bass; 2nd edition

Introduction

Much has been said and written about Toyota and how its practices have influenced and sometimes revolutionized the working environment of companies from different sectors worldwide.

Toyota has been the cornerstone on which Lean principles were grounded and these in time have greatly influenced Agile and the Scrum framework.

We often times forget to go back to Scrum roots in order to understand why we do things. Scrum has become popular but many people continue to ignore the pillars on which it is based and this can brings negative consequences.

The Machine that Changed the World

Cars have had a great influence on the transformation of societies and their way of producing has been definitive when it comes to modernizing manufacturing.

In fact, no other machine in the modern era has had such a big influence on the way workers, materials, capital, knowledge and equipment have been organized [Womack07].

A more efficient form of organization −following Lean principles and  avoiding various forms of waste− leads to greater productivity, better aligned with the market and impacts positively the well-being of the teams: hence the recommendation that Scrum Masters know and try to apply Lean manufacturing principles.

The Essence of the Toyota Way

Taiichi Ohno [Ohno13] greatly summarized a fundamental principle: the misperception that comes from being too far away from the gemba. To clarify errors of perception Ohno suggests a simple “Go and see” practice.

Unfortunately, this principle is not frequently seen in Scrum Teams that intended to supervise or evaluate the work by just reading reports and seeing visual indicators. 

A second fundamental principle is “stop and fix” which literally meant for Toyota to stop the production line as soon as a quality problem was detected, apply the “five whys” technique to find the root cause of the problem, mitigate (not find the perfect solution) and then resume the production line.

The “stop and fix” principle also had a second purpose: to force continuous learning. In general, adults, or at least a great number of us, do not want to continue learning and therefore a practice like this forced Toyota developers to stop working, reflect on what was not working well, propose possible mitigations and experiment with them.

Contrary to the “stop and fix” principle many Scrum Teams out there frequently tend to pile up defects and even create a backlog for them where they got recorded but ultimately forgotten; this practice not only contradicts a Toyota principle but also doesn’t improve engineering practices nor contributes to expand developers’ knowledge. Doing more work that is lacking quality or doing it in a more predictive way won’t positively impact the product that will keep accumulating technical debt. 

The list of Toyota Principles includes many [Liker04] but here only one more will be mentioned: “kaizen at infinitum”. This principle is about people continuously learning and expanding their knowledge, that eventually greatly pays off in the form of higher quality products [Senge90].

Very frequently I encountered Scrum Masters that are after learning the “Scrum best practices” which in reality doesn’t exit, and if they do those are tightly connected to a particular context and for that reason can not be directly extrapolated. Instead of embarking on that imposible quest, the Scrum Master should turn her/his attention to uncover how to build an environment of constant learning in which people can experiment with different practices. Paraphrasing Senge [Senge90] the differentiator of an organization (and its teams) is the wealth of acquired knowledge and the willingness to keep learning.

Lean, Respect and Waste

The Lean approach for manufacturing could be simplistically expressed using the following formula [Ballé14]: 

LEAN = RESPECT + KAIZEN

Where RESPECT refers to respect for the workers and their creativity,  and the  upper management commitment to provide all the necessary conditions for workers to develop their maximum potential.

From a traditional Lean perspective the central theme is to maximize activities that contribute value and minimize activities that generates waste. Wasteful work then can be classified into to broad categories: urgent waste that has to be reduced inmidiatlye and identified waste for which there is no mitigation that can be applied immediately.

Waste can take many forms, some of the most common are:

• Overburden and stressed workers
• Bottlenecks
• Waiting in queues
• Handoff
• Wishful thinking 
• Dissemination of information 

And many others that are particular to individual teams and context.

Consequently, part of the job of the Scrum Master is to positively contribute to create a culture in the team that values respect, really embraces and uses it as a pillar to work collaboratively to identify forms of waste and possible mitigations.

The opposite would be a culture of no-respect where forms of waste are not identified and even if so no one in the team does anything about it; no-respect can also lead to demotivation and won’t help the team to improve its own practices.  

Agile: Decades After and There is Still Confusion

It is very common these days to hear the very popular term “Agile” as a prefix  of many things like Agile Coach, Agile Adoption, Agile Inception and many others. However there is a sustancial problem that remains unsolved: people and organizations are trying to copy and use something that they haven’t completely understood yet.

Because of this one of the big challenges for the Scrum Master is to educate others so there is an overall better understanding of what Agile really is. One valuable tool that can help with this is the Agile Manifesto but this could not be sufficient due to its concise and lightweight nature.

Another tool is to educate using terminology and concepts that are frequently used in the Agile space and connected to software development.

Notwithstanding, I’ve found in practice that people and organizations tend to better assimilate Agile when it’s presented from a historical perspective that describes its evolution starting from its roots in Toyota, the connection with software and the key influence of eXtreme Programming.

Furthermore, it’s very valuable to highlight the connection between Toyota and the current practices of DevOps [Forsgren18].

Whichever path you choose to explain Agile I think is important to recognize that Agile has a lot to do with things like:

MINDSET <-> CULTURE (PRINCIPLES + PRACTICES)

Equally important to mention is that Agile keeps evolving as more and more agilist gain experience and take Agile to other domains, there are for instance two examples of agile evolution: Modern Agile and The Heart of Agile. I’m expecting that this evolution continues as Agile itself is an evolving concept.

And That is How We Arrived to Scrum

It is true that Scrum is an Agile lightweight framework that is team-centric and used by teams to collaboratively build products, but it’s also true that Scrum conceptual simplicity could led to be erroneously interpreted as a simple prescription of a set of meetings and the use of post-its on a taskboard.

Scrum needs then be understood from a more educated historical perspective and also in connection with other disciplines that complements it, more simplify put:

SCRUM = LINEAGE + INTERSECTIONS

If we talk about lineage it’s vital to understand that Scrum is not a revolutionary framework; instead it comes from the influence of the Toyota Production System that originated Lean Manufacturing and both influenced in time Agile and  Scrum. 

And if we talk about intersections Scrum intersects with a long list of disciplines  such us:

• Queueing Theory
• Systems Theory
• Industrial Empirical Process Control
• eXTreme Programming
• Caos Theory
• Soft Skills
• Team Building 
• Facilitation
• Coaching

The Scrum pragmatic goal is to create a continuous learning environment where is safe to experiment and fail. This type of environment fosters continuous improvement and benefits the Scrum Team, the Product Owner, the organization and the advancement of software development practices. 

A corollary of this is that the Scrum Master should focus in four areas: the Development Team, the Product Owner, the Organization and the software development practices [Larman17].

Conclusions

It’s been openly said that Scrum can and should be adapted and combine with other tools and approaches but that needs to occur respecting the Agile principles and also taking into account the connection with Lean and the Toyota Production System.

Making adaptations disconnected from the Agile principles frequently have lead to suboptimal results and/or failed Scrum adoptions. What is even worst, Scrum has been mistakenly seen as a new and improved tool for better control developers that now need to work harder to meet imposed deadlines.

The Scrum Master rol is fundamental to clarify this misunderstandings so Scrum can be all adopted and really benefits people as the Scrum creators really envisioned. 

Bibliography 

Womack07 Womack J., Jones D., Ross D., 2007. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry, Free Press; Reprint edition

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw-Hill

Liker04 Liker J., 2004. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, McGraw-Hill

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute

Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press

Larman17 Larman C., Vodde B., 2011. Large-Scale Scrum More with LeSS, Addison-Wesley