Tag Archives: snarap

Super Heroes

Super Heroes

In a Scrum practicing team, every one is a hero, trying to promise and perform what or what ever it takes to deliver in the Sprint. For transformation projects, the biggest threats are with the super hero’s in the team.

A had a candidate in my team who works like a geek, he understood Scrum, he even takes it to the next level to make his associates understand what Scrum as a framework is?, he works best or bets his velocity, each time. He delivers what is required and sometime more than what is required, He helps associates to complete their work, sometimes working overtime or helping them code or test, or even do their work as his and claim that they have done it. Infact he solves all his impediments by himself. Did I say, he solves it by himself? Well, did you see the hidden threats that can blow up the team even it can delivery Sprints.

What was the candidate trying to do? He was basically doing the whole project by himself. There were physical teams depending on him to deliver for the sprint. The Scrum Master became dumb to understand how unwell the Sprint executed and the threat never showed up even in the Sprint Review or Retrospect because the Done for the user stories are validated and signed-off by the product owner as accepted. Infact, the Sprint was super flawless, hidden inside the team is the incompetence lying low and the super hero trying to cover it up along the team.

A Scum Master is just not enough to handle situations like this. We needed a Coach here to make the team understand what they were supposed to do.


As a team for each sprint, we deliver, but not over deliver it. In highly self organized teams, the threat shadows itself and grows as a poison tree. The super heroes, thinking of helping junior peers, coding for them and claiming they have done it, is a way of spoiling the guy who looks you as a senior. The candidate should train, guide the juniors to perform the action than to do things on his own.

Scrum Master:

Impediments are to be solved or guided by a Scrum Master who has to be a technical guy in a tactical project. If he is just another Project Manager moved role, then it becomes a clear problem that is buried within a team and never showed up. In Scrum, we need to remember it’s a team’s delivery not a single person who can prove the sprint to be right.

This is a hidden, secret layer that cant be found unless you go a step ahead with the team and understand what each person deliver. In my experience, even if you have been honest with the team, the team never shows up that there was something hidden. For the sake of being good hero, outside but what each individual misses is that their learning curve is pulled by his senior and at the end of the day, he doesn’t really know what went on with project or how it was ever coded.

Why do these heroes do this?

From my experience,

  1. It’s for them to prove that they can deliver technically anything and they want their expert light bulb above them.
  2. The thirst to qualify and get a good rating and prove technically strong caps.
  3. To impress junior or senior peers
  4. As a challenge, to fight with self ego’s
  5. Innocently, they overdo, just to prove.
  6. Rightly to beat their velocity Sprint after Sprint.

There is a parallel threat that runs with this, the velocity is being observed not as a team but by a single resources doubled up velocity and there starts the waterfall model as the resources who are waiting to get their work done spend quality time doing all sorts of other works.

How do we identify the secret as a Scrum Master?

  1. In Daily Standup we don’t hear any impediments
  2. Even if we hear, they are solved or can be solved by today or a specific day
  3. Details on impediments aren’t shared by the team.
  4. Team considers every risk to be an impediment.
  5. Team member doesn’t provide an update or deliberately avoid a specific update.
  6. Team member deliberately absent for a update that he needs to share on a day.
  7. Team member has resistance in volunteering to pick up user stories.
  8. Team member depends on senior resources (super heroes) in the team to suggest, picking up user stories.
  9. Team member informs that he would not be available today for the daily standup.

The above are some of the symptoms that I have faced as a Scrum Master. Watching the sprints deliver perfectly at the end and being dumb.

What can be done:

  1. Discuss it personally with the resource. Understand his problem and start assigning him a mentor to help him learn where he’s week at.
  2. Remove him from the Scrum Team. (Make him an observer for a sprint)
  3. Give him or allow him to take simple tasks from the backlog (planned for other sprints) to work on.
  4. Have a personal stand-up with him on daily basis to understand three things. (What did he learn or do yesterday, what is he going to learn or do today, what is the proof?)
  5. Just by assigning him / her to a mentor or getting them a training tickets to attend training does not make him a hero overnight.
  6. As a human, he takes his turn to understand that he has done a mistake; he first tries to cover it up with guilt. Then he tries to recover from his act, He anticipates and understands the move forward. This is the time you as an assistant provide him the tools for him to grow. Infact his is one of the best things a Scrum Master can do to his team ever.
Leave a comment

Posted by on October 13, 2011 in New forms in Agile


Tags: , , , , ,

Ah, I don’t want 2 work on US time

Collocating or Co-locating them and performing the delivery using Scrum was a nightmare in our organization. We use to have re-organizations twice a year. The need was to be aligned with the function or with the business or within the business function.

Prior to this, our re-orgs were more towards technology like Java Unit, Microsoft Unit, which had sub units Front End , Back – end and then version wise split up Java 1.2 Sub unit Java 2.0 …. It was a mad rat race….

 Delivering becomes even more cumbersome as the front end guys needs to collocate and need a separate infrastructure and when they were integrating their process they need the testers who needs to be borrowed for a period of time and then returned back. No dedicated testing, BA resources were provided for a development team.  They need to collocate for a period of time. Infact this led to creating a pooling structure for BA’s, Testers and they formed a unit, sub unit and a department for them. The billing become more holy and the process became the cow. These departments gave birth to a sibling Technical writers and it race raped a new breed of Document Writers, Critics and User Manual creators, Automaters and on… At the end of the day, we had hybrid teams in a department collocated working on a technology where the technology breeds a dozen on the weekends with new versions zipping our lives.

It was a real mad rate race.

Aligning to business itself is a threat, as the vision for the business is strategic and anything strategic has a dynamic weather change. The rolling up was much easier in this end but when another re-org needs to happen it again became cumbersome.

Aligning  with the function or a service was ideal, where we really found cross generations of ppl work in a team. Every organization that is on the way to become a matured hybrid should have undergone all these kind of alignments, vertical, horizontal, funnel down, up and undressed to show the value of joined up teams.

Yesterday, It was a dull client – customer – development team hybrid where the clients / customers were in the East or West, the development, testing centers were in India and China to work and deliver the content. Forming Scrum teams were a challenge, a huge impact on teams that were in US and India, where the Indian developers needs to work on the US time just to clarify doubts, prototype and present what has been done.

Today, A much energertic approach in handling clients have been found and practiced in organizations like mine. We have replaced the word Clients / customers with ‘In-Country colleagues’. They aren’t clients, but our team members who work in other locations. The idea is to help us help them. Some organizations called this joined up.


Tomorrow, As I blog, Our Team has picked up 2 or 4 members from our In-country colleagues to collocate to India and spend solid 2 years in helping us helping them, to shape up the product, to help us understand the big picture than just the scrum team or the sprint deliverable.


The advantages are…

  1. We don’t worry about Scrum of Scrums
  2. We aren’t delayed to get first hand information.
  3. We have the team collocated. (Clients, Stakeholders, BA’s, Testers, Development team and SME’s) all in one place to deliver what is required like a mission critical delivery.
  4. We save time and focus on results.
  5. We buy in. When your clients sits with you while you develop, while you prototype, while you present make a lot of transparency, confidence in delivering and a much positive attitude to deliver what is required.
  6. It helps both the members to learn from each culture / psychology and human network.

This is how a Scrum team should be… If you have your clients in the US and UK, Suggest to your management to bring the key resources for a period of 3 sprints to your developing arena and see the difference of how your team can perform. I have seen IBM, Microsoft and other companies who follow this.

I have learned this over the period of two years what Scrum meant by collocating.

The graphics in the blog are not self created but gathered from internet google search.
Leave a comment

Posted by on October 4, 2011 in New forms in Agile


Tags: , , , , , , , ,