Preface: To be transparent in my agenda, I firmly believe there are strong parallels between Agility and Human Rights, and I believe that is a purposeful and direct by-product of the primary outcomes of the Agile Manifesto. However, I have attempted to make this article a little different from others by more subtly embedding the learnings and patterns within the messages and on several levels. As such I hope the connections are still obvious, and that you find this article refreshing, insightful, appropriate and useful.

A Premise

It seems everywhere I turn lately there is a scandal of greed, lust, abuse, harassment, violence or oppression in both the workplace as well as personal life. I’d like to believe the number of despicable activities is not actually increasing but rather I am simply exposed to more because we live in an age when the speed and ease of access to information is staggering. Certainly recent events are no exception to human history that records thousands of years of oppression, subjugation, control, and violence. My question is: as a supposedly intelligent species, why is it we have seemingly learned very little over the millennia?

I propose we have actually learned a great deal and made significant advances, yet at the same time we have experienced setbacks that repeatedly challenge that progress. These setbacks are often imposed by select individuals in positions of authority that choose to prioritize and exert their power, individual needs or desires over the rights and needs of others. However, I believe if we can truly harness the power of unity and collaboration we can make a significant positive difference, and that is what I seek your help in doing.

“The whole is greater than the sum of its parts.”
~ Aristotle

Finding a Beacon in the Darkness

Every day I find it disheartening to bear witness to people being physically and mentally hurt, abused or taken advantage of. In their personal lives and at home. At the workplace. In wars and conflicts. In human created environmental disasters. It seems there is no end to the pain and suffering or the countless ways to inflict it.

Meanwhile I sincerely believe many of us have the desire to make the world a better place, but given our positions and busy lives it can be daunting to make a real difference. In many instances we feel powerless to change the world because someone else has authority over us or over the system. It may also seem pointless to commit to change something we as an individual have little to no control over. It can also be risky to draw attention to ourselves by speaking against others in a position of power who may and sometimes will exert their influence to attack and hurt us as well as those we care for.

Despite the temptation to hide from the noise we must remain strong and acknowledge that by creating transparency and visibility in to dark and sometimes painful events we are actually opening the door to the opportunity for positive change. Obscuring truth does nothing to help a worthy cause or to better society. Remaining silent about an injustice does not provide the victim with any form of respect or comfort. Pretending something didn’t happen doesn’t make the consequences and outcomes any less real for the casualty. Inaction does not provide any benefit except perhaps the avoidance of an immediate conflict.

Many times, shining a light on something does provides tangible benefit. It creates visibility and awareness, and provides opportunity for the truth to be exposed. Although transparency itself may not solve a problem, reflection and openness should make the misalignment more critical and obvious. I believe the majority of us want trust, and honesty wherever we are, whether it be in the boardroom, on the manufacturing floor, in a political office, or even in a private home.

“Each time a man stands up for an ideal, or acts to improve the lot of others, or strikes out against injustice, he sends forth a tiny ripple of hope, and crossing each other from a million different centers of energy and daring, those ripples build a current that can sweep down the mightiest walls of oppression and resistance.”
~ Robert Kennedy

However we must also acknowledge that sharing truth may often be painful and uncomfortable, and in order to create the opportunity for truth we must first provide individuals with safety so they may find the courage to do what is right. Without safety people fear reprisals, embarrassment, retribution, consequences, and loss of respect. History has taught us that without safety and courage we can not expect most people to bridge the chasm from fear to justice, and as a result the silence will continue. With silence there will be no hope for change. So in order to help define expectations and to foster a safer environment for effective communication we need a code to live by; one that provides standards and creates safety – that serves as a beacon in the darkness so that we may uphold ourselves and one another to it.

To be absolutely clear, I am not saying that policies, processes and tools are more important than people. Instead, I am acknowledging that the right combination of policies and processes with appropriate tools and a method to uphold those ideals should serve to provide opportunity for fairness for people, which is the desired outcome.

A Disturbing Retrospective Leading to a Hopeful Outcome

At the end of World War II when “relative” safety was finally achieved, people were exhausted, shocked and appalled with the magnitude of human atrocities they bore witness to. Given the darkness of the times it may have seemed less painful to move on, put it in the past, and perhaps even obscure disturbing facts rather than revisit them in the pursuit of learning. Instead, the leadership of that time chose to leverage careful inspection to uncover truths and provide visibility with the aspiration that something good could flow out of the evil. In the end the aim was to use the learnings to create a shared understanding and define standards and expectations for a safe environment in the future.

“Those who cannot learn from history are doomed to repeat it.”
~ George Santayana

To this end I believe we already have a code to live by, but I surmise most of society doesn’t give it the continuous, serious consideration and support it deserves. The United Nations Universal Declaration of Human Rights (UDHR) was created on December 10, 1948 as a direct outcome of the learnings from World War II, and in this brief but impactful document are 30 articles that define human equality and set the standards for safety. Despite some of its choice wording and age (at almost 70 years) I believe it is still directly relevant and bears serious attention.

The UDHR document transcends political borders, gender, orientation, race, religion, boardrooms, workplaces, homes, family, and economic status. Every person on this planet should not only just read it, but actively live, work, and explicitly honour the values it represents. The UDHR should become the definitive core learning article for every child. If we all continuously make a firm commitment to hold ourselves and others by the standards in the UDHR I believe we could collectively create opportunity for better safety, transparency, respect, and courage in the workplace, at home, and abroad by putting focus on what matters most – equality and the value of and compassion for human life.

The UDHR document may be policy, but with continuous effort, unilateral agreement and support it enables and empowers people. It may not be perfection, but it is aspirational towards it. It focuses on individual rights but strongly values human interaction. It promotes balance, harmony and partnerships. It demands mutual respect and caring. It is elegant in its simplicity. It promotes collaboration and shared responsibility. It defines clear expectations for a safe environment.

I believe the UDHR is the manifesto of real, human agility, and if enough of us embrace and enforce it I believe we could collectively make real, positive change.

Now, A Challenge

I challenge each and every one of you to take time to read the UN Declaration of Human Rights. I don’t just mean on the train on the way to work, or over morning coffee, or while your kids are playing soccer or hockey, or whatever you do to pass a few minutes of time. I mean take time to really, truly and deeply comprehend what each of the thirty articles are saying. Reflect on the value of wisdom that it provides and how that wisdom came from pain and learning. I then encourage you to share it with every family member (adults and youth) and ask for constructive feedback on what it says about them and personal life. I encourage you to share it with every co-worker and then have an open, honest dialogue about what your company culture and leadership either does or fails to do to provide a safe work environment and to promote equality, truth, transparency and human rights.

Then, I challenge you to ask every single day “Given the declaration, what small positive adaptation or change can I make right now to help our family, friends, peers, coworkers and humanity achieve these goals and outcomes?” You could start with something as simple as a brief conversation, and see where it goes.

“Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that.”
~ Martin Luther King, Jr.

I asked myself that very question after visiting the UN General Assembly and Security Council Chambers in New York late last year. In response, one of my first actions in 2018 is to publish this article in an effort to re-establish awareness about the UN declaration and how it may bring hope and positive change if we can rally enough people behind it. How about you?

A secondary (and arguably less important) challenge I am issuing for Lean and Agile enthusiasts is for you to identify the patterns and key words in this article that I have borrowed from various facets of the Lean and Agile domains (hint: there are at least 20 different words – can you spot them). I purposefully embedded these patterns and key words in this article to explicitly highlight the parallels that I see between Agility and the UDHR and I hope you see them too.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

Trust is an exceptional quality that we humans can develop with each other. It goes a long way to building positive relationships. We hope and strive for trust in our families, and with our most intimate connections. Yet do we expect trust in our work lives?

Can you imagine the relief you might feel entering your work space, knowing that you can do your work with confidence and focus? That encouragement rather than criticism underlies the culture of your workplace? That a manager or co-worker is not scheming behind your back to knock you or your efforts down in any way? That you’re not being gossiped about?

Trust is especially key in today’s work spaces. Teamwork is becoming an essential aspect of work across every kind of business and organization.

Here’s what one team development company writes about this subject:

The people in your organization need to work as a team to respond to internal and external challenges, achieve common objectives, solve problems collaboratively, and communicate openly and effectively. In successful teams, people work better together because they trust each other. Productivity improves and business prospers. http://beyondthebox.ca/workshops/team-trust-building/

It Starts With Me and You

As with so many qualities in life, the idea of trust, or being trustworthy, starts with me and you.

It is essential that we take a hard look at ourselves, and determine whether or not we display the attributes of trustworthiness.

To do this, I might ask myself some of these questions:

Do I tell the truth?

Do I avoid backbiting (talking about others behind their back)?

Do I do what I say I’m going to do?

Do I apply myself to my work and do my best?

Do I consciously build positive relationships with all levels of people in my workplace?

Do I encourage or help others when I can?

There are many more questions to ask oneself, but these offer a place to start.

One website proposesa template to assess employees in terms of their trustworthiness:

Trust develops from consistent actions that show colleagues you are reliable, cooperative and committed to team success. A sense of confidence in the workplace better allows employees to work together for a common goal. Trust does not always happen naturally, especially if previous actions make the employees question if you are reliable. Take stock of the current level of trust in the workplace, identifying potential roadblocks. An action plan to build positive relationships helps improve the overall work environment for all employees.

This snippet comes from “Lou Holtz’s Three Rules of Life,” by Harvey MacKay:

“The first question: Can I trust you?”

“Without trust, there is no relationship,” Lou said. “Without trust, you don’t have a chance. People have to trust you. They have to trust your product. The only way you can ever get trust is if both sides do the right thing.”

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.

Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.

Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.

Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.

For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.

There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.

The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.

Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.

Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.

But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

“Improv-ing Your Scrum Team” was the title of the webinar given by Paul Goddard, a CST and Coach from the UK with a background in improvisational theatre. He has written and coached extensively on the use of improvisation to help Scrum teams develop. Because of my own experience in teaching and creating theatre, I was eager to see how Mr. Goddard used improv to improve Scrum teams.

For clarity’s sake, we can describe improvisation, in theatrical milieus, as the act of making things up as you go along. Improvisers are normally people who know their discipline very well, and are able to allow their creativity to take them into new places, new expressions, in their art.

Themes

The improv themes Goddard covered that can be used with Scrum teams were: creating safety, being spontaneous, telling stories, changing status and increasing sensitivity.

He likened these themes to the Agile Manifesto which proclaims: “Individuals and interactions over processes and tools,” and “Responding to change over following a plan.” He also related improv to Agile principles of “welcoming change,” “face to face is the best way to convey information,” and “the best designs emerge from self-organizing teams.”

Myths

In an interesting aside, he also compared myths of Agile to myths about Improv, for example, that Agile is only about creating software, and Improv is only about comedy. Another myth is that Agile and Improv are about unstructured chaos, whereas both prescribe being disciplined within a framework. Goddard described the Scrum framework as “a lightweight structure that uses constraints to unlock creativity;” improv also provides such a structure.

Creating Safety

Improv starts with “creating safety.” Since it is impossible to improvise alone, we must learn to trust others. This involves a team behaving as a family who rescue each other if necessary. There are no mistakes in improv; team members work for each other. When we try too hard in improv to get it right, it becomes a struggle to feel safe. Ultimately, we should be able to feel safe whether we win or lose, and definitely we feel safe when we PLAY.

Being Spontaneous

The second theme is “being spontaneous.” Spontaneity is the ability to act on impulse as soon as an idea occurs. This is the bread and butter of creativity. We are less spontaneous when we filter or edit our ideas before trying them out. We usually do this filtering because we fear our ideas being deemed crazy, or obscene, or unoriginal. Good improvisers increase their spontaneity by giving and receiving offers from team members. Offers are the currency of improv: you go with an idea, build on it, and keep a scene going. Bad improvisers put up blocks, that is, they reject ideas, and a scene goes nowhere.

Telling stories

Goddard tells us that the power of storytelling lies in the fact that many parts of the brain get activated: empathy is increased, oxytocin hormone and cortisol is released when we feel empathy for a character, and so on. Conversely, the brain switches off ideas or stories that are cliches – things we’ve heard too many times before and are inured to. The beauty about stories is that they make dry data more human and therefore interesting.

Changing status

Status always exists, especially in business environments. Some jobs or roles imply having a higher status, i.e. Scrum Master. If physical power poses adjust the hormones in our bodies, as Goddard claims, then the opposite is also true. In improv, playing high or low status and then changing it becomes a dynamic and creative game. It assists in collaboration. Low status players in improv tend to accept offers from their fellows; high status tend to refuse offers, unless they can control them. Scrum teams can learn to play with status to collaborate more effectively.

Increased sensitivity

Great improvisers develop certain qualities: selflessness (they want to make others look good), listening, observation, recollection/ memory, and emotional awareness (ability to pick up on cues). They are able to be “fully in the moment.” Goddard describes this as “thinking inside the box,” i.e. with safety established, the ideas are already there.

Back to Scrum

Just as in an improv team, a Scrum team’s firmest foundation is trust. How can one introduce improv and its beneficial themes to a Scrum team? Start with the idea of a game. It’s not about performing. It’s simply about having fun together, getting to know each other, learning common values, shaking off the dust of work-related responsibilities and allowing time for play. If you’re working with introverted types, allow that person to opt out. Make sure no one is judged. It’s important to be able to joke and feel like a family. Even a non co-located team can play word games over the telephone.

I look forward to trying out some improv with my own team, and, hopefully, in the future with others.

For a more in-depth understanding of the use of improv see Paul Goddard’s book “IMPROV-ING AGILE TEAMS” available at www.amazon.ca.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

Hi Everyone, I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve! This is a fully automated Scrum maturity assessment tool!

The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results. The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.

The analysis is both statistical and expert-system based. This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements. There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.

Every team member fills in the survey to help us generate a valid set of recommendations.

The Scrum Team Assessment is $496/team/use (that’s Canadian dollars). If you have several teams or wish to obtain an enterprise license, please contact us at sales@berteigconsulting.com or +1-905-868-9995.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

Under the right conditions Scrum can be a tremendous success story, but it often requires hard work to get there. For new Scrum teams it means learning to fundamentally work very differently than they are used to, such as relying on a lot more collaboration, making and delivering on shared commitments and building a high degree of trust. For existing Scrum teams it means constantly renewing the team commitment to each other, the cause, and to the Scrum framework. This includes the rather painful practice of revisiting the fundamentals and ensuring any deviations from accepted processes or practices were for the right reasons and had the right results.

To have a chance at achieving high performance a new-to-Scrum team will not only need to just change their processes, but fundamentally change the culture and behaviour of the team and all of the supporting roles (that includes their leadership). Meanwhile, a mature or well-established team should never assume they are high performance; they should always be checking (and rechecking) that they are still living the Agile values.

Needless to say this can become an extremely complex challenge! To be absolutely clear, I’m not proposing there is a single formula or recipe that works, but I do believe certain criteria can dramatically improve your Scrum team’s chances of success. To that end here are 10 tips (plus a bonus) that may help you focus your efforts towards building a successful Scrum team and experience.

1. Right Number of Team Members

Currently the Scrum Guide recommends that Scrum teams will work best with three to nine people (not including the Scrum Master and Product Owner). Too few people on the team and you risk not having enough technical expertise and coverage of critical skills. Too many people on the team and you may become challenged to truly collaborate effectively. Remember, this is just a guideline and you may be successful with different numbers, you just need to be aware of the impacts and make sure the gaps are covered.

2. Appropriate Balance of Skills

Scrum teams really should be balanced and cross-functional. Having all of the necessary skills on the team for delivering a complete solution (not roles, but skills) will encourage and support end-to-end thinking all the way from design to implementation. This approach will result in a better solution and a superior customer experience, but it relies on whole team collaboration. Note this does not mean individual team members need to be fully cross-functional, but what is important is that all the critical skills are represented on the team and each team member contributes their domain expertise towards the collective strength.

3. Propensity for Engineering Technical Ability

For increased chances of success, a Scrum team should leverage technology and engineering practices whenever possible. Techniques, skills and tools that facilitate Agile approaches such as Continuous Integration, Automated Testing and Test Driven Development all make technical excellence, continuous improvement and truly being “Done” every Sprint a possible reality for a Scrum team.

4. High Team Member Allocation

Scrum team members should be allocated to as few different initiatives as realistically possible. The more projects you are allocated to, the more task switching you may have to perform, the longer it will take to complete any one item, the thinner you will be spread and the less effective you will be. In other words, people (and teams) should limit their work in progress as much as possible and focus on completing those things that truly matter most. This is true for any framework, but it is particularly emphasized with Agile ones. Note there is a slight but fundamental difference between being allocated to a team and being dedicated to a team – that is a topic for a future article.

5. Empowered and Knowledgeable Product Owner

Your Product Owner needs to be informed, available, business-savvy, knowledgeable, collaborative, and empowered to make decisions about what to build and what order to do it in. They also need to be a strong negotiator and very capable at conducting business driven trade-offs. In the end, a Product Owner needs to effectively communicate, convey and deliver on a clear vision to the Team and Stakeholders to ensure a useful solution is created. Without empowerment, knowledge, and vision in a Product Owner the team will struggle.

6. Equitable Scrum Master

Having a good process is only part of the equation. A good Scrum Master will champion and enforce that process, protect the team, encourage collaboration, highlight (escalate when necessary) and encourage the removal of obstacles, facilitate discussions, provide fair and constructive feedback, cultivate a culture of continuous improvement and learning, and work to help the team live the Agile values.

Remember that the Scrum Master has authority over the process but not over the team. As the process champion the Scrum Master may sometimes even find themselves in a conflict between maintaining the Scrum rules and guiding the team as they discover the need to adapt practices to better align with their own needs and ways of working. In that regard a Scrum Master should understand and embrace the servant leader role. In the end, a Scrum Master needs to be the person that helps the team make decisions, but not the person that makes decisions for them.

7. Strong Executive Support

Leadership is the key to driving change and progress. Executives and managers of Scrum teams need to nurture the environment, let go of the “how”, allow the team to learn from mistakes, and encourage and coach the growth of the collective team knowledge and overall experience.

Understanding the dramatic impact leadership has on a transitioning team is also very critical, as a single word or direction from the executive level can single-handedly affect (either positively or negatively) the team’s future behaviours and resulting successes or failures. And without a true environment of trust built by the leadership, team members will often shy away from taking a risk to try something new or unknown.

8. Solid Partnership Commitment

There must be a consistent commitment and engagement from all parties in the organization towards adopting the Scrum framework, Agile methods, and thinking. The initiative must be an open, collaborative experience and there must be complete understanding and alignment by all parties in assuming the risks and rewards as well as sharing in the effort. This includes not only business partners and their IT counterparts, but their leadership as well as all of the people and teams supporting an Agile initiative.

9. Reduced Team Dispersion

Co-located teams are more effective communicators and can sometimes experience increased productivity by up to 60% if situated together in the same room. More simply stated, the greater the dispersion factor, the greater the challenge of collaboration. Note that time zones are often considered the largest dispersion factor and can have a greater impact than geography.

Although it is strongly recommended that teams be co-located, it is not mandatory to success. In fact, certain Agile practices have factors, tools and techniques inherent to them to help bridge some of the shortcomings of increased dispersion, such as a higher reliance on frequent collaboration and communication. But to be clear, they do not replace the value of face-to-face conversation, they are merely a crutch to not having it.

10. Consistent Education and Coaching

To ensure consistency and a shared understanding, whole teams (including the business, IT, and their leadership of executives and managers) should receive a common skills development and education experience in proper Agile Thinking, the Scrum Framework, aligned practices and mindset training. Coaching should then reinforce this new knowledge and encourage appropriate behaviours to turn these new practices into habits. Indeed, learning should be a continuous cycle and endless journey towards excellence, and Scrum leverages this through frequent retrospection and continuous improvement.

11. The Right Attitude!

Mutual respect and caring are the cornerstone to the team’s success and it needs to be integral to their culture and beliefs. Not just saying but living the belief there are no heroes or scapegoats. Everyone, including the business, executives, team members and leadership must collaborate and share in celebrating the successes as well as accepting responsibility for setbacks and failures.

Everyone must have the right attitude and commit to not only DOING as needed by attending the ceremonies or following the process and practices but truly wanting to BE part of the solution by willingly changing the way they think, work and collaborate.

At the end of the day your goal should not be to become Agile or Scrum savvy. Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers. These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention. Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.

For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach. To be clear, this is not easy to do but the rewards are well worth the effort. By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.

Can you think of other success factors that might help your Scrum team succeed? There are lots, so feel free to reach out and share them below.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

The Hunt for Better Retrospectives

The rumours had started to spread, retrospectives at our organization were flat, stale and stuck in a rut. The prevailing thought was that this was stalling the pace of continuous improvement across our teams. In truth, I wasn’t sure if this was at all true, it’s a complex problem that has many possible contributing factors. Here are just some possible alternative or co-contributing causes: how the teams are organized, the level of safety, mechanisms to deal with impediments across the organization, cultural issues, levels of autonomy and engagement, competence & ability and so on…

On the theme of safety, I thought we could try to go as far as having fun; we’d already had lots of success with the getKanban game (oh Carlos you devil!). Where it all tied together for me, was being inspired by the great question-based approach from cultureqs.com that I’d had a chance to preview at Spark.

If I could create a game with the right prepared questions, we could establish safety, the right dialogue and maybe even have some fun.

The Retro Game

This is a question-based game that I created that you could use to conduct your next retro for teams of up to 10 people. The rules of the game are fairly simple and you could play through a round or two in about 1 to 2 hours depending on team size and sprint duration. Prep time for the facilitator is about 2-4 hours.

Prepping to play the game

You, as facilitator, will need to prepare for 3 types of questions that are thought of ahead of time and printed (or written) on the back of card-stock paper cards.

One question per card. Each question type has its unique colour card. About 8 questions per category is more than enough to play this game.

The 3 types of questions are:

In the Moment – These are questions that are currently on the mind of the team. These could be generated by simply connecting with each team member ahead of time and asking, “if you could only talk about one or two things this retro, what would it be?” If for example they responded “I want to talk about keeping our momentum”, you could create a question like “what would it take to keep our momentum going?”

Pulse Check – These are questions that are focused on people and engagement. Sometimes you would see similar questions on employee satisfaction surveys. An example question in this category could be “What tools and resources do we need to continue to be successful?”

Dreams and Worries – This is a longer-term view of the goals of the team. If the team has had any type of Lift Off or chartering exercise in the past, these would be questions connected to any goals and potential risks that have been previously identified. For example if one of a team’s goal is to ship product updates every 2 weeks, a question could be “What should we do next to get closer to shipping every 2 weeks?”

On the face-up side of the card it should indicate the question type as well as have room to write down any insights and actions.

You will also need:

To print out the game board

To print out the rule card

Bring a 6-sided dice

Playing the Game

Players sit on the floor or at a table around the game board. The cards are in 3 piles, grouped by type, with the questions face down.

The person with the furthest birthday goes first.

It is their turn and they get to roll the dice.

They then choose a card from the pile based on the dice roll. A roll of 1 through 3 is an “In the Moment” card, 4 is a “Pulse Check” and 5 to 6 “Dreams & Worries”

They then read the card question on the card out loud and then pass the card to the person on the right.

The person on your right is the scribe, they will capture notes in the Insight and Actions boxes of the card for this round.

Once they have read the question, they have a chance to think and then answer the question out loud to the group. Nobody else gets to talk.

Once they’ve answered the question, others can provide their thoughts on the subject.

After 3 minutes, you may wish to move on to the next round.

At the end of each round the person whose turn it was chooses the person who listened and contributed to the discussion best. That person is given the card to keep.

The person to the left is given the dice and goes next.

Winning the Game

The game ends at 10 minutes prior to the end of the meeting.

At the end of the game, the person with the most cards wins!

The winner gets the bragging rights (and certificate) indicating they are the retrospective champion!

You should spend the last 10 minutes reflecting on the experience and organizing on the action items identified.

Concepts at Play

Context & Reflection – Preparation is key, particularly for the “In the Moment” section. The topics will be relevant and connect with what the team wants to talk about. Also when presented in the form of a question they will likely trigger reflection for all those present.

Sharing the Voice – Everyone gets a chance to speak and be heard without interruptions. The game element also incentivises quality participation.

Coverage of topic areas – The 3 question categories spread the coverage across multiple areas, not just the items in the moment. The probabilities are not however equal, for example there is a 50% chance of “In the Moment” being chosen in each turn.

Fun & Safety – The game element encourages play and friendlier exchanges. You are likely to have dialogue over debate.

Want to play the game?

I’d love to hear how this game worked out for you. I’ve included everything you need here to setup your own game. Let me know how it went and how it could be improved!

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions. Let’s look at each of these aspects of the ScrumMaster role in turn:

The ScrumMaster Helps the Team Follow the Rules of Scrum

The ScrumMaster is a process facilitator. The Scrum process, while simple to describe, is not easy to do. As the Scrum Guide says:

Scrum is:

Lightweight

Simple to understand

Difficult to master

The ScrumMaster helps the Scrum Team and the organization to master the Scrum framework. Helping everyone understand Scrum and respect its rules is a first step. Some of the rules are particularly challenging. In some companies, being on time for meetings and ending them on time is hard. Scrum requires this. The ScrumMaster helps the team do this. In some companies, meeting deadlines, even short ones, is difficult. Scrum requires this every Sprint. The ScrumMaster helps the team do this. In some companies, giving time to improving things is hard. Scrum Teams do retrospectives. The ScrumMaster ensures that the team takes the time for this.

Of course, following the rules is hard for people. Even just the concept of “rules” is hard for some people. Everyone has the right to do whatever they want. Well, if you aren’t following the rules of Scrum you aren’t doing Scrum. So for some teams, just getting to the point of being willing to follow the rules of Scrum is a big step. The ScrumMaster needs to help with motivation.

The ScrumMaster is Vigorously Removing Obstacles

The Scrum Team is going to be working hard to meet a goal for the Sprint. As they work, they are going to work through many challenges and problems on their own. However, the team will start to encounter obstacles as well. These obstacles or impediments come from a few sources:

Dependencies on other people or parts of the organization outside the Scrum Team.

Skill gaps within the team.

Burdensome bureaucracy imposed by the organization.

Lack of resources such as tools, equipment, licenses, or even access to funds.

The ScrumMaster needs to work through these.

On a panel talk on Saturday one person said “the scrum master is an administrator, moving cards, updating the burn down. It is an easy job, I think my son could do it.” I then rebutted his remarks….

The ScrumMaster will tackle enterprise operations for their slow error prone deployment process, tackle Sarbox [Sarbanes-Oxley] compliance policy that has been way over-engineered to the point of slowing dev to a crawl, telling the PMO that 3 sets of reports is waste, exhorting the team to try to do unit tests in ABAP (SAP cobol), etc.

The ScrumMaster is Protecting the Team from Interruptions

Every organization seems to have more work than their staff have the capacity to deliver. Staff are often asked to task switch repeatedly over the course of a day or even in a single hour. Sometimes people are “allocated” to multiple projects simultaneously. This breaks the Scrum value of focus. The ScrumMaster needs to protect the team from interruptions or anything else that would break their focus.

But what should the Scrum Team members be focused on? Simply: the goal of a single Sprint. And a single Scrum Team is focused on a single product. The Product Owner should be the point of contact for any and all requests for the time and effort of a Scrum Team. The ScrumMaster needs to re-direct any interruptions to the Product Owner. The Product Owner decides if:

the interruption results in a new Product Backlog Item, OR

the interruption is irrelevant to the product and simply discarded, OR

the interruption is important enough to cancel the current Sprint.

There are no other options in Scrum for handling requests for work from the Scrum Team (or any member of the Scrum Team).

Contribution as Distraction for the ScrumMaster

Any time the ScrumMaster starts to contribute to the product development effort directly, the ScrumMaster is distracted from the other three duties. Although simple, following the rules of Scrum is not easy. Getting distracted from the duty of helping the team follow the rules of Scrum means that the team is likely to develop bad habits or regress to non-Scrum behaviour. Vigorously removing obstacles is usually a huge job all on its own. Most Scrum Teams have huge organizational obstacle that must be worked on. Some of these obstacles will take years of persistent effort to deal with. The ScrumMaster cannot become distracted by tactical details of product development. Protecting the team from interruptions means the ScrumMaster must have broad awareness, at all times, of what is happening with the team. If a team member is interrupted by a phone call, an email, or someone walking into the Scrum team room, the ScrumMaster needs to notice it immediately.

Whenever a ScrumMaster takes on a product development task, focus on the role is lost and a condition of a simple conflict-of-interest is created. If the team has “committed” to deliver certain Product Backlog Items at the end of a Sprint, then that feeling of commitment may lead a ScrumMaster to focusing on the wrong things.

The time of a ScrumMaster is an investment in continuous improvement. Letting a ScrumMaster contribute to the work of the team dilutes that investment.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

The next time the team says “we can’t estimate without better requirements” what they actually mean is, “this is crazy, but hey…if you think you can accurately predict all the exact requirements and you can guarantee that nobody in this company will change their minds about those requirements between this moment and forever, then we’ll give you an estimate to hang your hat/noose on.”

Every group responsible for the creation and delivery of software (or any complex/creative product for that matter) will experience dissonance between the need to plan and the need to obey the laws of nature which prevent us from travelling through time and future-telling. Business leaders have to finance the development of product; creative and technical leaders have to solve complex problems amidst dynamic, unpredictable, circumstances. These conditions manifest as a dichotomy which is difficult to mediate (at best) and/or downright toxic (at worst).

On one hand, a common sentiment among project managers is: “The problem I have with the release planning stage is that without clear requirements, the developers don’t like to give estimates, even with story points.”

On the other hand, a common sentiment among developers is: “Stakeholders don’t understand what they’re asking for, if they knew the complexity of our technology they wouldn’t be asking those questions.”

If developers don’t like to provide estimates, it is likely because others in the organization have used their estimates as though they are accurate predictions of future. Thus, when said estimates turn out to be inaccurate they are used as punitive metrics in conversations about “commitment” and “velocity” and “accountability”.

Point of order: NOBODY CAN PREDICT THE FUTURE.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.

This “team creation event” was a fantastic success for that particular department. What made it a success?

Everyone participating already had Agile training and experience. They knew what they were getting into and why they were doing it.

Everyone was encouraged to participate through the way the meeting was facilitated. No one felt like their opinion was ignored.

The meeting was long, but also time boxed. It wasn’t an open-ended discussion that could go forever.

It was in-person!!! Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.

It was honest: tough things were discussed including potential personality conflicts. This open discussion required expert facilitation.

Management was not involved in the decision-making during the meeting.

The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?

A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.

Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)

In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.

Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.

The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.

One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.

So, to make it systematic, here are the steps required to run a team creation event:

PREPARATION

Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.

The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.

The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.

In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group. Is it for a specific Program? If so, what is the objective of the program from a business perspective? It should not just be a one-time communication. This should come from the business Real Agility Coach.

The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations. These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.

TEAM CREATION EVENT AGENDA

The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.

Management stakeholders make their presentations to ensure that participants have a clear vision.

The business Real Agility Coach summarizes the vision presented by the management stakeholders.

The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:

People who want to work on that particular team’s goal (if such is set).

Everyone must be on a team.

Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).

Everyone starts self-organizing! Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams. These optimization opportunities should always be offered as suggestions rather than being directive.

As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.

Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).

The people/process Real Agility Coach closes the meeting. It is critical to record the final results of who is on which team. It may be easiest to get the teams themselves to do this before leaving the meeting.

FOLLOW-UP

The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.

The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone. Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.

Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.

A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.

Have you experienced an event like this? Did it work? What was different from what I described?

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

The Product Backlog is often described as the primary input to Scrum. The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog. In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog. And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role. I believe in just starting if you can. I even wrote a blog post about this a while back and I stand by it.

I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing. Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start. And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.

Past performance of the Development Team (not applicable to first Sprint)

Definition of “Done” (implicitly)

A newly-formed team often needs to address the following before the first Sprint:

Product Backlog

Projected capacity of the Development Team during the Sprint

Definition of “Done”

If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).

Product Backlog

Keep it simple. It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product. Get the Product Owner to blow these things out into a list. It doesn’t need to be a complete list. Just the most important things right now. A good test is to give the Product Owner 5 minutes. Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on. There are all kinds of techniques that can be used to order the Product Backlog. The simplest way is to just have the Product Owner eyeball it. If people are uncomfortable with this, then introduce the other ways. It doesn’t need to be perfect. It will get better and become refined and adapted as you go.

Projected capacity of the Development Team during the Sprint

Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%). If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post. According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).

Definition of “Done”

This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done. The team needs to know this before it can estimate the items in the Product Backlog as a team. Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.

Planning with the Product Backlog, projected capacity and Definition of “Done”

In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”. Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done. All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built. The team should try to create a set of tasks each of which are a one-person day effort or less. Count the number of tasks. If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog. If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Author’s caveat:

Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach. Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony. This is my other trick.

Requirements for team estimation (and planning):

Product Owner

The whole Development Team (i.e. everyone who will be involved in doing the work)

Product Backlog

Definition of “Done”

When team membership changes:

A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.

When team member allocation is adjusted:

Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.

Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.

WARNING:

The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.

Step 1 – What is our current velocity?

After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!

Step 2 – What is our current capacity?

As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:

50% Chris P. Codemuncher

50% Larry Legassifulunch

25% Beth Breaksidal

40% Gertrude Gamesthadox

40% Dana Deadlinedryver

The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:

8.5 x 50% = 4.25 days Chris P. Codemuncher

8.5 x 50% = 4.25 days Larry Legassifulunch

8.5 x 25% = 2.13 days Beth Breaksidal

8.5 x 40% = 3.4 days Gertrude Gamesthadox

8.5 x 40% = 3.4 days Dana Deadlinedryver

17.43 Total combined available days per Sprint

Let’s round that down to 17. That’s the number used by the team to understand its capacity for Sprint Planning. This is a powerful number for other reasons than what we are trying to get at here, but they are worth pointing out nonetheless. For generating the Sprint Backlog in Sprint Planning, this is particularly useful if each task in the Sprint Backlog is a maximum of a one-person-day. Therefore, this team should have a minimum of 17 tasks in the Sprint Backlog and these tasks should all be a one-person-day or less amount of effort. If the team has more than 17 tasks which are all about a one-person-day of effort, chances are the team has overcommitted and will fail to deliver the Sprint Goal. This should trigger the adaptation of the Sprint Goal. In any case, it provides the team with simple transparency that can easily be inspected and adapted throughout the Sprint. For example, with one-person day tasks, each team member should be able to move at least one task into the “Done” position every day and point to that movement every day during the Daily Scrum. Also, this team should be burning down at least 5 tasks every day. If either of these fails to occur, this is a clear signal for the team to inspect and adapt.

Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:

21 Velocity

17 Capacity

21/17 V/C

(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)

Step 3 – How much capacity do we hope to have in the next Sprint?

Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”

Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…

But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:

8.5 x 50% = 4.25 days Chris P. Codemuncher

8.5 x 50% = 4.25 days Larry Legassifulunch

8.5 x 50% = 4.25 days Beth Breaksidal

8.5 x 30% = 2.55 days Gertrude Gamesthadox

8.5 x 15% = 1.28 days Dana Deadlinedryver

16.58 Total combined ACTUAL available days in Sprint 1

16 Actual capacity (rounded-down)

21/16 Actual V/C

As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.

Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:

8.5 x 100% = 8.5 days Sally Supaspeshalis

8.5 x 100% = 8.5 days Chris P. Codemuncher

8.5 x 75% = 6.38 days Larry Legassifulunch

8.5 x 50% = 4.25 days Beth Breaksidal

8.5 x 30% = 2.55 days Gertrude Gamesthadox

8.5 x 0% = 0 days Dana Deadlinedryver

(Note: Dana is also the Scrum Master with plenty of other work to do for the team)

Step 5 – How do we adapt our planning in light of what we now know (assuming we now know something substantial enough to inform our planning)?

Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.

Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!

See you next time,

Travis.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

In a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program. While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams. This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams. Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals. These teams are responsible for delivering value—business results and quality. Individuals are committed to the performance of the team and the organization. Teams develop the capacity to self-organize and focus on continuous improvement and learning. A team is usually composed of people from various roles at the delivery level. For example, and IT project team might be composed of people whose previous* roles were:

Project manager

Business analyst

Software developer

Tester

Database developer

Team lead

User experience lead

Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support. Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals. Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix. The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority. This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process. Usually, these steps take one or two weeks each, but sometimes they take longer. A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks. In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them. In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team. Of course, to do this requires some investment of time. Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

See also the article on the Recommendations component of the Real Agility Program.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

I’ve been working for the past year on building the Scrum Team Assessment (yes, you can still go get it for your team 🙂 ). I’ve been doing all the work on it personally and it has been great fun. The best part of it has been that I’m back into coding. And, with that, of course I have had to take my own advice about Test-Driven Development and the other Agile Engineering Practices. But it hasn’t been easy!

I’m using PHP for the web front end, and Python with OpenERP for the back end. My testing tools include Selenium for Acceptance Testing and PHPUnit for unit testing. And… nothing yet for the Python back-end. This is still a sore point with me. Normally, I would find the back end TDD process easier… but OpenERP has been a HORRIBLE BEAST to use as a development platform. Well, I might exaggerate a bit on that, because it is really just the complete lack of well-written API documentation and sample code. Which is funny, because there are tons of open-source extensions for OpenERP written. Anyway, I don’t want to complain about it too much, because in many other ways it is a fantastic platform and I wouldn’t easily switch it for anything else at this point.

Back to testing. Last week, a client using the Scrum Team Assessment found a bug… and it was one of those ones that I know made them consider not using the tool anymore. Fortunately, our contact there has the patience of a Redwood, and is helping us through the process of fixing the system. How did the bug happen?

Because I didn’t do _enough_ TDD. I skimped. I took shortcuts. I didn’t use it for every single line of code written.

<Failure Bow>

The question for me now, is “why”? Fortunately, the answer is simple to find… but solving it is not as easy as I would like. I didn’t follow my own advice because I was learning about too many things at the same time. Here’s what I was learning all at once over a three week period in December when I was doing the real heads-down development work:

PHP and PHPUnit

Python

OpenERP (APIs for persistence and business logic)

RML (a report generation language)

Amazon EC2, RDS and Route 53

Some Ubuntu sys admin stuff

VMWare Fusion and using VMs to create a dev environment

Postgresql database migration

Oh, and refreshing on Selenium

Like I said, FUN! But, a bit overwhelming for someone who hasn’t done any significant development work since 2006-ish. As well, because of learning about so many things, I also didn’t have a good setup for my development, testing and production environments. Now I have to clean up. Finally, I also forgot about another important Agile Engineering practice that is used when you have lots of intense learning: the Architectural Spike.

I have to make sure that I take all that I’ve learned and create a truly good dev and test environment (because that was a huge hinderance to my work with both Selenium and PHPUnit). And I have to take the time to learn to do the testing in Python (I would love suggestions on a good unit test framework)… and go back over that code, even though most of it is simply declarative of data structures, and make sure it is well-covered by unit tests. Ideally, I might even consider throwing some code away and starting from scratch. One possibility I’ve considered is to get rid of PHP entirely and build the whole system with Python (I’d love some thoughts on that too!)

Why am I doing all this? Well, I really think that the Scrum Team Assessment is an awesome tool for teams that maybe can’t afford a full-time coach. It certainly isn’t a complete replacement, but I’ve poured my knowledge and experience into it in the hopes that it can help a bunch of people out there do Scrum better… and more importantly, create great teams that produce awesome business results and where people love to come to work every day.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing. The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book. There are also two links added at the end of the article. One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.