Tagged: Scrum

Marcus Aurelius on how to implement Scrum

Being an Agile coach I help organizations to improve their way of thinking and working based on Agile mindset, values and principles. Part of that is providing training on Agile and Scrum. I teach participants what Agile values and principles are, what Scrum is and what is is not, so as about Growth mindset, team-based organizations, collaboration, frequent customer feedback and customer value maximization. I usually get the same reaction about Agile and Scrum, especially from people from big companies. Their concerns can be summarized as “it will never work here”:

  • We need a collocated/cross-functional/self-organizing teams so it will not work here
  • We can’t release every Sprint because of regulatory requirements so it will not work here
  • We need a business-person with a lot of decision making power as Product owner but such a person might be a C-level so it will not work here.

It is a pretty common idea that in order to do Scrum (and be agile, broadly speaking) one needs to changes the organization so that it would be a perfectly Agile and its processes 100% compliant with Scrum guide. Who would not like to have all the Agile things in place: co-located team, autonomy and self-organization, continuous deployment, agile budgeting and all the other. The problem with this viewpoint is that it’s often too hard to do so much change at once. So it demotivates and leads to “this will never work here” attitude.

But is it really an all-or-nothing game?

Do we really need to be absolutely, 100% perfect?

I study (and practice) Stoicism, partly because I believe it’s a life philosophy that fits best for me (at least among those that I am aware of). And partly because it is a very practical philosophy, and it helped (and continues to help) me to improve my personal life, family relationships and work. One of the best advice on Scrum adoption (and any changes in general) I got from Marcus Aurelius. He was a Roman Emperor about 2000 years ago and wrote a diary that was later published and became a thought-provoking, guiding and inspiring book for many generations of thinkers. This is what he wrote in book 8 paragraph 32:

You have to assemble your life – action by action. And be satisfied if each one achieves its goal, as far as it can. No one can keep that from happening.
– But there are external obstacles…
Not to behaving with justice, self-control and good sense.
– Well, but perhaps to some more concrete action.
But if you accept the obstacle and work with what you’re given, an alternative will present itself – another piece of what you’re trying to assemble. Action by action.

This is an approach to organizational change that I believe in. You need to know what your vision is. For Scrum, the vision that you are aiming at is described in the Scrum Guide. Once you define your vision, the best is to aim at some possible step toward that vision. You take a step – the one that is possible. Then you observe. Probably you will open some new opportunities for action. Align yourself with your vision, and take the next step – the one that is possible with what you have. Repeat. Over and over. Action by action. Make a change. One step at a time. Inspect and adapt. What is important is to keep moving.

You don’t release every sprint? But you reduced release cycle from 18 month to 4. You don’t have a cross-functional team? But your testers started to talk with developers rather than just sending each other documentation. Your team is not 100% self-organized? But you agreed with your manager on some areas that your team has full authority rather than asking him for every smallest decision. So people say that you are not doing Scrum? The goal is not to “do Scrum” per se but to maximize value. Keep the Scrum guide in mind and keep moving.

You might never get to the ideal, but what is cool in the idea of continuous improvement – there is always something that you can make a bit better. So master the art of possible, and change for good. Action by action.

On zero refinement in Scrum

My friend Steve Porter recently twitted on Product Backlog refinement:  “Refinement isn’t an event in Scrum. It’s a concept. It’s not mandatory and there are no hard and fast rules for when and how much. Zero refinement is acceptable, as is spending a majority of your Sprint on it. Figure out what works for you.” My first reaction was a feeling of doubt, but Steve is one of few people who really understand what Scrum is (he is a Professional Scrum Trainer and a team member at Scrum.org – a home of Scrum).  So I decided to think that through and try to figure out what I think of that.
We need to clearly define what we are talking about, so I would like to start from a quote from Scrum Guide, that defines what Product Backlog refinement is:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Then I wanted to figure out the things we agree upon. Scrum Guide does not define Product Backlog refinement as an event. Rather it is an ongoing process. So we are in agreement on that. The same thing with acceptability of “spending a majority of your Sprint on it”; refinement “usually consumes no more than 10% of the capacity of the Development Team” and that does not mean that it should consume exactly or no more than 10%. So it looks to me as if we are in agreement on “there are no hard and fast rules for when and how much”
But when it comes to “zero refinement is acceptable”, I have a different opinion. Yes, Scrum is a framework that is used in complex environments, and complexity implies that everything is extremely context-dependent, and nothing is “one-size-fits-all”. One should approach things with curiosity and open mind, and try to help the team figure out what works best in their particular situation (and don’t forget to review the decisions, because things are changing, and solutions should adapt respectively). And yes, Scrum Guide does not require explicitly that a Scrum team should do Product Backlog refinement. What makes me disagree here is the very definition of refinement as “the act of adding detail, estimates, and order to items in the Product Backlog”.
If we define refinement in such a way, then “zero refinement” will mean that our Product backlog is set once and for all. We do not add any detail, nor estimates, nor change its order. And that contradicts the very idea of a Product Backlog as a dynamic entity that “evolves as the product and the environment in which it will be used evolves”. Moreover, theу idea that a Product Backlog can be fixed once and for all violates the definition of Product Backlog. Let we quote Scrum Guide once again:
The Product Backlog is an ordered list of everything that is known to be needed in the product.
[…]
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.
[…]
Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
So if one’s Product Backlog is not changing, then it is not a Scrum Product Backlog and therefore one does not do Scrum because “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”
I can imagine environments where such a backlog is possible, and that is probably something in a simple domain, and in that domain one probably don’t need Scrum (because one doesn’t need to inspect and adapt). Or it’s possible that a team just ignores changes or does not get feedback that could allow them to see that changes. Rephrasing an old joke. “If you don’t see any changes, you are right: you don’t see the changes.”
As Steve pointed out in our later discussion, there are (at least) two options to consider:
a) Some people suggest that refinement is specifically the act of the Product Owner and the Development Team working together on the Product Backlog. If a Product Owner updates Product Backlog items on their own, that’s not technically refinement.
b) There may be cases where a Product Backlog is very small and very loosely defined. It’s just a list of goals or experiments to run. In this case, the only work needed on the Product Backlog is adding new items or discarding unneeded items.
Regarding Option A Steve is not sure if he agrees with that view of refinement, but, as he says, “just because I don’t agree with it doesn’t make it wrong”. I would agree with him, taking into account definition of refinement in Scrum Guide: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog”. I would also say that this notion of refinement, when mixed with “zero refinement” idea, may add a lot of complexity. If Product Owner updates Product Backlog on his or her own, and Product Owner and the Development Team are not working together on the Product Backlog, this could mean that the only way Product Owner and the Development Team communicate about Backlog items is through Product Backlog itself. This might lead to all sorts of misunderstandings. I can imagine how that might work well, but such a way of communication lead to so many troubles that it is now among Principles behind Agile Manifesto (The most efficient and effective method of conveying information to and within a development team is face-to-face conversation).
Option B might potentially work, but also may bring a bunch of product troubles (miscommunication due to too vague Product Backlog items is just one of them, another possibility is a problem with fitting  Product Backlog items into a Sprint to have a potentially releasable Increment done by the end of each Sprint).
To summarize all of the above in three takeaways:
  • if your team does zero refinement, I would suggest reviewing team’s definition of refinement and team’s feedback mechanisms (including communications within Scrum Team) – there is a reasonable probability that one of those is not functioning the way it should be;
  • if a team’s feedback mechanisms are functional and the team has zero “ScrumGuide-ish” refinement (i.e. not adding detail, estimates, and order to items in the Product Backlog) – and it works well for that particular team – all good to them! As Steve says, “it’s possible and I don’t want people not trying it because of something they read in the Scrum Guide.” And,
  • before changing Scrum make sure that you are not changing it to hide the problems, but to solve them.

Remember the ignorance

I recently had a very interesting conversation with Steve Porter from Scrum.org. We discussed a Scrum team where developers are not pulling their work themselves. Instead,  it’s a senior developer who, during the Daily Scrum, selects which Product Backlog items will be worked on that day and who will work on them. This senior developer is a well-respected member of the Development Team. So the question was, should a Scrum Master do anything about it?

On one hand, Scrum guide does not explicitly require members of Development Team to pull their work on their own. Scrum Guide also states “no one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality”. So it looks like Development team is doing Scrum, and there is no need for Scrum master to intervene. However, there could be many possible reasons why this situation may require an intervention from Scrum Master. Here are two: the definition of Development team and Scrum Values.

Firstly, this situation may contradict the definition of Development team in Scrum guide. The Scrum guide does not describe Development Group. Rather Scrum team has a Development Team. I believe that the word “team” was used intentionally and one of the main reasons why Scrum is so effective is that it is based on “a team” rather than “a group”. By definition a team is “a group а people who share a common team purpose and a number of challenging goals; members of the team are mutually committed to the goals and to each other”. In Scrum context, we can consider delivering potentially releasable Increment as Development Team’s purpose, and Sprint Backlog as a set of challenging goals. But it’s hard to be committed to something that you did not take voluntarily. On the contrary, a situation when someone assigns a person work makes this person less committed to accomplishing this work. A commitment is one’s responsibility, but if one does not make a decision, he or she will not take responsibility for that decision. The best you can get in such a situation is an obligation, but not ownership. So by assigning Sprint Backlog items to Development Team members, a senior developer destroy a team’s ability to be a team. This situation might also violate the Development team equality principle: “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person”. But here it might be that “all developers are equal, but some developers are more equal than another”.

Secondly, this situation seems to contradict the Scrum values. We’ll start by a quote from Scrum Guide: “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” I have already described above how this approach can destroy the team’s ability for commitment. People do not personally commit to achieving the goals of the Scrum Team. This situation may also be a sign of lack of respect. Scrum guide defines respect such that “Scrum Team members respect each other to be capable, independent people.” But a situation when someone defines what piece of work one should do a given day is far from treating that person as a capable and independent (not to speak about showing respect). This rather may be a demonstration of a lack of trust in one’s capability. Such a situation is very toxic for team morale and performance.

Thinking all that I concluded that that team is not doing Scrum and Scrum Master should intervene by raising team’s awareness of what is going on an how this influences a team. Being pretty confident in my conclusion, I shared that with Steve, and his reply was: “be careful not to make judgments about how a Development Team decide to work. If you see behavior that you don’t understand or feel could be improved, approach the situation from a position of curiosity. Remember, the people closest to the work are in the best position to decide what’s right and wrong.” I thought to myself: “Man, you were the one speaking about beginner’s mind and importance of context, and you’ve run to the very mistake that you were teaching to avoid!” Working for a long time for big companies, I was literally paid to have the answers. At some point in time, I realized that my success was due to asking questions, and helping my team to find the best possible answer, rather than bringing with my solutions. That was the reason why I started to learn about Agile, Scrum, self-organization, team, etc. In general, that is why I do not stop learning things. And that is what I am teaching others. “Remember the ignorance” – that was my advice for my students. And now I failed to live up to my own advice. That was really sobering!

When working with people things are rarely are the way they look at the surface. Every situation, every problem is very context-specific, so you can have different solutions for two (seemingly) similar questions of the same person – because these two questions sit in a different context. So just looking at the surface is not enough even if things look obvious, because there is a good chance that they are not. It is very rewarding to act “like a smart guy” and have a clear answer to any question. Being an expert. As Mike Maddoc writes in Forbes blogpost “As experts, we get paid more, trusted more and sometimes even honored more. Our parents are proud, our partners are proud and sometimes even our kids think we’re cool.” That leads to a very straightforward thinking. We know too much and forget Socrates lesson that we know nothing. And that leads to wrong decisions, sometimes with bad consequences, sometimes with catastrophic ones.

And I do not want to be that kind of person.

I want to avoid an expert trap. I choose to have less confidence in what’s best, choose to be curious, ask questions and be open to learning the answers, and by doing that to be able to co-create a better solution in collaboration with people involved. I will ask myself “What else is there? What am I missing? What could lead me to an opposite conclusion?” So I wrote a mantra on a card that I have now in my wallet, and I re-read it several times a day.

REMEMBER
       THE
         IGNORANCE.

Why Product Owner needs courage

I had a conversation with Steve Porter from scrum.org on dysfunctional interactions between Product Owner and Development Team in Scrum. This discussion reminded me of an idea that I learned from Jordan B. Peterson that real trust is an act of courage. In this post I am trying to unfold this idea applied to Scrum team.
A newly trained Product Owner usually is inspired by ideas of self-organization believes that a Scrum is a best way to solve complex problems, and that self-organizing Development Team is a best way to do right things right (and fast). He acts as Agile evangelist, working to promote Agile as much as he can. Based on this beliefs and inspiration he trusts Development Team to do what is needed to deliver Sprint Backlog and reach Sprint Goal. You probably have seen such a person. Many will say that having such an inspired Product Owner is critical for Scrum success.
What inevitably happens next? Development team fails. Sooner or later it happens to each and every development team (even if they are extremely undercommiting and overperforming 🙂 So this failure raises some questions for Product Owner. Why did they fail? Did I trusted them enough? Or maybe I trusted too much? Why are they destroying my trust? There is a good chance that Product Owner had some commitments regarding product, and his stakeholders are truly unhappy. Product owner feels bitter (and maybe resentment).
Did he really trust his Development Team?
If that trust was based on naive view that a team will be able to do anything if trusted, can we consider that a trust. Or it’s just a naivety? Trust is a necessary precondition for a team to reach peak performance and engagement, but it does not guarantee success. We are living in a complex world, and working to deliver value solving complex problems. There is always something we don’t know. There is always a change. There is always something missing. And this mean that sometimes we inevitably fail.
Next step for Product Owner is to think of what to do next. He might think “How can I prevent this from happening again”? He wants bad news early, so that he could get prepared (and prepare his stakeholders). He might decide to check Development Team regularly on how are they doing and if they are doing what he expects them to do.
Do they work on most valuable backlog item?
Are they still within their estimates of efforts?
Do they solve a problem in a way it should be solved?
This creates micromanagement habit, and eventually such checks become a daily (or hourly) status meeting.
What will happen to Development Team? First, such questions, even if they look innocent from Product Owner perspective, probably perceived by Development Team not as questions, but as requests. Product Owner’s role is associated with power and authority, and people have tendency to listen to everything said by empowered figure as if it is a demand, not a question. Next, Development Team will feel that they are not trusted, and this feeling will result in more and more disengaged team. Moreover, team loses it’s ability to self-organize: developers stop making their own decisions because Product Owner will decide anyway. In such a way, Product Owner becomes a bottleneck. And while he takes more and more decisions, team has less power, so he sees that he has to decide more. Less trust leads to fewer decisions that leads to worse decisions, which leads to less trust. And so it goes.
Some Product Owner will stay stuck on that level. “They can’t be trusted – they are too immature” view is wrong! They cannot mature because they don’t have opportunity to fail and learn. It is not the team. A Product Owner is the one who is immature.
What is an antidote for that? The answer is courage. It is one of five Scrum values, and I would say that it’s perhaps the most important one. If Product Owner has courage, he might think something like “OK. If I will trust them to do the work on their own, they will sometimes fail. This will be painful for me (and probably for Development Team also). But we need trust to move faster, to deliver more value, to deliver best possible solutions”. So he decides to be courageous enough to trust Development Team knowing that they will sometimes fail.
This is what a real trust is. It is a trust that is based on wisdom, not just some naive expectation that people succeed if trusted. Yes, if I will trust them, there is a risk. But I am taking this risk as necessary precondition for success. This is  a courage that a Product Owner should cultivate. And one of the key things that Scrum Master could do to server a Scrum Team – help everyone in a team to nurture enough courage for such kind of trust. Feeling vulnerable, but having enough courage to trust each other. This is a trust that makes Scrum so effective in dealing with complexity and allows Scrum Teams to thrive.

Why Scrum does not work (and what can we do about it)

Scrum is the most popular agile framework. Period. If we look at VersionOne 11th State of Agile report, Scrum is praciced by 58% of respondents (68% if we summ up Scrum and Scrum/XP hybrid). Among scaling frameworks Scrum although dominate: while Scrum-of-Scrums has 27% (1% less than Scaled Agile Framework), Scrum-of-Scrums, LeSS and Nexus combined have 31%. I believe that there are two main reasons for such popularity. First, Scrum is simple to understand and comes with a clear recipe – Scrum Guide. Second – it works by helping team to succeed in value-driven agile delivery.

So it looks like within a first paragraph I have reached the conclusion that contradicts my initial claim made in post heading. Well, no. Scrum really works – but only if you succeed in its adoption. I do believe that Scrum is extremely powerful, and its power emerges out of tight interconnection of Scrum roles, artifacts and practices. Its holistic nature emphasized in Scrum Guide itself: “Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.” This means that the one and only way of getting full benefits of Scrum is literally follow the Scrum Guide. This does not mean that you cannot get at least some benefits from using part of Scrum (often referred as “Scrum, But”), but a) one should not call this thing “Scrum, and b) actual results are highly unpredictable.

Why would you want to implement ScrumBut? Well, assuming that you are not ignorant, the main reason would be “It contradicts our organizations culture.” Among main challenges of Agile adoption “Company philosophy or culture at odds with core agile values” is at the top (and rising) for at least 6 years with 63% last year. So in Agile (and Scrum) adoption key question is “How can we change organizational culture so that it will embrace (or at least will not contradict) Agile values and principles.” One possible answer to that question is known as  Larman’s 5th Law of Organizational Behavior: “Culture follows structure.” If you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. Make people act differently, they will adapt their mindset so that this new way of doing things will be aligned with their way of thinking about their actions. This is what Scrum does (when fully implemented) – it creates a structure that forces organization to become Agile.

I believe that Scrum works exactly like that – not only changing the way of doing, but changing mindset and belief system of people involved. But (and it’s a big butt!) putting people in new environment with new rules is painful1, so as changing one’s mindset. And when choosing is between two painful paths, people tend to pick the one that associated will less pain. Or at least the one that they think will bring less pain. 2.

This leads us to understanding a key reason for Scrum failure: it just requires too much change (and too much pain) to do the Scrum. If an organization’s culture is close enough to Agile, implementng Scrum works is like magic: it will add necessary tension that will force cultural changes, leading to success of Scrum adoption and Agile transformation. But as soon as the distance between organizational culture and Agile becomes too big, enforcement of Scrum framework does the opposite. Now it’s not just structure vs culture, it’s structure vs culture and pain aversion combined. And we all know how much energy people can direct on pain aversion. So Scrum is doomed to fail, and there are basically two ways how events can unfold after that. One is stepping back to what is, claimimg that “Scrum (and Agile) does not fit our company”. The other is changing Scrum so that it won’t bring so much tension (and pain). The latter leads to all sorts of “ScrumBut”s and Cargo Cults, and in best case will lead to frustration, irritation and unproductive behavior (and in worst case it can lead organization to total disaster).

So Scrum does not work when forced on organization with poorly compatible culture. Does this imply that Scrum is bad? No. But what it does imply is that literally following Scrum Guide is not suitable for every organization, and Scrum Master has to carefully think out a way of Implementing Scrum. This could possibly mean that we do not do Scrum from the very beginning, and trying to gradually approximate our structure to Scrum, and avoiding “get it right from the first time” attitude.

This is a first of a series of posts on my perception Agile coaching, it’s challenges and faults. By no means I’m claiming that I have all the answers. Rather, I hope that by writing this (and by reflecting on your feedback) I could think through this and maybe find some plausible answer on the main question of agile coach: How to help an organization make it’s way through successfull Agile tansformation. In next post I will consider some of the questions that a Change Leader should consider designing a plan for Agile transformation.