One of the most common discussion that always seem to pop up again an again, is whether Scrum /Agile is good or bad. I don’t know why but in most cases it’s starts with a claim that Scrum is not  good since it … and then state a reason. (or with the claim that Agile is dead),for example

Scrum is not a good process cause its not complete, it doesn’t define everything you need in order to succeed.

or

Scrum is not a good process. Team members are equal, each has his own set of skills and ability and treating them as equals will not work.

And although in many cases those argument make some sort of logic, what most of them are missing is that scrum is NOT a process. Scrum is a framework.
Don’t get me wrong, I don’t believe in silver bullets, I don’t think that there is one solution (process) that fits them all. Each project context is different. The people involved are different, the technology varies, the business domain changes. While there are common patterns of issues and behaviors that we can look for, at the end each project is a unique, and therefore will need a different way of doing things in order to succeeds. That’s what I love about Scrum (and Kanban and XP), they are flexible enough to handle most of the diversity you can find.

Scrum as a Framework

Scrum is just a tool. But a tool for what?
Many people consider scrum as a process for software development. That is, Scrum is a tool used in project management that will help you t create a product at th end. but that’s not exactly right.
Scrum is actually a tool for creating other tools, more specifically Scrum is the tool which you use to create a your development process. The process that you end up with after you “applied” the Scrum tool, is the “tool” you use to build your product.
Confusing? Yes? lets try again.
Normally this means, that in the process of using Scrum you take the company, the people/team, the technology and the product. those are things you feed into the Scrum Machine (along with many other things) and at the end after some time you get one new development process. that process is what you use in order to manage you project.

Scrum is not a Process

so what’s the actual difference? why the fact that scrum is a framework important?
When I see teams taking Scrum as a process, what many of them fails to realize that that there a lot of hard work involved. They start with using Scrum and expect that all of there problems will go away. They read the book follow everything that is written there to the best of there ability and they expect that everything will be fine. What then happens is that Scrum does what it was meant to do, it starts by surfacing all the underlying dysfunctions that have been will hidden there. That’s what Scrum does best.
In order for a team to create a good working process, it must resolve its dysfunctions. The Scrum framework was designed with the sole purpose of exposing them in order for the team to face them and find a working solution.
In fact, this is exactly the stage in which many Scrum adoptions fails. Its seem to be really hard, When a team starts using Scrum all kind of problems starts. So clearly if Scrum is causing all these problems it might not be such a good idea.
In some case the team will try to stick a little longer with the Scrum book. that usually doesn’t help. in other cases the Team will revert back to old habits that seem to have worked in the past. that doesn’t work as well. they either ends up in their old process (and then the claim that Scrum has failed) or they end end up somewhere else that technically looks likes a scrum based process, but in essence is not (a mini waterfall is one example)
Scrum book has no solution for dealing with bad coding, it state nothing about how to create a good flexible architecture. it doesn’t give you an idea how to handle two team members that simply cant work together,….

Knowing your tool

There’s a reason why most scrum implementation fails. Like any tool, one need to learn and practice using it. No one expects that his holes will be perfect the first time he picks up a power drill. right?
Managing a software project is a little bit more complex then that, and still people read the scrum book which seems to be simple enough and expects everything to work. It doesn’t, Especially if you confuse your tools. Especially if you think that Scrum has all the answers, Especially if you think that since defines three roles those are the only roles that you ever need on a project. Especially if you think that the 4 ceremonies are all the meetings you will ever need. Especially if you think that a daily meeting is just a daily status report, Especially if you think that you can continue writing the software like you ever did and still deliver something every two or three weeks, and I can continue for ever like this.
Especially if you fail to realize that when using Scrum you will need to work hard in order to create a working process for your team.
so one more time

SCRUM IS NOT A PROCESS

Are you also

• Feeling you can do a lot better?
• Thinking there’s much more to Scrum and Agile?
• Having a hard time Finding your place with the team?
• Doing things you are not sure you fully understand?

Then come join our Product owner workshop on April the 30th.

Read more »

Posted in: Random Thoughts,Scrum

So what is the Product Backlog?

Trying to define what is a product backlog is always a tricky business. One definition I use from time to time is:

The product backlog is just another way of describing the system requirements and serves to describe the work needed to be done

Which is a good way to simplify it to death. I had reasonable success using this definition with agile beginners, but clearly it doesn’t start to capture its entire meaning.
The more official definition taken from the Scrum guide at Scrum.org is:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Which is more complete, but still raises quite a few questions. for example:

• What is everything? (new features? bugs? technical enhancements?…)
• If it’s a single source does it contains all the details? (i.e. the requirement docs)
• what is actually written inside it (how do we write those requirements? use cases? stories? plain English?)
• Is it a business facing document (i.e. read by clients and user) or is it a technical document (i.e. serves the team who needs to understand what to build)

So what is the Product Backlog

when trying to answer this I go back to my first initial encounter with  agile. At that time what I actually read and first saw was the work done by Ron Jefferies and Kent beck on eXtreme Programming. and what I still recall today is the simple statement in which Kent Beck explained that the whole purpose of agile is to bring all involved parties to one table and make them work together in order to create great products. (unfortunately I cant seem to locate the exact quote). At that time I didn’t know what a Backlog was and I was just starting to understand all the various agile techniques. but that statement just stuck and for me it’s the best way to describe what is the main goal of the Product backlog.
Forget about stories, requirements prioritization, acceptance criteria and all other technicalities which are associated with the product backlog.
In essence, when done right, the product backlog is the one “thing” that makes all involved parties converge communicate and cooperate in order to make the product a success.

The interface between the problem space and the solution space

To take it down into more specific terms what I think that the product backlog main role in the project is to serve as an interface between the business facing aspect of the product AKA the Problem space and the technical sides AKA the Solution space. On one side the Problem space is using the backlog in order to help it define the problem and describe on his terms WHAT its need to be done in order to help with the problem and on the other hand the Solution space uses the backlog in order to sort out the actual work. the team need the backlog in order to understand what is actually expected from him, what exactly he should build, what needs to be developed first. and most important use it to create a shared language he can use to talk to the business people and create a shared understanding.
And I’m guessing that this dual nature of the product backlog is what sometimes causes all these misunderstandings we see. here are some examples:

1. Every team occasionally needs to do things which are very technical in nature and involves a significant amount of effort. Being the single source of incoming work its not unreasonable that they will want to add it to the product backlog. However, these kind of things tends to be less understood by the business side, and suddenly there’s a conflict: “why do you add theses things that has no value to me?” asks the PO. “you know what, if you need it lets keep it there but please reduce the priority of it” which practically means ok I will let you put it there, but lets make sure that you actually wont work on it.
2. Being the single source of work, a reasonable team working in short iterations will expect backlog items to be of a certain size (typically a few days worth of effort). However, splitting requirements in a sensible manner is really hard work. The “Problem space” natural tendency is keeping the items size much bigger. I’m guessing it makes things easier to manage on their side (and of course avoid the extra work of splitting those into small chunks) and again we have a conflict
3. Not only that the Solution Space demands the things to be small, it also needs them to be FULLY prioritized. Even more hard work for the “Problem” side.

Now don’t get me wrong, there is no right and wrong here. All sides in all these situations are “right”. IF you look at it from there side. 

Treating the Product backlog as an interface

The moment all sides respect the fact that the product backlog is not only there to serve their needs alone, things tends to become much easier. When Technical people understands that the product backlog is the place in which business side describes the “Problem” and respect that. They find it much easier to keep it in a way which is understandable by the business side (avoiding the regular technical language they tend to use internally). When the business side respect the fact that the backlog is used to manage the actual work done. they find it reasonable to invest the effort needed in splitting, prioritization and other activities needed.
So don’t forget the Product Backlog is an interface. it’s the one thing that can be used to establish effective and productive communication by all sides of the business. Take advantage of it.


if you are also

• Having a hard time splitting user stories to shippable items?
• Struggling with predicting when will we reach the deadline?
• Having a hard time with prioritization of requirements?
• Does it seem that the team never understands what you mean?

Then come join our Product owner workshop.

Read more »

Posted in: Agile practices,Scrum

About Myths

To every Myth there is always an equal destructive (Stupid) and opposite counter Myth:

Here are some Examples

Myth

You do not need to design up front

Counter Myth

Design is a one time effort which is best done before you start

Reality
You need to design some of your system up front and some of your system as you go. How much you need atg each stage depends upon your understanding of the problem, you technical skills & your system.


Myth

All user stories may be implemented independently from each other

Counter Myth

We must analyze all the dependencies between all features in order to lay out our critical path

Reality
There will always be some dependencies between different user stories, however a lot of those can be eliminated with some effort invested during story slicing. Those which are left are usually obvious enough for a reasonable team to deal with.


Myth

you don't need architects.

Counter Myth

A strong enough architect can design the system in such a way that anyone could implement it.

or

The architect doesn’t need to code

Reality
Every team needs to have strong design skills, when the projects becomes big enough a dedicated person (aka the architect) to help with the communication of the overall design and helping making sure everyone stays on the same picture is really important. However, the architect in order to be effective, needs to be involved in the day to day programming issues and challenges the team encounters. And at the end it will be the programmers that will do the implementation and they will adapt it according to their understanding so you better have a strong team as well.

Read more »

Posted in: Agile practices. Random Thoughts,Design,Engineering Practices

Creating a Mini-Waterfall

Some people refer to sprints as mini-waterfalls. Well that’s a mistake, sprint are not that.  But a mistake or not, doing a Mini-Waterfalls still seem to be a natural step for some people when they start with their Agile transformation.
So how do you create a mini-waterfall?
well its not very hard like anything else when you create a mini-X you start by taking the X for example:


and then you make the same thing just smaller. like this:

see where this is going?

I encountered several contexts in which a companies, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what left for them to do is just start working in short cycles. So in order to become “Agile”, they take their regular process as is and shrink it down to fit inside short time boxes (anywhere between a couple of weeks to a couple of months) and wait for all problems to disappear (well they just become agile didn’t they?)

Is this bad?

Well actually by itself no. Doing a mini-waterfall isn’t necessarily a bad idea.
on the Pros side we can say the following:

1. Mini-Waterfalls is some kind of an iterative process so you will get more feedback.
2. When you work in a short time boxed iterations you will be forced to work in smaller batches.
3. To support working in small batches you will need to get used to cut and slice the work into small things.
4. and when you work in smaller batches, all kind of things will become visible. For example, your one week manual regression cycle is going to be a real problem. The fact that you only manage building a working version of your product once every three days might also be an issue…

So basically when you start doing a mini-waterfall you are taking one big step in the right direction
However, On the Cons side we should probably say that:

1. Mini-Waterfalls is some kind of an iterative cycle so you will get more feedback.
2. Working in short iterations is just different than working in long cycles.
3. If you don’t do the needed mind shift, working in mini waterfall is going to be very hard
4. And if it gets hard enough , most likely you will stop doing it.

So basically doing a Mini-Waterfall process is not a steady state. Keeping it for long is extremely hard. When you a team starts working in short iterations things that were comfortably hidden become  visible and painful.  and the natural reaction to pain is to make it go sway. You can either fix the problems – maybe becoming more agile as you do, or you make sure to hide them again by reverting back to the older process for example.

So when is it bad?

Mini Waterfalls become bad when organizations confuses them with an agile processes. The difficulties of sustaining a mini waterfall along with this confusion, causes some companies to revert back and claim that Agile is bad. In fact I’ve participated in several emotional discussion with people that experienced exactly that. (BTW trying to go down the this was not agile road only seem to fuel the fire).

Can it be good?

Well I don’t know. However, I’m not sure that’s even an interesting question. Personally I would avoid a mini waterfall. If you try to become agile you should probably try doing something different. There are easier and less risky ways to start. trying Kanban might be a good alternative if you want to start at a familiar place.

But we already are in a Mini Waterfall. Now What?

First realize that by understanding the problem your are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and its really not important at all. Accept the fact that the problems you see are naturally caused by trying to take a lengthy process (designed for long cycles) and squeeze it into  a very short time period (iterations). What’s actually crucial at this stage is to examine the pains and learn rom them.  Each and every pain is a place in which something new can be learnt, about your process, about your team about the context or maybe personally about yourself.  If you manage to locate the actual root cause there’s a good chance you can make real progress. Design small experiments with the goal of finding out what may be the cause of those pains. Try to test different things and see how they effect you team. Collaborate with other parties in the organization and see what they have to say. And always remember that a new process (yes even a mini waterfall) require a new way of thinking to make it work. Most likely old solutions wont solve these new problems.

Read more »

Posted in: Agile Management

Can your team agree to this?

Read more »

Posted in: Agile practices,Engineering Practices