Could a Rugby player be a good Scrum Master? Let’s see what happens…

Today’s post is related with Scrum Masters. Well, in this case with a specific type of Scrum Master.

You might be asking why I’m writing about them, since I never wrote anything related with Scrum Masters. Well… Today I have a funny reason.

Today, I had a friend from work (Melvyn Bulkes | Agile Coach) that during our coffee break he said that he would like to share with me a really funny video about a crazy Scrum Master that he found on Youtube. At the beginning I didn’t believed him until I saw the video that he was talking about. The video was so great and funny that I decided to share with you too.

So, to start I think that we need to know the origin of the word Scrum.

“A Scrum (short for Scrummage) is a method of restarting play in rugby that involves players packing closely together with their heads down and attempting to gain possession of the ball.” [1]

And since we are talking about Scrum and Rugby, what do you think that could happen if we had a Rugby player as Scrum Master?

Let’s see what happens…

Did you enjoy the video? Now I have a quick challenge to you that comes down to one question only:

  • What do you think about this Scrum Master? 😉

References:

[1] Wikipedia | Scrum (Rugby)

 

Adopting Agile Scrum (With caution) by Bogdan Suteu

Some time ago (November Last Year 2015) I’ve challenged a friend that is a Scrum Master (Bogdan Suteu) to write an article sharing some of his past experiences.

The result from the invitation was that he accepted the challenge and today I’m sharing his article as invited writer from this Blog.

It’s a really interesting article since we have some good points that we should keep in mind when we are helping a team or business during their transition to adopt Agile Scrum.

Having said this, please find the article below:

Nowadays, everyone uses the word “Agile”, “We are Agile”, almost to the exhaustion. But my question is… Do they know and understand what they are saying and what it means?

For that, I must explain you what is in my mind!

What makes any business powerful and competitive is their ability to constantly adapt to market change, while delivering quality products. Agile Software Delivery with its Scrum flavour give us the tools for having high performant teams with the availability to have a fast, high quality and perfomance delivery this way being able to achieve highest customers satisfaction.

Nevertheless, being transparent, adaptive, responsive to change and able to deliver at pace may be everyone’s dream, and yet a lot of teams and business are reluctant in adopting an Agile Scrum approach for Software Delivery.

As a result, I truly believe that ,we shouldn’t use Agile because is the new buzz word in the industry and because everyone is using it. We should use Agile Methodology in order to survive in this industry, but most of all be competitive and be ahead of the competition. Yes, that’s right. To survive in this wild, dynamic and competitive market/world. So, if you really want to succeed, you need to be able to get outside your comfort zone and take actions.

Agile is much more than having iterations, a definition of done, product backlog refinement meetings and so on. Agile means a cultural change at an organisational level, where people start to take ownership of their commitments and actions, and also, start to reflect on the way they think and work.

In the context of Agile Scrum adoption, there is no “smooth sailing” all the time. From my experience by working with scrum teams, I identified some anti-patterns that can make everyone transition/adoption more difficult.

1) One pitfall is to implement Agile for solving problems that don’t require Agile in order to be solved (Depicted below), on top of this, create performance metrics focused on data that is not accurate or reliable. Taking actions based on those metrics, will lead to a failed Agile transition/adoption.

Applying Agile Framworks

2) Trying to change every single issue that you’ve found really quickly, can lead to failure. Agile comes with a lot of benefits but also creates a lot of transparency, awareness and bad pattern revealing. Setting realistic actions and timeframe for implementing them will make people to be open and to get outside their comfort zone easier.

3) Agile Implementation & Support must come from top to bottom in an organisation. People need to be encouraged to share their lesson learned, and to feel that every mistake has the benefit of generating feedback &more powerful teams. Removing the “pointing finger/blaming culture” and trying to promote team spirit together with a culture of winning together / loosing together must first come from the top management. Do not be afraid of failing, but learn from your experience and each time, take actions.

4) Micromanagement days should be over! We should have small, but solid steps in creating self-organizing teams that can deliver valuable software each iteration. The management should create the safe environment and act as an enabler for those teams.

5) The term of a Cross functional team can be really misunderstood. Try to encourage “T shaped people” to step in. For example, one backend team member can change a label on a contact form. Encourage those types of inter-technology mix. Do not abuse of that from the very beginning, but make sure that you have willingness needed in the team.

6) First and foremost always try to keep delivering High Quality. Try to reach a sustainable pace while delivering high quality products. What’s not done, almost done or done but with “minor” defects (according to team’s definition of done) should be moved back into the project backlog. Try not to split established units of work or to create defects just to cover for “almost done” work. This is just enormous source of debate and politics. And it’s misleading for everybody.

7) Even if we implement everything with caution, with small solid steps, eventually Agile is not for everyone and we can expect that some people will not be on board. It demands an extra effort to leave comfort zone and maybe leaving your ego at the door.

8) Be flexible and patient. 😉 That’s so easy to say, but if you want to have most of the crew on board, you need from time to time to adjust and refine your agile processes. Change the retrospective format, cancel a product refinement meeting in a busy day, bring chocolate to the retrospectives, and be sincere and empathic.

So, is your organisation up to the challenge?

My feedback is that is really an interesting article showing his past experience and point of view. I hope that you enjoy reading it like I did.

The Scrum Year Retrospective by Nuno Gouveia

Today, is the last day of the year 2015 and there is nothing better than talk about Retrospectives. Having this said, this time I’m not writing one of my articles but instead I would like to share with you an article written by my friend Nuno Gouveia (Scrum Master from the Avengers Team).

After reading his article “The Scrum Year Retrospective” I thought that was really great to share with you their idea on how they could keep improving as well their experience regarding the Scrum Year Retrospective. Not forgetting the outcome results and feedback from this experience.

For me it’s really amazing when we see teams with this innovation spirit. In other words, not having afraid to fail and with continuous improvement as a team value.

Having said this, please find the article below:

Background
I’ve been acting as Scrum Master for my team (Avengers) for the past few months. Just to give some context, we are a team with some experience with Scrum and some of us have been working together for about 2 years now. Our retrospectives usually have a lot of good discussions and I like to believe that we are not the type of team that sweeps stuff under the rug. Our biggest problem is really that sometimes we discuss so much that we start deviating from the issues at hand. With that in mind, on my first retrospectives as a Scrum Master I tried not to change too much from what was the routine retrospective (+/- board with post-its) and focused instead on trying to not let the team scatter too much on the issues being discussed.

For the past 2 sprints I’ve been working with another team member that is also acting as Scrum Master, so we can say we are a kind of a Scrum Master’s team. The experience has been very good and last sprint, we had a great idea for a retrospective and this post is to share that experience.

The idea
The idea was to do a year review or year end retrospective. This seemed a great idea but there was a big problem: if sometimes in the sprint retrospective we have a hard time remembering everything that happened in the last 2 weeks, how would we remember all that has happened during one entire year? To solve that problem we had the idea to do a year timeline that could represent all the main events that had happened during that time. So a couple of hours before the retrospective we (the Scrum Master Team) tried to capture the most outstanding events from each sprint. We also decided to take screenshots from the most important product features we developed. We assembled the timeline on a big paper just a few minutes before the retrospective and then called everyone into the room (the result is the image in the cover of this post).

Year Retrospective

We started by explaining what was going to happen to the rest of the team. We told the team that besides our usual sprint retrospective we would also do a retrospective of the entire year. After that we unveiled the year timeline and everyone looked quite surprised! We went over the timeline together and while at it we decided (with the team’s input) to add the time of the year when the team new members joined in. After that we gave everyone around 10 minutes to write post-its for good and bad things that had happened during the last sprint or the entire year.

Results
There were a lot of post-its both from the last sprint and from the entire year and that generated a lot of discussion, and it was the first retrospective where the number of post-its for good things exceeded the bad ones! It was very good to revisit some old discussions and try to get closure in others. We have been improving as a team with each sprint retrospective, but this was a totally different experience that allowed us to step back and realise how far we had come since the beginning of the year.

Conclusion
In the end it was an amazing experience and we had a very good feedback from the team. If you haven’t done something similar yet I would recommend that you try this with your team, either to close this year or to start the new one!

Postits
Good 2016!

Nuno

My feedback from this is simple: Great article. I hope that you enjoy reading it like I did.

See more at: The Scrum Year Retrospective by Nuno Gouveia

 

Scrum and Leadership: Responsibilities of the Executive Action Team with Jeff Sutherland and his Scrum Inc.team

I’m happy to share that I just finished my registration for an extensive examination of why and how leadership needs to engage to de-risk an Agile implementation with with JeffSutherland and his Scrum Inc.team.

This is going to happen on December 1st 2015 and I’m looking forward to learn more about this topic from these guys experience.

To give you some context please find below the course description.

Scrum and Leadership: Responsibilities of the Executive Action Team

iStock_000028769268Medium-300x200

“Transitioning from traditional project management to Scrum is a paradigm shift. Too often, leadership believes implementing Scrum as a simple process change that can be delegated. Leadership must own an Agile transition because it is nothing short of a strategic reorganization. Albeit an incremental one.

To truly reap Scrum’s benefits, the C-Suite must lead a cultural change. How? First and foremost, they need to form as a senior Scrum team, or Executive Action Team (EAT.) By operating as a small cross-functional team, executives not only understand how the Scrum ceremonies, roles and tools work together to enable massive increases in productivity but they learn how collaboration, rather than command-and-control, enables innovation and problem solving. This emotional aspect is the cultural change leadership needs to learn and communicate to the rest of the enterprise.

Join Jeff Sutherland and his Scrum Inc.team, Tuesday, December 1st at 11am EDT for an extensive examination of why and how leadership needs to engage to de-risk an Agile implementation.” [1]

References:

[1] Scrum and Leadership: Responsibilities of the Executive Action Team | scruminc.

How to build an Airplane using Agile Methodology (To be more specific Scrum)

A few months ago during one of the training sessions  I had a person that asked me if we could use Scrum to build an Airplane. Ex: A320

Airplane

Since that time I’ve being thinking and discussing this subject with a lot of people and we got to different conclusions where one of them was to start building a Hang gliding as MVP and keep improving.

So today, instead of sharing a new article I would like to share this challenge. How could we built an Airplane using Scrum?

Please leave your thoughts and ideas 😉

Achieving a Successful Scrum Implementation – Making the Red Pill-Blue Pill Decision (Published at ScrumAlliance)

Sharing my recent article publish by Scrum Alliance today, Tuesday 25th of August 2015.

Again its a very interesting article regarding one of my past experience that I called “Achieving a Successful Scrum “Implementation – Making the Red Pill-Blue Pill Decision“.

It’s amazing how often movies are my source of inspiration for talking about real themes related to Agile.

Some time ago, a friend and I were discussing previous Scrum implementations. What could make them successful? This conversation was really productive, because we shared our opinions and past experiences. Also, we agreed that often Scrum or Scrum implementations don’t work due to people’s lack of understanding and their concerns, motivation, and beliefs.

What I’m trying to say here is that Scrum, as everyone knows, is not the silver bullet that is going to solve software development issues. Implementing Scrum sometimes means changing mind-sets, and to do that, people need to believe in what they are doing. They must free themselves from old ways of thinking.

I remember the dialogue from the 1999 movie The Matrix, in which Morpheus offers the main character, Neo, a choice between taking the red pill or the blue pill:

“You take the blue pill, the story ends. You wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.” [1]

Pill
Source: http://counterinception.com/sites/default/files/pictures/MatrixBluePillRedPill.jpg

To give you context, the red pill represents the human desire to discover the reality hidden in the fabricated world that they are living in (the Matrix). As soon as Neo takes the red pill, it triggers his desire to free his mind and wake up from continuous sleep as a prisoner in the Power Plants. That is, it bolsters the will to wake up and be free from the old mentality. Embrace new methods and frameworks that allow us to learn, adapt, respond to change, deliver faster with high quality, search for real customer satisfaction, and have tools that help us continually improve.

What about the blue pill? Let me explain why I believe that people’s understanding, concerns, motivation, and beliefs are key to a successful Scrum implementation by using Morpheus’s pills as an analogy.

Some time ago, I was approached to help some teams in their Agile transition and Scrum implementation. During this time, I discussed ideas and approaches with everyone on the team to elicit feedback about how we should do it and what benefits the teams could realize from this transition. Everything looked OK at first; team members were motivated and interested. So we started following the steps as agreed.

In the beginning, everything was going well. We hit some bumps in the road, but that’s normal when changing mind-sets and old ways of working. But suddenly things started to slow down and issues surfaced regarding how the work was submitted to the teams and how the teams were performing. In that moment, we felt that something was wrong, something that was causing all this distracting noise and continuous interruption. The teams became confused. So we decided to investigate a little further to understand the root cause.

My biggest surprise was when we realized that this was coming from a group of people who were concerned with their sudden lack of control. How could things work if we had no control over what was happening? What would we do if all the information became so transparent that everyone could see the issues that we had been suffering from for a long time?

The irony was that this was coming from people who said that they believed in the transition to Agile and Scrum implementation. They were so concerned about making noise that they started doing what they were used to doing before the transition. You know what I’m talking about: working under the table, micromanaging, transforming the ceremonies in status reports, etc.

You might be asking yourself how this issue could be solved. That’s a great question. The first thing that I did was ask everyone to join me in a face-to-face meeting. I started the meeting by asking the following difficult questions, without pointing any fingers:

  • How do you think the transition is going?
  • What are your concerns about the transition?
  • What can we do better to improve the transition and adoption?
  • Why do you think that making the issues transparent is a bad thing?
  • What can we do to help you gain a better understanding of what we are trying to achieve, and why?
  • Can I count on your full support and commitment?

In the end, everything went well. I’m not saying we had a 100 percent shift in attitude and mind-set. Keep in mind that changing the familiar mind-set and, as a consequence, familiar attitudes is a difficult thing to do. It takes time and patience. But these team members saw that we were there to help and support them all the way.

The final statement and question during the meeting was the hardest one for them to accept. I told them that to have a full and successful transition to Agile and Scrum, all meeting participants had to think hard and decide whether they really wanted to achieve success in the Agile transition and Scrum implementation.

In other words, I asked them which pill would they take if Morpheus had offered them the choice.

Please let me know of any similar experiences you have had. By sharing we can learn together.

[1] IMDb | The Matrix

See more at: ScrumAlliance.org | Achieving a Successful Scrum “Implementation – Making the Red Pill-Blue Pill Decision

One last thing, I hope that you like reading this article as much as I enjoyed writing.

Hyper-Productive Metrics with Jeff Sutherland and Scott Downey

I’m happy to share that I just finished my registration for the hour-long course about Hyper-Productive Metrics with Jeff Sutherland and Scott Downey.

This is going to happen on August 26th 2015 and I’m looking forward to learn more about this topic from these guys experience.

To give you some context please find below the course description.

Hyper-Productive Metrics Course

HyperProductive-300x200

“In Scrum, beyond velocity, which metrics matter? Which metrics apply across teams? What do you measure at scale.

In their groundbreaking paper Scrum Metrics for Hyper-Productive Teams: How they Fly Like Fighter Aircraft, Scrum Inc. CEO Jeff Sutherland and legendary Agile coach Scott Downey of Rapid Scrum, created best practices for accelerating Scrum teams and the metrics used to fine tune them.

Join Jeff and Scott August 26th at 11:00 EDT for an hour-long course with a live Q&A follow up. See how they’ve iterated on the original metrics and what they’ve learned as they have further applied them.” [1]

References:

[1] Hyper-Productive Metrics | scruminc.