The Scrum Dream Team

I was watching football (soccer in American sports terminology) the other day. I'm not a big fan these days but I used to be. Anyways, seeing Brazilian National Team playing is always a good investment of time.


While I watched the game some reflections came to my mind:

1. Brazil has great football players, they're all sport starts that play in the best teams in Europe. They are rich, talented, and famous, everything in the same package. But they're humble enough to accept to be coached.
2. Anyone in the team, except the goal keeper of course, can score goal and win a match. It's not unusual to see that Brazilian defense can also score. Team success in more important than individual recognition.
3. Why defense player can score? Simple, they change roles during the match and become part of the offensive. Adaptation is key here.
4. Brazilian National Team plays differently when it plays against South American or European National teams. Brazilian players use technique or play rough if needed. Essentially they adapt their style to circumstances.
5. Motivation comes from inside the team, Brazilian players believe that they're the best and always look for new challenges.

Lastly, there many national teams and thousands of excellent players around the world, but what makes this national team so successful? My answer would be that a combination of talent, humbleness, adaption, inspection and teamwork, triggered the magic of the 'jogo bonito'.

The Incomplete Judo Definition of Done

One of my clear memories from youth is training Judo projections and uncountable number of times. In Judo you won a match in several ways, but the most spectacular one is when you throw your opponent to the floor over your heap. You get a full point, the match ends, you won a medal, the crowd chants your name and everybody is happy but your opponent.

But what if you for misfortune you are forced to use the same technique to protect your life in the street? Throwing somebody to the floor would be enough to neutralize your attacker? Hard to say, but statistics shows that this won't be enough, you need to immobilize your attacker to be really safe. So following this rationale, Judo projections are half done.



Extrapolating this to the Scrum world, Judo projections are like writing code: looks really cool, people love to see it, it attracts attention and respect but is still half cooked. Code that has been coded but not tested is like a furious attacker in the ground, it can counter-attack and really hurt you unless you do something to really control him.

In Judo (and more effectively in Ju-Jitsu) you use punches and locks to really immobilize your attacker. In software development you can use testing-both manual and automated-to assure that the code is good enough. Further, you need to reach consensus about the acceptance criteria and the Definition of Done. Why? Simple, it's a team's activity, without consensus effort would be wasted without favorably impacting in code's quality.

Some Scrum Fallacies

I been looking into some Scrum concepts that we take from learned but are wrong from a conceptual level, I compiled a list that you can read see below.

• The PO (Product Owner) prioritize team's activities. This is false. The PO main responsibilities are to provide feedback, answers questions about items in the current Sprint, and work with the stakeholders. The Team is in charge or prioritizing its activities.
• The Sprint has to last a calendar month. False again. The Sprint can last a month or even less, it can also be extended under special circumstances and with PO's approval. However, the Sprint shouldn't be so long that it doesn't adjust to business events.
• It is necessary to have a vision and product backlog to start and sprint. False. There are important things that you'd like to have before starting an Sprint, things like a release plan, budget, executive sponsorship, technical leadership, team space and team rules, backlog, etc. Nonetheless, those things are not essential for starting and Sprint, remember, Scrum is about adaptation and not fully detailed planning.
• All the Sprint Backlog must be defined up to 100% in Sprint Planning meeting. False. The team just need to identify all the necessary tasks to complete the selected Product Backlog items that will be tackled during the Sprint.
• The SM (Master Scrum) is responsible for removing team members that are not performing well or disturbing other team member's work. False. In Scrum we have self organizing teams that can decide to remove team members by themselves, the SM may provide advice but the final decision has to be team's call.
• Burndown charts show how much effort has gone into the Sprint. False. Burndown chart essentially shows estimated work remaining for each day of the Sprint.
• During the Sprint, identified tasks are added as soon as the PO approves their inclusion. False. Tasks needs to be added by the team as soon as their are identified, no need to wait for approval, agility and proactivity is crucial.
• The team is responsible for selecting the PO. False. Even thought we have self organizing teams and that the SM role can be rotated, the PO is appointed and can't be removed, at least not for the team.
• The SM has to attend to the Daily Scrum. False. The Daily Scrum is a inspect and adapt meeting for the team that does actual work in the project, so no need for the SM or PO to attend unless they are invited by the team. The SM however should collaborate setting the logistic for the meetings: reserving a conference room, providing phones, sending invitations, etc.
• The Sprint Backlog will be the output of the Sprint Planning Meeting that will set the direction for the next Sprint. False. The target and direction for the team will be provided by the Sprint Goal.
• The PO has to ship each Sprint increment when it'll be free of defects. False. The Po has to ship increments whenever he feels that this make sense, of course that they don't have to have defects but this more like an enabler and not the ultimate motivator for shipping.
• A Product Backlog item is considered completed when all its tasks are completed. False. A Product Backlog is actually completed when it meets all negotiated acceptance criteria.
• User stories are included in the Sprint Backlog. False. User stories are decomposed in tasks during the Sprint Planning Meeting and then they go into the Sprint Backlog.
• The SM has to act as a go-between the PO and the team. False. This is the least communication technique that the SM could use, more effective ones are: monitor communication between the team and the PO, teach the team to talk business languages , teach the PO technologies involved in the product.
• The SM or the PO are in charge of updating the Sprint Backlog during the Sprint. False. The empowered team takes the decision of updating the Sprint Backlog to reflect their decisions and tasks progress.
• Teams make adjustments to their engineering practices only after consensus was reached in a Sprint Retrospective meeting. False. Teams are adaptive in nature and need to take initiative and adapt their practices whenever needed.
• The SM is an engineering position. False. The SM is a management position.
• The product has to be shipped at the end of each sprint. False. The product needs to be shipped when the PO decides to ship it and taking into account a release cycle that includes marketing, finantial, legal and other implications.

A Backlog for Improvements

During a training session that I conducted last week, a very interesting question popped-up, how teams accounts in their improvements after Sprint Retrospectives?

What I use for my teams is a very simple technique: I take pictures of all problem insights and improvements that we''ll be tackling in the next Sprint after the retrospective. I then post those pictures in team's SharePoint and I project them in the initial part of the next retrospective meeting in order to have a feel of what has been accomplished and what not.

This works quiet well but we still miss the feeling of progress, more to the point, we're lacking the psychological effect of burning something (like hours, story point, user stories or any other indicator).

What I propose is to create a backlog of potential improvements, we could go as down as estimating effort and time and maybe creating associated tasks, but my initial feeling is that this would over complicate things. Instead the attack plan should be just logging in this backlog the list of potential improvements from the Sprint Retrospective, prioritize them and then work in the top priority areas for improvement. No much data about how improvements have been accomplished should be logged, unless somebody in the team wants to document them as case studies.

I'll be trying to implement this idea and write later with actual evidence in hand.

Jazz Band Conductor a.k.a. Agile Project Manager

I though in a interesting analogy the other day, if you hear a jazz band (and hopefully a good one) you'd realize that the conductor encourages improvisation. Actually, improvisation is a distinctive characteristic of jazz music.


The conductor is someone that is deeply familiar with the instruments and music, but not necessarily plays with the band. What is important for him is that everybody plays good jazz and the audience gets satisfied. Making every musician in the band happy is of course a priority, happy people are generally more willing to improvise.

There's of course an style to follow and a lot of training, all these required for being able to improvise in the first place. But the goal is always at sight, have fun and play good jazz. Again, the conductor don't tell the team what to do, he let the team create and help it to reach the next level. This is certainly a lesson that we can translate for Agile Project Managers.


On the opposite side, this guy has everything figure out from beginning to end-or at least he likes to think so-, everybody in the chorus has to sing exactly what has been rehearsed endless times.

No deviations from the score are allowed, improvisation is not specially highly rewarded. Do you see any similarities with traditional Project Management?

The Most Important Meeting in Scrum

I was thinking on which would be the most important meeting in Scrum, this questions crossed my mind because I've heard that many teams in my organization still believes that Scrum is all about the Daily Scrum Meeting. Maybe the confusion came from the fact that both Scrum-the framework- and Scrum-the meeting- has the word "Scrum" in their names. Whatever it was it's pretty obvious that is a serious mistake that needs to be corrected.

An interested behavior that I've observed on those teams is that they believe that they're doing Scrum just because they have a daily stand-up meeting. Nothing could be further from the true spirit of Scrum.

But going back to the initial question, in Scrum we have meetings like:

• Planning Meeting
• Daily Scrum Meeting
• Sprint Retrospective Meeting (a.k.a. Post Morten meeting)
• Mid-Sprint Review Meeting
• Release Retrospective Meeting

This list is not definitive and surely enough more meetings will be added/suppressed by teams based on their specific needs. However, the meeting that in my humble opinion is the most important in Scrum is the Sprint Retrospective Meeting. Why? Because this is the meeting for revision and improvement and Scrum is all about inspection & adaption.

The Old McKnight Was Right

William McKnight at 3M create a new mentality: let the workers innovate. This revolutionary mentality made of 3M a company capable of being always surfing the wave by introducing dozens of new products to the market and create very diverse business units.

I read a very interesting quote from McKnight:

"Hire good people, and leave them alone."
"If you put fences around people, you get sheep. Give people the room they need."
"Encourage, don't nitpick. Let people run with an idea."
"Give it a try—and quick!"

This is something that definitely goes inline with empowering the team and other core Scrum values . Again, I'd recommend that we listen to old McKnight.

Technical Debt a.k.a. Torpedo in the Water

What can be more dangerous than having a armed torpedo coming fully ahead to your ship? Short answer: not knowing that the torpedo is coming and just feel the blast and have only an split second to realize that you, your ship and your crew are domed.

You could mitigate this by having some good active and passive radars that at least tell you that at torpedo is on seeking mode and looking for your ship. Of course knowing what is coming is times better than being taken by surprise.



During the Sprint we have a very good indicator-you can call it information radiator if you want-for knowing than something really bad is coming. This indicator is the technical debt which in its simplest definition is just unfinished work. But let me elaborate on this definition a little more, technical debt is:

1. Schedule work that has not been even started
2. Schedule work that has not been implemented
3. Implemented work that has not been tested
4. Tested code that failed to pass all test, bugs were encountered
5. Work with bugs for which fixes were provided but rejected
6. Retest work that is still in progress, consequently there's still uncertain that fixes actually work
7. Unplanned work that has been discovered in the Sprint but that has not been completed-maybe not even started
8. And the worst of all, undiscovered work that has not been considered but that will be necessary-armed and locked torpedo

Technical debt, like torpedoes, is lethal unless you know that it exist and is coming towards you. If you detect a torpedo in the water, you can still save your ship-and your life of course-if you launch counter-measures. The sooner you act, the more chances that you have to save your boat, sounds similar to technical debt?

Agile Flavors

Thinking tools: Tools that we use in our field of expertise to build software. In other domains they’re also called mindsets or philosophies. Some examples are:

• Lean
• Agile
• Systems Thinking
• Theory of Constrains

When thinking becomes acting you need a toolkit (some people like to call it framework). There are many toolkits/frameworks out there to put Agile/Lean at work:

• Scrum
• eXtreme Programming
• Kanban
• RUP

Some thoughts on the various disciplines:

• Agile: A core set values for executing projects
• Lean: A core set of principles for running a company
• Scrum: A set of agile management practices based on one principle: Inspect and Adapt
• XP: A set of agile software engineering practices/processes