There’s a Lion Lurking in the Organization

(Or is agile just another way of hiding it away?)

Imagine the following scenario

Fred is a senior developer. The team is doing Scrum for about 10 sprints now, and the ceremonies are kind-of getting into a routine. The team is committing for work to do, and delivering more-or-less what they promised. And yet, Fred is not a happy chappy.
The team is coming to their third release, and there are talks that regression period must be on time, on track this time.
In his frustration, Fred talks to his Scrum Master, expressing his concern that developers must do regression testing yet again in the upcoming regression period. Clearly developers should do coding, and testers should do the testing.
Joe, the Scrum Master reminds Fred that regression is for the entire team, not just for testers, and that they are all in the same boat, and that by coding away during regression they are merely adding more technical debt to an already potentially unstable release.
Fred walks back to his desk, muttering “right; and my testing skills are so good, that all bugs will be uncovered. Such a good tester I am”.

What just happened here?

What are Fred and Joe really talking about? What aren’t they talking about?
Given the conversation of these two individuals, what can we say about the atmosphere in this team?

Teams, Organizations and Lions

There is a lion lurking here.
A normal person reaction to seeing a lion would be: increased alertness, increased heart rate and increased perspiration – the automatic physical reaction required for survival in the face of danger. This is vital for survival, yet not a pleasant experience.
Therefore, a normal person, having the knowledge that a lion is lurking would act to avoid being seen by the lion: Acting cautiously, refraining from conspicuous and sudden gestures.

Let’s relate this back Fred and Joe. Fred might be trying to say: I’m a damn good programmer, and by doing testing, I will be exposing my weaknesses. This is something I am not prepared to do!
Joe, on the other hand, is hiding behind Scrum (teamwork, technical debt) in order to avoid Fred’s issues. He is using Scrum as a defense mechanism against dealing with what Fred has to say.

The thought of confronting these covert issues provokes anxiety. As if Joe is telling himself: I am afraid that if I talk to Fred directly about his subjective experience of being a tester, it may feel as if a lion is about to attack me. I am not prepared to handle such an experience.

Of course, both Fred and Joe don’t necessarily articulate these thoughts to themselves. This, in itself, is too frightening. So they both unconsciously use their survival mechanism not to wake the lion lurking in the grass:
Fred resolves to focus on developing new stuff; Joe is using Scrum to get Fred to do testing, as he thinks the entire team also should.

Dealing with Lions

Is Scrum to blame here? Is Scrum in particular, and Agile in general doomed to fail in such situations like all other organizational methodologies?
I think not.I am paraphrasing on an expression used in Diana Larsen’s and Ester Derby’s book: Agile retrospectives – making good teams great: Agile belongs to a group of management frameworks that inherently advocate the use of “the ‘F’ word” – Feelings.

Fred is trying to say: I am afraid that by being a tester in the regression sprint my weaknesses will be exposed. I feel compelled to avoid this in front of the entire team.
Joe, as a Scrum Master, should be equipped to identify these Feelings; to sense that we are talking about regression, but, in fact, in the sub-text Fred is trying to say without words that he feels his own lion is lurking in search of him.

Many kinds of lions are spotted in various organizations. For example: Support (“handling this P1 call is a matter of life and death!”); Over glorified business goals (“get this demo wrong, and we can all start looking for a new job”); Coercive management (“don’t mess this up, or the boss will be on your tail from now to eternity”); and so many more.

One of the aspects I like about agility is that it advocates being equipped with the knowledge and experience to identify such emotional blind-spots. Training programs, coaching, mentoring, retrospectives – are just a few examples that invite the development of such skills.
In this post I will focus on just one: feedback.

Feedback

Organizations tend to treat feedback as a periodic activity, taking place one to four times annually. In our example, Joe would be expected to fetch his “little black book”, and record the “regression sprint incident”, and “take it to the positive place” during employee review by telling Fred something like: “you should understand that testing during regression is a team activity. Let’s set a personal goal for you to get more involved in regression testing, and we’ll review it again in six months. What do you say?”

This is like telling Fred – you should confront your lion! You’ve got six months to either kill the lion or make it go away or become friends with it. Hmmm…, not something most sane individuals do willingly.
Conversely, effective feedback giving and receiving is about providing continuous, relevant, specific, actionable feedback.
The effective feedback approach would commence along the lines of:
“Fred, I sense that there is something else bothering you. Is this a good time to discuss this?”
And, if the invitation is accepted, continue to something like:
“It feels to me that participating in regression testing makes you angry. By not participating in this team activity, you will be creating a problem for the team and for me as well. For example, adding new code during this period will create more testing effort for the rest of us.

What can I do to help you join in, without compromising your professional standards?”
Such a conversation: a) addresses the feelings involved; b) makes it a joint issue; and c) invites a conversation on the specific issues, rather than a general “this is Scrum” lecture.

How to give and receive feedback

Luckily, giving and receiving feedback is an acquired skill. If you want to learn more, there are many resources on this subject. For example, a short Google search revealed this good webpage: http://managementhelp.org/communicationsskills/feedback.htm

Does this make sense? Do you think this is achievable? Have you tried such feedback techniques?
And can you think of your own lions lurking?

Learning do deal with such “lions” is easy, if you have the right tools. One such tool is a Scrum Master Week, where you will have the opportunity to learn and to practice, and to chase away some “lions” in your team.

Photo by cheetah100 source: http://www.flickr.com/photos/devcentre/327960789/

Scrum Master is Not Merely a Facilitator

For some reason, for many the essence of the Scrum Master role boils down to: “remove impediments for the team” or “is responsible for the Scrum process”.

Others declare that “the Scrum Master is a kind of a PMO”, or “a facilitator for the team”. Not that it is not part of the Scrum Master role – but it certainly is not the essence.

Furthermore, such statements are demeaning, in my view. Strong word, and yet, making statements such as the above, to me, indicates that the speaker may not yet understand what agility really means.

And please don’t get me wrong – it’s not that I think that facilitation is something to look down at. On the contrary – facilitators can save a conference from failing miserably. Similar arguments can be made on PMOs.

These roles and professions are important and significant in their own right. But this is not the essence of the Scrum Master. Moreover, it takes courage to step out of these simplistic views of the Scrum Master, and delve into the complexity of becoming one. What follows is highlighting the other, more important, aspects of being a Scrum Master.

Let’s begin with the plain definition. The Scrum Guide (pages 6-7) explains the role of the Scrum Master. Here’s the relevant text from the guide – I have highlighted a few parts in bold-italics.

I am pointing these parts out to emphasize that Scrum Master is about leadership, understanding human interactions, and making interventions to promote a certain set of values and principles (referring to the Agile Manifesto).

The Scrum Master

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

  • Finding techniques for effective Product Backlog management;
    Clearly communicating vision, goals, and Product Backlog items to the Development Team;
  • Teaching the Scrum Team to create clear and concise Product Backlog items;
  • Understanding long-term product planning in an empirical environment;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Teaching and leading the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

This passage talks about teaching, coaching, understanding, servant-leadership, all in the context of profound knowledge in the domain of agility. In the terminology before Agile we would call this a domain-expert and an experience manager.

Well, what is the difference between the Scrum Master and a traditional team leader or development manager?

I am adding here two video clips that suggest what that difference is in my eyes. Both videos have nothing to do with software development. Nor do they directly relate to leadership.

The first video is David Foster Wallace’ commencement speech at Keyon University in 2005. It is a beautiful description of the attribution bias as it affects us in our daily life, and how our unconscious default settings get in our way of seeing other options of our reality.

 https://www.youtube.com/watch?v=DKYJVV7HuZw

The second video is Hedy Schleifer’s The Power of Connection talk in TEDx Tel Aviv, 2010. It is about space, bridge and encounter between people. 

The context of these videos is that if you wish to be coaching, teaching, leading and planning using empirical data, it is crucial to understand that what you see as truth may be just your default settings – and that you have a choice to see another’s truth; that by violating the truth of the other you are contaminating the space between you, making it impossible to have a dialog until that space is cleared; and that as a Scrum Master you should appreciate this space, to make a bridge in order to have an encounter with other members of the team and of the organization.

Not that facilitation is unimportant. Or that removing impediments is not something worthy investing time and effort in. Just that a Scrum Master is much, much more than that.

Not that it’s easy. It requires discipline, and awareness, and a great deal of learning. If you want to get to the next step in being a great Scrum Master, please join our one-day Advanced Scrum Master workshop. You may register for any of our available courses and workshops here

Photo by OregonDOT, source: http://www.flickr.com/photos/oregondot/6235421713/

Velocity (or how fast does your car go?)

One of the key elements in planning in Scrum is basing your forecast on Velocity. In contrast to cars’ performance, the Velocity used in Scrum is not a performance-indicator. Rather, it is a parameter used towards calculating a forecast for a team’s or a project’s short, medium and long term.

In kinematics, velocity is the rate of change of the position of an object, equivalent to a specification of its speed and direction of motion. For motion in one dimension, velocity can be defined as the slope of the position vs. time graph of an object. Speed describes only how fast an object is moving, whereas velocity gives both how fast and in what direction the object is moving.[1] If a car is said to travel at 60 km/h, its speed has been specified. However, if the car is said to move at 60 km/h to the north, its velocity has now been specified. To have a constant velocity, an object must have a constant speed in a constant direction.
Source: Wikipedia, http://en.wikipedia.org/wiki/Velocity (emphasis in the original)

Not surprisingly, the photo chosen by the authors of this Wikipedia term is this:

How fast can your car go? Put it to the test in optimal conditions, and measure it. For example, take the car to a race track, measure the top speed it can reach, and – voila! What you might get is along the following lines (emphasis added):

Performance
The Enzo can accelerate to 60 mph (97 km/h) in 3.14 seconds [12] and can reach 100 mph (160 km/h) in 6.6 seconds.[7] The ¼ mile (~400 m) time is 11.0 at 136 mph (219 km/h) and the top speed has been recorded to be as high as 355 kilometers per hour (221 mph).[13] It is rated at 12 miles per US gallon (20 L/100 km; 14 mpg-imp) in the city and 18 miles per US gallon (13 L/100 km; 22 mpg-imp) on the highway.
Source: Wikipedia, Enzo Ferrari,http://en.wikipedia.org/wiki/Enzo_Ferrari_(automobile)

Alas, when we are referring to velocity in agile planning, we mean something slightly different. When referring to performance of cars, we relate to a measurement: how fast can this car go?
When we come to plan, we want to know how fast does this car (or team, or project) go?
Of course, now this brings into context another aspect of velocity, being direction – how fast does this car go towards the desired destination?
Using a similar analogy, how fast does the Enzo Ferrari go in conditions as depicted below?

Traffic congestion is a condition of road networks that occurs as use increases, and is characterized by slower speeds, longer trip times, and increased vehicular queueing. The most common example is the physical use of roads by vehicles. When traffic demand is great enough that the interaction between vehicles slows the speed of the traffic stream, this results in some congestion. As demand approaches the capacity of a road (or of the intersections along the road), extreme traffic congestion sets in. When vehicles are fully stopped for periods of time, this is colloquially known as a traffic jam or traffic snarl-up. Traffic congestion can lead to drivers becoming frustrated and engaging in road rage
Source: Wikipedia http://en.wikipedia.org/wiki/Traffic_congestion

If you were to set out in your Ferrari on a journey on the Delhi road depicted above, and I was to embark on the same journey at the same time with my 2CV, by how much time would you beat me?

Let me help you in getting the right answer:

Driving your Ferrari you set on a 10km journey, driving 5km/h in nail-biting traffic conditions. How much time will it take you, providing that traffic conditions are more or less static (quite literary in this example)?

As we have learned in elementary school, Time=Distance/Speed, so this short journey would take you about 2 hours. My 2CV (if I really had one 😉 ) would do it in about the same time.

Coming back to software development teams, Given that the team is developing 10 things in a two-week period, and we have a backlog of 50 things left to do, we can comfortably forecast that it will take the team about 2.5 months to finish this work.

It doesn’t matter how the scope was originally estimated, how well or Ferrari like the team is, or how brilliant or Schumacher like being your Product Owner and/or Scrum Master. All we want to do is to empirically check how fast the team is going towards the goal in order to plan our journey.

Just replace Distance with Scope, and you have the answer.

With that in mind, you can make a relevant forecast on the project:

Velocity = [Done Scope] / [Elapsed Time]: What is our velocity?

By this we obtain the value of the parameter to set in answering the questions below:

Time = Scope / Velocity: How long will it take us to complete the desired scope?
Scope = Time * Velocity: How long will it take us to complete this project?

Note, that Velocity is not necessarily a one single parameter value used in all kinds of forecast horizons. In fact, typically you will need different parameter values for different contexts:

[Team Velocity] = [Done Stories] / [Number of Sprints]: What is our team’s velocity?
[Project Velocity] = [Done Features] / [Number of Releases]: What is our project velocity?
[Portfolio Velocity] = [Done Themes] / [Year]: What is our portfolio velocity?

Note also, that the above is not applicable for everyone. One organization may need to use [Done Epics] / [Quarter] to calculate their projects’ velocity, while another may need to use[Done Things] / [Day] to calculate theirs.

What happens when we treat Velocity as an indicator of our capability, rather than as a parameter based on empirical evidence?

“Traffic congestion can lead to drivers becoming frustrated and engaging in road rage.“

Paraphrasing on the above, “Slow project’s progress can lead to managers becoming frustrated and engaging in team rage.“

At this point it doesn’t matter why the progress is slow. It is more important to acknowledge that this team is now slow. Only after planning based on the current speed and direction of the team, can you try to alleviate some of the obstacles to increasing the speed. Some of these reasons may (or may not) include:

  • The team is occupied with a lot of support issues, diverting from the project goal (analogous to road-works)
  • The team is dependent on one or more other teams, leading to slow delivery of done things (analogous to congestion due to junctions and intersections)
  • The team is working on too much in parallel (analogous to congestion due to exceeding road capacity)
  • The team is working very hard, but on things not related to the project (analogous to driving very fast but in the wrong direction)
  • The team is pushed too hard, leading to working too fast neglecting quality and capability (analogous to speeding beyond road conditions)

There are many other possible reasons. But when one is stuck in a traffic jam, and getting all worked out about it, one tends to ignore the objective, empirical, conditions, and focus instead on the subjective, intrinsic, emotional condition. Similar things happen in projects.

Ten Tips for the New Scrummer

What makes a good Scrummer? Well, if I knew an exact formula, I would be too busy selling it to Scrum-wannabees than writing tips about Scrum 😉

On a more serious note, the differences between organizations is so great, that any ten tips will never be good enough for all.

Nonetheless, I’ve gathered some of the things I found helpful in early stages of Scrum adaptations.

 I hope that many will find this useful, since ‘Early’ is also organization specific – some teams I’ve encountered have become self-managed in less than 10 weeks, whereas other teams still struggled with the basic concepts after six months (and more) of doing Scrum.

So here it is – my Ten Tips for the New Scrummer:

  1. Start with a project small enough to become a success, yet important enough to attract decision makers.
    It is not uncommon to see organizations start with multiple concurrent teams going Scrum, which makes the transition effort much greater than required. Instead, generate success by building a Scrum team that will give management the ‘appetite’ for more.
  2. Celebrate small successes.
    Focus on what’s working well. Peel-off all the cynicism that we so frequently meet in IT organizations, and find that people still love when told that they are doing good.
  3. Appreciate that Scrum is a very different than traditional software development projects.
    It is unrealistic to expect people who didn’t do Scrum before, or are fairly new to Scrum, to adapt to concepts that may seem counterintuitive at first.
  4. Read the Scrum Guide. If you’ve already read it, read it again after a while.
    This is a great concise description of Scrum, and you’ll learn something new with each time you re-read it.
  5. Speak of forecast, and refrain from talking about commitments.
    There are good reasons why the authors of Scrum chose ‘forecast’ as the team’s indication of what they will achieve in an iteration.
  6. Start-off with sticky notes on a wall or whiteboard, and postpone choosing an electronic Scrum tool for as long as you can.
    Deploying a change-request on a physical Scrum board costs almost nothing. Asking for a change request on a commercial tool might block you for a long time. Making your own tool – unless you plan to sell it for big bucks – don’t do there!
  7. Learn. A lot.
    The team you are a member of should expect itself to inspect-and-adapt indefinitely. What better way do you have than increasing your knowledge to have great ideas for your retrospectives? Read books, attend courses and workshops, read blogposts. The return on this investment is priceless.
  8. Learn to trust relative estimations.
    Learning to estimate and to continuously plan in a way that reduces overloading teams is critical, and one of the hardest transitions from traditional software projects. Relative estimations are key to letting go of unrealistic plans.
  9. Excel in your engineering practices. No matter how well you do Scrum, if your testing cycle is too time consuming, if the feedback-loop on writing new code takes too long, or if your coding standards are inadequate for short iterations – you will hit a brick wall without paying your technical debt.
  10. What are your 10 tips?
    Really, what ten tips would you give someone who is thinking about doing Scrum?
    If you can’t come up with ten good tips, either you’ve got more learning to do, or you are going through a stressed phase and need to let go, or maybe Scrum is not right for you. Whatever the reasons, if you want to succeed in Scrum (and agile SW development in general), find ways to become passionate about it.

Of course I could be writing fifty or a hundred tips or more: invest in agile requirements, sharpen your Definition of Done, how to decide on the Iteration length, Always have a well-groomed backlog for Iteration start, … I arbitrarily chose a good selection of important ten tips.

Wanna give Scrum ago and not sure how? Start with a course. It will take you through the paradigm shift that comes with agile, you’ll get to try it out in a workshop setting, and it’s fun. You’ll be far more equipped for your first Sprint than any blogpost you’ll read. Contact us if you’re not sure.