Scrum 2.0 | Yes we can!

Would it be possible to upgrade Scrum to Scrum 2.0? What would that mean? Would it be possible to mix traditional Scrum with social networking flavors?

Scrum is partly about improving communication between all team members. Social networking is all about connecting people and improving communication between them. Both try to improve communication ... so let's try!

Let us pick a single team conversation and see how we can enhance it with some social networking tools.

Scenario 1: Daily standup meetings

Let's not go that far... the whole point why this works is because we have face-to-face contact. I would be kinda strange to replace this with everyone sitting behind his desk (micro) blogging about what they did. Let's try something else.

Scenario 2: Inter-team communication during the day

Let's imagine for a second you have a team practicing extreme programming. This team is obliged to maximize communication during the day. Some of the communication that can go on is:

• Check out this article about TDD
• We need to bring down the build server for a second, memory upgrade
• Added feature X to the base test class
• Get me some coffee ... NOW
• Mails from the CI server (broken/fixed)
• and so on ...

In the examples above we can have several ways of communicating this data, we can:

• shout it
• send an email
• put it on wiki (+ rss feed)
• send it using instant messaging
• and so on ...

You can shout it through the room and that works if you do it like once a day or you have a very small group. The usage of email is still #1, perhaps some filters can drop the number of unread messages. The wiki is fine for bigger stuff, if for every little thing you want to say you need to open the wiki, add a page (or open one), add the text, and save it ... fwiejjww. Instant messaging also sucks, some tools have grouping functionality but it keeps on blinking on my desktop, hate it. I think if I needed to summarize the problems we all of the techniques above is that they make too much noise, don't push information upon people but let them people only what they think is necessary (aka Lean). Scrum doesn't provide any insight in this so so much for that...

So I guess the second scenario can be a good one for further analysis. We know that team communication is crucial, knowledge sharing is even more crucial, but making too much noise will kill all of the benefits of trying to share. A business case for a technical tool? I guess we are kinda stuck with person to person solutions here, we could try to whisper but even then ... :-)

We need a tool that allows us to share information (crucial or not) between team members, small messages, things that pop up, things that have no need to be archived until the sun explodes messages like 'I'm feeling sick today ... give me a break'. We need to be able to send them with no ease, everyone who might be interested in what I or the team has to say can listen upon those messages but you can't force people to read everything. This latter one is very important, we want to know what is going on with everyone but we don't like the information to be forced upon us. Email has this problem, you send it, I have to read it but first I need to open the message, if I don't want to read it I still have to delete it otherwise my inbox keeps growing... It is up to the reader to decide whether or not to read the message if he doesn't want to the message should just 'disappear' (don't even have to delete them), he should be able to give feedback at no ease, look at feedback of others and so on....

What we have here is a business case for what is called Micro Blogging.

Let's look at Twitter. You either love it or hate it, but you can't get around its popularity. Twitter is all about micro blogging, a technique similar to sending sms messages. The main difference is that your audience is much, much much much bigger and secondly and not unimportant is that reading a Twitter message it is much less intrusive than having to open each sms message individually. Each sms you receive you need to open individually whereas Twitter messages are pushed to you as a continuous stream where you decide whether or not to read a message. So sms / email = push + click and Twitter = push and forget.

The biggest disadvantage currently is that you can't used it behind the company firewall. Yammer is a tool which allows you to overcome that obstacle, it lets you create a Twitter like stream behind the firewall and is only available for those have been registered and allowed to use it.

So what would happen if the team would embrace something like Yammer and use it instead of shouting, sending emails...?

First of all it would take out all the noise out of the team, don't feel obliged to use it for everything because it is still very important to keep up a good atmosphere within the team, so talk... but don't make noise!

Second, Let's say you found a great article about TDD, just put it on the stream and whoever feels like reading it will, those who are too busy will just ignore the message.

Third, no more spam in your mailbox! No more messages to delete, nothing to open just to make sure it isn't interesting...

Fourth, most of these tools even have API's which means that with some effort you could easily redirect your CI server information (build broken / fixed, what has been updated and so on) and stream it directly into for example Yammer. If someone is interested to see what is going on with the build he can, if not just skip it; it will only take a blink of an eye to do so.

I can go on but you get the picture I hope? By introducing a stream like micro blogging tool we reduce a lot of team noise and we optimize communication. We just eliminated a lot of waste ;-)

Yammer is really great, no matter where you are you can always check the team stream because they have ported the application also to a desktop, mobile and iPhone application.

Scrum 2.0, yes we can!

Scrum | Detecting waste

Waste elimination is key to Lean. Nevertheless is the approach to detecting it completely different from traditional cost cutting techniques. The latter one detects waste by appointing certain persons or committees, who's job it is - yes you guessed it right - to detect waste.

An approach which will not uncover the true problems of an organization...

Lean is all about creating an environment that makes it easy to notice problems. If people are on the alert to detect problems, and the environment is created that makes it easy to notice problems, the supply of creative idea "seeds" will not run out.

Our job as Scrum Master or Lean Leaders is to help create that environment and inspire everyone to act, to take action, to make improvements.

Scrum already provides one key ingredient to continuous improvement by stating that at the end of every Sprint a retrospective should occur. Two things are important in the previous sentence. The first one is that there is a meeting, an environment, created where all team members can look back at what happened, what went well or would could have went better and last but not least that the intention of the meeting is to create action points to improve upon all things that could have went better, dividing them between things that can be solved by the team and those that fall under the jurisdiction of the company. Secondly you should notice that it clearly states that the meeting should be held after each Sprint, the fact that this is a rule, a standard will help in the process of detecting problems. The team will exactly know when to address their issues. Short iterations will only help in quickly exposing impediments.

One of the Lean principles I try to apply on projects is Kanban, the art of visualizing everything that is going one. A Scrum implementation of this is the Scrumboard and the burndown chart. But don't stop there:

• get that full project burndown also up there


• keep the result of each previous retrospective on the wall especially when it contains impediments that need to be solved by the team or organization


• Don't waste too much time on making detailed UML driven technical design, grab a big paper, make some design sketches and put them up there


• technical issues which don't belong on the product backlog can be kept as a separate Technical Backlog on the wall by adding each technical issue as a post-it on it


• your application consists of a web front end than take a print of the screens hang them visible for everyone so that they can be discussed at any time, also having them around will make you get used to the screens and will help in detecting inconsistencies or improvements

I can go on for a while but you kinda get the picture. Get it up there, visualize it, so that everyone can start talking about it...

Scrum | The final battle

In ancient times, Priests, men through which God spoke, had the duty to translate the Word of God into Holy Scriptures and to spread the Word among the people.

These Knights of God who were intended to lead us through Dark times caused disasters all over the world, non-believers got hanged or burned, opinions that didn't stroke with the Word of God were said to have come out of the mouth of the Devil himself.

A world denied of creative thinking, change...
A world lead by the Holy Word of the Book of God...

Although the power of these ancient Priests seems to be disappearing in our modern society; the force is still strong; many followers that survived have been working on a smaller scale, indoctrinating the world from the inside out, infecting companies with their Scriptures and fortune telling...

We call them ANALYSTS...

Those who write the book of the World...
Those who shape, who decide upon our future...
Those who tell the future and never look back...

But things are about to change...

Meet The Scrumpies


You understand I can't reveal their true indentity

Scrumpy dislikes fortune tellers...
Scrumpy dislikes big Holy books...
Scrumpy believes in wisdom of the crowds...
Scrumpy loves and respects everyone...
Scrumpy gets grumpy from analysts...

Scrumpy is from the Order of the Scrum Masters...
Scrumpy his job is to disinfect companies from fortune tellers...
Scrumpy his job is to protect his team; defend them at all cause...

Scrumpy has a secret weapon called user stories

A tree liner that will make analysts INSANE
Scrumpy will fight Analysts on their own field...

The war has already started...

Scrum | Anno 1945

I came across a quote from General George Patton who lead the U.S. Army General in World War II in campaigns in North Africa, Sicily, France, and Germany. It goes as follows:

A good plan executed today is better than a perfect plan executed at some indefinite point in the future.

I can only guess that he would have loved Scrum ;-)

Agile | Processes and tools aren't evil

The Agile Manifesto clearly states Individuals and interactions over processes and tools, better known as People over processes.

Many people I talk to interpret this definition as follows: Remove all processes and tools and base everything upon excellent communication and interaction between all parties. Processes and tools equals clutter, waste, too much noise...

Is that was is meant by 'People over processes'?

Not really, the word OVER is very important in the above definition and often misinterpreted. It means that communication and interaction are prefered OVER processes and tools. It doesn't state they should be used INSTEAD OF. There is a clear difference between both.

Let me explain...

In a healthy organization both are important and they shouldn't be treated as opposites. The process should be there to serve the people and if they become to bloated they should be fixed so that the roles do not turn around. If you look at methodologies like Scrum, Lean or XP they clearly state you should have processes, having processes is part of a good methodology and you have to grow them within your organization, constantly monitor and improve. A process you have today will probably be unproductive within the year, things change within the organization, so should your processes. But process optimization only works when people communicate and interact often.

You can talk about riding a bike from A to B but at the end you'll still need the physical bike to get there. The bike serves the person, the person doesn't serve the bike.

A while ago I found an article where someone rephrased the definition as Humans over robots.

Humans over robots, that says it all doesn't it, the message is so much clearer. Humans and robots can and should work together, but the robots are there to serve the needs of the human.

Crush ... kill ... destroy

Scrum | Story changes during Sprint

At the beginning of each Sprint the team commits to a number of Backlog stories which end up being the Sprint Backlog. Once the Sprint starts these stories aren't allowed to change, they are fixed, frozen until the end of the Sprint.

A frozen Sprint Backlog allows the team to focus on delivery instead of having to deal with change. Every change whether it is small or big is by default denied and placed on the Backlog so it can be prioritized and dealt with later. So what is delivered at the end of a Sprint isn't always according to the latests specifications. Short iterations cause these changing specifications to be implemented much sooner than later.

Or at least that is the theory...

In practice it can be up to the team to decide whether or not they can handle the change within the current Sprint iteration, just call it common sense. Some changes are small enough not to impact the Sprint iteration.

But what if business comes to you with big changes, very big changes? The team has committed to 6 stories (2 week Sprint). After 4 days business comes to you and tells you that 2 stories have been analyzed completely wrong (90% wrong), one of these stories the team has already started on. Even worse, if they implement it as-is it will have very negative impact on several upcoming tasks. What do you do?

In theory Scrum says all changes should be denied, we could do that. Practice teaches us to evaluate each change upon their impact. We can quickly conclude that the impact of these changes is a nightmare for the current iteration, so we deny the change, right?

Don't forget that denying them will cause a disaster upon upcoming tasks, what will you do? How sure is the business about these changes, or about the impact? The business has been wrong before, right? But this time they have truly done their research and it will make your life a living nightmare if you don't implement the new changes...

What do you do?
What do you do?

I know what I would do...

Scrum | Ban local optimization

Traffic jams, we all know them, we all hate them!
But perhaps there is an important lesson to be learned from them...

While I was sitting in my car, listening to the same old cd, not in the mood for an overdose morning-radio-happiness-whether-you-like-it-or-not, my mind started to drift of and before I knew it a couple of miles passed by without me even realizing it.

How did I get there?
When did I started to accelerate or brake?
Where did the people in front, next to or behind of me go?

I just got there, how I got there, or how others had got there is based upon individual driving decisions. The only rule we have is that at some point it is best to follow the herd. Each driver individually can decide when and how fast he moves from A to B, he does what he think is best, what he does, what he is allowed to do are local optimizations.

Trying to kill the time remaining in traffic I started thinking. Traffic jams are a strange phenomenon, they have been analyzed thoroughly but solving them seems to be tricky! Why is that, are traffic jams that unique from other optimization problems in different industries? Can a simple every day problem like traffic jams inspire us enough to think about related problems in our organizations? Perhaps...

To maximize throughput, all cars need to adhere to a speed limit, preferable the exact same speed. Car drivers are required to optimize only for themselves which causes the system to break down and everyone finds himself caught in a traffic jam.

This problem can be solved by synchronization of all participants. This means all cars need to have the exact same speed and its flow should never be interrupted (continuous flow). A separate acceleration / deacceleration zone allows cars to get up to the exact speed before entering the highway. At no point, not while getting on the highway nor during traffic individual drivers should be allowed to manually manipulate their speed. Comparable with an automated railway system.

Don't compare it with traditional train railway systems, they have even more bottlenecks than the highway system, up to you to detect them...



To conclude, a problem not to be solved overnight! Key to remember is that the root cause is allowing individual drivers to do local optimizations.

SkyTran is a futuristic example of such a fully optimized system.

So we learned that local optimizations are bad. Not really an innovative idea because it has been around for ages in manufacturing methodologies like Lean. Lean has taught us that optimization should take place at the project level, not at the level of the individual people or processes. Local optimization weakens the overall process.

So what about local optimization within an organization?
What about implementing Scrum on a single team within a traditional organization? Aren't those local optimizations?

Many of you who have been using Scrum have probably asked yourselves: 'How does Agile / Scrum scale?'. Can it work even when it is not supported by the the enterprise (team level)? Is it sustainable within a traditional organization?

At least that's a questions that keeps popping up for me!

Scrum equals optimization, local optimization in most cases. The companies that have implemented Scrum or Agile project methodologies fully from top to bottom or a few. Organization adaption is a hot topic during Scrum Master trainings, do we need to do it top-down or bottom-up? My experience has taught me that most companies get familiar with Scrum bottom-up (thanks to all the smart developers) but it gets stuck somewhere in the middle or even at development team level ... equals local optimization. Better would be that the vision comes from above as we have learned from Lean (aka Philosophy level), a clear vision on company wide optimization! One goal envisioned from above!

If you are using Scrum in an otherwise traditional based organizations you'll probably spot some of the typical problems ...

• No support for a Product Owner
• Waiting for resources
• Conflicting resources
• Planning requirements
• Lots of noise
• Strange deadlines
• ...

Typical problems a Scrum team has to deal with because the rest of the organization is not aligned with the Scrum vision, the way of dealing with change. The same reason why if one person in the team does test driven development it will fail, this one person is doing local optimization which are not sustainable on the long term.

I love Scrum / Agile but they only tell you part of the story, it is too fully focused on single projects, it never explains the bigger picture, the real issue, how to optimize the organization. That's why I love Lean, Lean is the bigger picture where methodologies like Agile / Scrum fit in nicely. Lean will teach you about local optimization problems, about the higher organization cause, about Kaizen, about dealing with multiple projects.

Scrum does scale, but only if an organization is prepared to adhere fully to Lean methods!

Don't stop with Scrum, it is great, but don't stop there, learn Lean, because only then you'll see why Scrum can work on organization level. Learn how to create that sustainable organization wide vision, learn how to grow that vision...

Afterwards you'll never questions yourself again whether or not Scrum will work for 1 or 50 projects.

Optimize the organization, not the projects.

Scrum | Stop the blame

Today I want to talk about something that I find particularly common for teams that are adopting Scrum for the first time ... blame.

Let's start by defining blame:

"To blame is to hold another person or group responsible for perceived faults, whether these faults are real, imagined, or merely invented for pejorative purposes. Blame is an act of censure, reproach, and often outright condemnation. Blame is used to place responsibility and accountability for faults onto the blamed person or group."
-- Wikipedia

Key to the definition above is accountability something which you will also find in Scrum, but different. Accountability within Scrum means that not a person is responsible for failure but the team as a whole.

Like any team sport, you win or loose as team. Like they say there is no "I" in team. But reality teaches us that when we loose we feel the need to make someone accountable for the loss. Even worse, blame is basic to hominid behavior. Studies have showed that blame seems to be an essential part of human development. When language skills develop, one of the first practical things which can be done with them is to apply them to blaming others for one's own misdeeds, and getting them sanctioned, or punished, while one simply continues with more of the same.

So don't get all cracked up on the fact that your team start blaming during the daily stand-up or even worse during the retrospective after a 'failed' sprint. We can't help it, it is in our nature ... see, we can even blame the fact that we blame solely on being human :-D

So why is there no place for blame within Scrum? Actually for this we need to look beyond Scrum and look at its daddy called Lean. Key to Lean is waste elimination which is achieved by continuously trying to improve the process, also known as Kaizen.

Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work, and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.

To be most effective kaizen must operate with three principles in place:

• consider the process and the results (not results-only) so that actions to achieve effects are surfaced


• systemic thinking of the whole process and not just that immediately in view (i.e. big picture, not solely the narrow view) in order to avoid creating problems elsewhere in the process


• and a learning, non-judgmental, non-blaming (because blaming is wasteful) approach and intent will allow the re-examination of the assumptions that resulted in the current process.

Blaming is wasteful, a simple truth but just because blaming is part of our nature so hard to achieve. So don't go expecting team members to stop blaming from day one but guide them into the magic world of getting things done like a team. Guide them towards spotting waste, guide them towards process optimalization and continuous improvement, help them to stop thinking about blame.

I make mistakes, I do things wrong, I don't know the answer to everything, but so don't you! That's life!

An example

During a retrospective a member of the team put up a post-it saying "Commitment?" and said "I think this needs no further explanation".

You kinda get the idea that such statements are not very constructive nor are they identifying waste = the real issue. So what should have happened and what was behind his frustration?

The frustration was actually caused by team members working on tasks in parallel, doing multiple stories at the same time. And by doing so they started blocking each others work, tasks depending on other tasks. And even worse the guy that had put up the "Commitment?" paper in the first place was working on multiple tasks in parallel, blocking a complete story and was not willing to give some of his tasks to someone else and by doing so unblocking the ongoing work.

Everyone in the team got frustrated because they could not proceed, and the one doing the multiple tasks was frustrated the most because he felt he was doing all the work. Causing him to sit behind his desk until late at night.

So during the retrospective he felt frustrated and blamed the team not being committed. Should he have kept quiet? Hard to say, yes and no. Because he was new to Scrum he could not really pinpoint what went wrong so yes I believe he was in his right to do so. But then it is up to the team members to react and explain what really had happened, not that he was blocking everything but that as a team they made bad some bad decisions upon dividing the workload on the task board.

During the daily, the moment everyone was grabbing the tasks he will be working on the team or at least the Scrum master should have reacted and warned about the fact that they were starting on multiple tasks in parallel ... so actually they failed as a team.

In the story above the person should have concluded that failure of the sprint was due to the fact of badly implementing Scrum, doing multiple stories / tasks in parallel and not the fact that there was no team commitment.

It isn't always easy to spot waste, nor process inconsistencies, nor is it to keep your emotions under control! A learning, non-judgmental, non-blaming environment in which we continuously try to improve ourselves isn't something we can achieve in one day, but by practicing Kaizen we take each day a little step towards this goal.

Scrum task boards gone wrong

I just started working on a new project for which the existing team was already doing 'Scrum', so I though I would post some first impressions on their Scrum task board - the wall where all the magic happens.

The moment I entered the room and I saw the wall I literally thought 'what the fuck'. The wall should give a clear and concise overview of the project state ... you probably already guessed it, it did NOT. Here are some remarks of things that were missing (they are already on my list for the next retrospective but I did not wanted disturb their current sprint):

Remarks:

The task board should look like a board. With this I mean that there should be a clear visual seperation between all the elements of the task board

Titles (i.e. story, todo, in progress, done, ...)??

Advise:??Should have a very big black font.

Now: Normal handwritten blue text, same size as you normally write

Grid lines

Advise:??Big black lines,not manually drawn but use tape so they are perfect straight

Now: Lines quickly drawn with a loose hand, blue pen, very thin, not really visible

Stories

Advise:??Pre-printed papers containing the title and description of the story including story points and importance. Use big papers, not small post-its, make a clear distinction.

Now: Normal handwritten blue text directly on the background (paper), very hard to read

Tasks

Advise:??Use super sticky post-its that way they don't drop from the wall during the night :-) Use a big black marker, yes BIG, to write the task on, handwritten is ok because those have to be made quickly. Don't forget to mention the remaining points and always put them on the SAME place, can't stress enough to make all the tasks look alike, otherwise it looks like chaos and it looses time during the daily stand-up. Also link your name with a task. Don't just write it on it but make specific post-its for yourself - you have to very small rectangle post-its in every color, feel free to custimize them, it represents you on the board. Also place the name tag on the same place, usually the name tags and the points are placed on the right.

Now: Normal post-its with small unreadable blue handwritten text (normal pen), names are written on them manually but hardly readable. From a normal daily stand-up meeting distance from the board I just can't read the tasks, even when I take a very close look I can't even read them.

Sprint goal

Advise:??Define cleary what the goal of the sprint is, always fun to know what you are working for.

Now: Missing

Test phase

Advise:??If you want to declare a test phase make it clear on the board. I prefer a different topic / grid column for things that have to be tested. You can use sticky markers on the post-its but watch out that you don't make your board a painting. Also non development people, testers, like the to be tested column because that gives them a clear view on what is expected from them. When the test phase fails you can put an extra post-it on it (different color) explaining the bug.

Now: They mark the post-it with a big blue handwritten 'V' when tested, totally unreadable, testers are not even clear what they need to test or if it has been tested, feedback / bug report back to the developer who needs to fix it, big less :-)

Burndown chart

Advise:??Update daily the burndown chart, and it should be part of the wall. Create a pre-printed paper with a graph - not filled in - with gridlines and x/y axis, make it easy to manually write the correct days on the x-axis, you can already pre-print the points on the y-axis. Use a simple ruler to drawn the normal burndown path and adjust daily during the daily stand-up the chart. You can do this by manually adding a now x-y coordinate and adjust the line. The chart if part of the daily discussion.

Now: No burndown chart on the wall, someone takes notes of the daily standup and afterwards makes adjustments to a burndown chart in an excel sheet. So there is no immediate feedback on whether or not we are on track during the daily standup.

These are just my first impressions, along the way I'll try to post improvements and other things I see going wrong :-)

I'll also try to take some mobile phone cam shots ... sneaky.