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