Short bit

"Organizations exist to create value for their stakeholders". I wholeheartedly disagreed. Then I noticed that I had read 'shareholders' instead of 'stakeholders'. Then I realised that 'value' doesn't necessarily mean 'monetary value', although this seems to be the norm these days. A good old-fashioned company strives for continuation, not short-term gain.

Where will your company be in 100 years?

Agile en BPM: bijt het elkaar?

De Agile manier van softwareontwikkeling wordt sinds een kleine 15 jaar steeds populairder. Je kunt de werkwijze het beste zien als tegenhanger van de sinds de late jaren 80 steeds logger en zwaarder geworden “professionele” softwareontwikkelmethoden. De bedoeling van laatstgenoemde methoden is natuurlijk het voorspelbaar, calculeerbaar en betrouwbaar maken van het ontwikkelproces. Maar hier is een grens aan. Voorbij die grens verwordt het ontwikkelproces tot een bureaucratische papierwinkel en vergt zelfs de kleinste aanpassing maanden werk.

Bij Agile pakt men de zaken anders aan: men probeert om voorspelbaarheid, calculeerbaarheid en betrouwbaarheid te bereiken door een focus - zoals ook beschreven in het Agile Manifesto- op klantwaarde en een flexibele houding. Onder de ‘agile-minded’ mensen heerst dan ook een verfrissende opgeruimdheid. Ze zijn wars van bureaucratie en moeten niets hebben van het al te gedetailleerd vastleggen van specificaties van systemen en processen.

Business Process Management (BPM) is een tak van sport die zich bezighoudt met het vaststellen en verbeteren van bedrijfsprocessen. Grondigheid is hiertoe vereist. De gedachte ligt dan ook voor de hand dat Agile mensen hier niets van moeten hebben. Het gevaar is hier immers groot dat de nadruk meer op processen, documentatie en bureaucratie komt te liggen. Toch heb ik het idee dat BPM en Agile elkaar kunnen aanvullen, mits je ze naast elkaar zet en niet zozeer probeert te mengen.

Een van de angstige vragen van mensen wier IT-afdeling overstapt op een Agile werkwijze is “hoe is de lange termijn geborgd als we vanaf nu in het wilde weg gaan bouwen?” Het antwoord is natuurlijk dat we helemaal niet in het wilde weg gaan bouwen. We gaan alleen stoppen met van tevoren alles tot in detail in ontwerpen uit te kauwen inclusief alle uitzonderingen, maar detailling gaandeweg aanbrengen op het moment dat het nodig is. Voor wat betreft het IT-gedeelte is dit een zinvolle manier van werken.

Dat wil niet zeggen dat het aan de businesskant niet noodzakelijk is om goed te weten wat de visie/missie van de onderneming is en welke processen dat doel moeten bereiken. Dat staat echter los van de IT en is precies het werkveld van BPM. Door het vaststellen en vastleggen van deze informatie ontstaat een raamwerk dat als uitgangspunt dient voor alle discussies over wijzigingen aan of uitbreidingen op bestaande functionaliteit.

Met dit raamwerk om op terug te vallen kan de IT-afdeling de business het beste van dienst zijn en heb je de grootste kans op het vergroten van klantwaarde. Dat is per slot van rekening het doel. Op deze manier vullen Agile en BPM elkaar dus aan.

Increasing the value of the Product Backlog

In Scrum all the work revolves around the Product Backlog. This is the list showing all of the items the customer wants to have. This is the list the Scrum Team takes it tasks from. In this article I will explain how to increase the value of the Product Backlog and therefore the Scrum process. Please add your thoughts.

First of all: logically the customer will want everything that’s listed on the Product Backlog. He should, because he has given the input for the list in the first place. Unfortunately time and money are usually not infinite. This applies to all organizations whether they use Scrum, Waterfall or any other software development method. If you just build everything the customer wants you run the risk of not getting things finished in time or at all.

In my organization time is the most important constraint. We work in two week sprints, but releases happen only every three months. If not enough Backlog items have reached status 'done' to release a certain functionality it will be pushed back another three months.

The root of the problem is that the customer’s wishes include various sorts of bells and whistles. We are talking about things that reduce manual steps, make the functionality easier to work with or even just make it look prettier. Things that promise to increase value, but extend beyond the basic functionality. Often it takes a lot of hours to realize all of this and it can mean that the functionality takes months to reach production status.

That’s why in Scrum we strive to work on the most important bits of functionality first. If there’s time and budget left in the release you can implement the less essential elements, but you can at least release the core functionality.

This means that you have a Product Backlog where the items are prioritized properly. This often involves splitting Backlog items into smaller items. So you must know and describe them in more detail. But we are told that in Scrum you should avoid describing your Backlog items in too much detail. First of all we can’t expect the customer to know every detail beforehand. Secondly getting too much detail too early will probably make it old news by the time you will need it. How to tackle this problem?

What we should try is to strip every backlog item down to its barest essential. Everything that can be omitted without breaking the functionality should be seen as a separate Backlog item. So instead of trying to describe every possible aspect and ask the customer whether he needs it and how bad he needs it you peel off as many aspects as you and the customer can think of. The description of these secondary Backlog items can be general. Further detail will come when the Scrum Team is ready to pick it up. Note: redirecting things into separate Backlog items does not automatically mean that they will not be built! It just means that we’re not building them right away.

When you have determined the most essential and the less essential Backlog items it’s much easier to prioritize. The goal should be to release the core functionality as soon as possible. First of all the customer will start getting value from the functionality and secondly he will get used to it. There is a good chance that some of the less essential items that were planned for a next release will be scrapped as the customer is content with current functionality. That will give the Scrum team time to work on the next project.

Let’s look at an example. Suppose an organization wants to build a 'Customer order information portal'. There is no existing customer or product portal. The organization only has a regular website. It's not difficult to identify the big items:

1. There should be login functionality. This way the system knows what customer to display the order information for.

2. There should be pages displaying the order information.

3. There should be a connection between the front office (HTML files) and the back office application (database).

4. There should be reporting functionality for the customer so he can print or send information to himself via email.

5. There should be logging functionality documenting who logged in and when, to help debugging and for security reasons.

These items are very general. There is hardly any core functionality discernible. Items 4 and 5 can be thought of as less essential, but more importantly all of the items could contain all sorts of bells and whistles. So we should try to peel them to the core.

Let's look at the first item: login functionality. Which aspects can you think of?

· The customer needs to be able to log in, so you should build ‘something’ that contains usernames and passwords and ‘something’ that can verify what the customer has entered on the website against this module.

· Functionality for the customer to choose his own password via the portal.

· Functionality for the customer to retrieve or reset a lost password.

· Functionality to have multiple accounts per customer (for instance for management, financial department etc.).

· Functionality for the customer to login automatically based on .Net Passport, Gmail or something along that line.

Really, with the first item you can go live. All the other items are nice, but not having them doesn’t make the customer portal impossible. Therefore the other items can be put on the Product Backlog with a lower priority. And it’s not necessary to have the precise details of these items yet. You do the same with the other general items.

Now the big challenge will be convincing the customer. The customer can be very concerned about the features that are put lower on the priority list. In the old system (other waterfall) it usually meant that it would be scrapped later on. It’s the job of the Product Owner to keep the focus on what is being built now and not what is being built later. The customer has to understand that it’s more valuable to have basic functionality soon than to have complete functionality at once at some unknown point in the future. Usually after having seen how it works the customer is more comfortable with the idea.

So summarizing in this article I argue that it's good for the process to get the Product Backlog right. You should at least have the most basic version of the functionality at the top of the list. Everything that goes beyond it should be lower in priority. This ensures that the Scrum Team is always doing what's most important to get the functionality valuable enough to release.

Scrum in a nutshell

You work in IT. You’ve heard about Scrum, but aren’t sure what it is. People claim it’s the answer to all our prayers. Others say it’s doomed to fail and a waste of time.

For that past 9 months I have worked with Scrum in a large company and want to share my experience through a series of articles. In this very short introductory article an explanation of what Scrum is.

1. Scrum in a nutshell

Most people are aware of the fact that most IT projects are still over budget, not delivered in time and/or do not necessarily provide the functionality that the end user needs. Many project management frameworks battle these problems in various ways. Scrum is basically one of them.

Of the three complaints mentioned above the most important one is not getting the business what they need. Seriously: delivering on time and within budget means nothing if the end product is useless. However, time and budget are also essential because they’re the principal reasons for aborting projects!

In the Scrum method much focus is laid on making sure the end product is what the business needs. To achieve this users have to be involved not only at the beginning and the end, but through the whole process. The sooner we know we’re on the wrong path the better, because it means less (and easier) rework and thus less time and money.

This is achieved by working in a series of timeslots, called sprints. At the end of a sprint the newly built functionality is demonstrated to representatives from the userbase. They can give feedback and approve parts certain parts, saving time later during acceptance tests.

The second focal point is cutting all unnecessary time loss. During software development many steps are mandatory that only serve the process and not the goal. Excess documentation is a good example. Modest documentation is enough. Communication is much better served by a live demo or sitting behind someones pc. Note: nobody said to do away with documentation altogether!

A big step towards cutting time loss is reshuffling of the teams. In the traditional waterfall method gathering requirements, designing, developing and testing are strictly separated. Each phase awaits conclusion of the previous one. But not all scope items in a release take an equal amount of time to process.

Scrum tries to tackle this by forming multidisciplinary teams based on scope items instead of profession. One team is responsible for one scope item at a given time. This means they don’t have to wait for other scope items that are more complex than theirs.

This has been a very short explanation. In the future I hope to publish some more articles about Scrum, drawing on my own experience. If you have any questions, please feel free to contact me.

Ed Luijendijk (30-05-2010 )