Through careful reengineering I discovered a list of essential features an application must have and compiled it as backlog items ready to use for your product backlog.

As a procurement manager I want the application to be expensive, in order to live of the bonus I guess when I negotiate a 1% reduction in price.

Acceptance criteria:

• The price of a minimal installation is at least 5 figures
• The price for a full installation is at least 500.000 Euro
• Bonus points when there is a mandatory support option

As a procurement manager I want the application to scale only by upgraded to an enterprise super deluxe edition, so my daughter can have a horse for Christmas.

Acceptance criteria:

• A demo setup needs at least 8GB RAM and 4 cores
• A system for 100 users needs at least 5 such machines, plus the same number of machines as a hot backup which you need at least once a month.
• You need 20 machines when 10 of the 100 users want to use it concurrently.

As an administrator I want the application to have only minimal documentation if at all, so I can claim to be an expert after reading all of it in an hour and charge a higher salary.

Acceptance criteria:

• The documentation is preferable non existent.
• Lengthy documentation is acceptable as long as it written so bad that nobody gains any knowledge from reading it.

As an administrator I want the application to be void of any user community, so nobody can provide easy free solutions to problems I claimed to be really hard.

Acceptance criteria:

•  the apropriate tag at stackoverflow has a maximum of 200 followers and less then 1000 questions.
• If you are looking for a real expert (one that actualy understands the product) you have to pay other my monthly salary as an hourly wage or look in a mental asylum.

As an administrator I want the application to rely heavily on as many other products as possible, so the beneficial effects of the application on my workday are multiplied.

Acceptance criteria:

• The application needs a database management system installation from a specific vendor. The database itself needs to qualify as an enterprise application according to this criteria
• The application needs at a queuing system, even when it doesn’t have any interface to any other system but itself.

As a person responsible for deploying clients I want the application only to run on IE6 or earlier so the people stop asking me for upgrades to Windows 7 or god behold these Apple thingies.

Acceptance criteria:

• When the application is run in an IE 7 or above a message appears: “You are not running a compatible browser, please upgrade to IE6″
• When any other browser is used the application should react with a http 500 or it should crash the browser.

As the manager responsible for deployment of the system I want the system to be still in development, so I never have to install anything.

Acceptance criteria:

• The application is labeled early beta or preferable with
• “latest build from Toms machine”

As a consultant recommending the application I want the application to be really hard to install and equally hard to keep alive, so my contract stays safe for the next years to come.

Acceptance criteria:

• The short installation overview has at least 50 steps
• a skilled person can’t install the system in less then 3 days.

As a network administrator I want the application to really hog the network, so I can get a larger budget for new shiny hardware.

Acceptance criteria:

• the application uses protocols like http in a way that makes caching completely impossible.
• the application downloads itself completely on every restart.

As a user I want the application to be really slow so I can’t blame the application for not getting anything done

Acceptance criteria:

• every interaction with the application (like moving the mouse) causes the application to freeze for at least one second.
• every use case requires at least 10 such interactions.

As a user I want the application to start up really slow so I can get some coffee and drink it too in the meantime.

Acceptance criteria:

• Startup needs at least 10 minutes
• The application needs to restart at least twice a day.

As a CIO I want the application to use single sign on so I can claim we are doing it without bothering with what it actually means.

Acceptance criteria:

• The application contains its own single sign on system
• The applications SSO solution is completely incompatible to anything else (other wise we would get asked to integrate them)

As a person responsible for the security of the system I want the application to have cryptography because it is soooo coool.

Acceptance criteria:

• The application contains some cryptography code, preferable with nice acronym like ROT13
• The cryptography is really hard to configure, so something easy like SSL isn’t acceptable
• All private keys involved need to get emailed to the support distribution list, along with the password (thats what our processes require)

I think this view ia a little to simplistic. Java developers like fast results and progress just as all the other developers. But if you have a look at the environments in which java is used, you’ll often find large corporations and that is causing problems. If you are lucky enough not to have worked in a large company let me describe this wonderful experience.

In the typical large company you can’t just talk to the future users, ask them about their problems and solve those using software. You also have to adhere to all kinds of rules. Rules about how to implement the login. Rules about how to talk to other systems. Rules how to format your code. Rules about how to blow your nose. All those rules easily amount to one or two thousand pages.

While the amount of rules certainly is a problem rule alone aren’t a problem. I’m an absolute fan of rules in order to steer software developments. The problem with those “Large Company Rules” (LCR) is they are based from the largest most complex (or complicated) system the company ever encountered. Thus they dictate an architecture fit for a system consisting of 20 subsystems doing some thousand transactions per minute.

But surprisingly most of the systems are really quite simple with only few users. Yet they have to use everything IBM sells.

So all the java developers get used to EJBs, SOAP, Messaging and what not and many think this is the only way to write systems.

And that is the thing I blame many developers for: To many ignore what happens outside their current project. They don’t read, they don’t learn. And while I think the companies are guilty of making everybody think development in java is slow and complicated every single developer is guilty when at some day in the future his current project ends and he realizes there is no more demand for his skill set.

Obviously this doesn’t work. But telling them they won’t get no plan at all doesn’t work either. So what to do? I think one of the keys to a useful plan (actually for every useful document) is to determine who is going to read it and what it can or should do for the reader.

So here is a list of things a plan can do for you or other people involved in the project plus some properties your plan should have in order to fulfill this purpose:

Basis for Go/No Go decisions. This happens early in the project or actually before the project, depending on your definition of project. For this the plan should state: What the project will cost, and what the expected ROI will be (Note: ROI is not a single dollar amount but a function of t -> $). AND it must state a measure of confidence in the plan. If you make any kind of decision based on a plan without understanding the intervals of confidence you are playing lottery. Also note, the intervals of confidence will always be asymmetric. While it is not seldom that a project will end up twice as expensive as planned, it very seldom happens in no time at all.

Basis for coordination. When all you have to do is queue up the tasks in the project an finish them one after the other, there is not much use for a plan. But if you have dependencies between the tasks things get interesting (and ugly). When your infrastructure team need three months for ordering and setting up the production machine, you better order it three four moths in advance. This of course means you have to know your going live date that much in advance. If you don’t have such dependencies, you don’t need the plan. Actually when people get introduced to MS-Project they start drawing lots of dependencies between tasks because it is so coool when MS-Project moves the tasks around based on these dependencies. But they go completely unaware that every dependency is a problem waiting to happen. Therefore dependencies should get minimized.

Thats it. I don’t think there is anything more to it. Of course you have to redo your plan constantly in order to realize when the basis for a decision is about to disappear, or when some kind of coordination won’t work as anticipated.

But there are also things plans are getting used for although they aren’t good tool for it:

Getting things done / Motivating people. Just face it: It does not work. Just because you write down that I have a day for a task doesn’t make it more likely that I’ll get it done in that time.

Not forgetting stuff You don’t need a plan for that, you just need a list. Oh and when you prioritize that list you pretty much have a backlog, isn’t that nice?

Yelling at people You are the boss, you can yell at whom you want as long as you don’t care that it demotivates them. You don’t have to screw up a plan to do that.

Anything I forgot? Let me know. Thats what the comments are good for.

There exists also another Definition of Done. It isn’t written down anywhere. And it is completely useless:

“You are done with a piece of code or a feature when you won’t need to touch it again”

It is useless, because it is impossible to achieve. Only code you delete might not change anymore. Of course there is still version control, so even that piece of code might come back.

Your not done when there is nothing to change. You are done when you provide some business value.

But in a couple of discussions lately a question popped up: Do we really do Scrum? Or do we only Scumbut and if so, is it a bad thing?

Well I guess if we are really doing Scrum is in the eye of the beholder. The is no test for ‘scrumminess’ except maybe an examination by Ken Schwaber. We try as hard as we can. We have problems, but we try to solve them, although progress is sometimes slow. And that is exactly the point where I think the label Scrumbut is just to simple.

We should distinguish at least two types of Scrumbut:

The Waterfall with lipstick Scrumbut: you have basically a waterfall process, but you are doing daily status meetings called scrums. Your project manager is called Master. If you do this kind of Scrum. Call it waterfall, as it is waterfall.

But there is also the We-aren’t-there-yet Scrumbut:

The product backlog is messy, but you realize it and are working on improving on it. Not everybody understands the meaning of the Definition of Done, but you realized it and you are working on it. This is not Scrum according to the book. But you are moving towards it.

So here is the point: At the heart of Scrum is improvement. Constant improvement. All the practices of Scrum rotate around making problems obvious so you can fix them; Establishing an environment where you can talk about problems so you can find ways to improve. If you are on a way to such an environment, thats awesome. Go on with your Scrumbut, it will turn into Scrum over time. Scrum is hard. It requires a lot of change. It won’t work on the first day of the first attempt.

But if you reduce Scrum to a version where it doesn’t make you change, you are missing the important part. This kind of Scrumbut won’t show you your problems, it just puts new names on things. This is Scrumbut in it’s worst form.

Actually you can and should apply the same differentiation to Scrum by the book: With some projects I get the impression they are adhering pretty much to the rituals of Scrum. But nothing happens. The reviews happen after every Sprint, but no change happens. At one time someone from such a project even said to me: “We don’t have anything to improve.” Sorry, but I don’t buy that. Just as every non trivial program contains a bug and a superfluous line, every team has room for improvement. If you don’t see it, you are not looking hard enough.

There is no point in doing Scrum without changing. You don’t gain anything from doing Scrum, except making challenges in the team and in the project obvious. If you still don’t see them, or if you don’t react on them you gained nothing.

Doing Scrum is only the start of a long way of improvement. Get going.

Biweekly Scrummy Scrum

Its inspired by the daily Scrum of a normal Scrum project but happens as you might have guessed every other week. The purpose of this short meeting is to exchange problems and ideas for their resolution and so far it works really well. Although it is really not much time we invest we learn a lot.

It is open to everybody interested in Scrum and it is limited in it time frame. It starts right before the lunch break, so there is a strong incentive for not letting it run to long. So far we don’t use a fixed structure. It is more like an open discussion group. Maybe in the future when we all have somewhat settled for a basic implementation of Scrum we’ll use a more strict structure, where everybody reports about her problems, possible fixes are discussed and a plan is formed about what to do about the problem until the next meeting.

You might think it is a Scrum of Scrums as described in many book, but I don’t think so since the teams involved are completely independent and don’t work on the same or related projects. Also it isn’t only for scrum masters, but for everybody interested. If comparable at all it is more like an Improvement Community as described in Succeeding with Agile, which is a group interested in a certain kind of change, working together in order to support that change. But so far we don’t have an improvement backlog, but maybe that would be a great idea.

What do you to improve you agile/scrum/kanban or projectmanagement skills inside your company?

These processes I am talking about look like this:

1. Come up with an idea (I like that process step)
2. Prepare a cost estimate and a business plan for the project
3. Present these to a committee
4. Update the documents from step 2. based on the feedback from step 3. (Its said that many comments are like ‘there should be a company logo on the title page’ or ‘you really shouldn’t center align the page numbers’)
5. Present these to another committee which will decide on the funding of the project.

While this might be of some value of for large projects, it will kill small projects and put medium into trouble right from the beginning. For smaller projects the overhead of the approval process will not only delay the project  and increase the cost by a considerable amount of money. It will also kill of any motivation of anybody in favor of the project.

But it is even worse for large projects. Since once the project ha the approval, who will be inclined to question the project? Of course everybody will be bickering about the stupid idea the project is. But who does step up and says: “You know maybe the guys in control of my salary and career made a mistake and we simply should buy an of the shelve product for 1% of the money?” Correct: No one. The task of questioning the purpose of a project is done by someone else.

This would be OK, if the committee is in a better position to judge these decisions. But it isn’t it has the information of one person, carefully crafted for making sure the decision is made in favor of that person. You might assume just as well, they don’t have any information at all.

How about an approach like this: Give every employee a budget. Top people might get a bigger budget. Employees might invest into a project, or keep the budget. A percentage of the budget left over at the end of the year would get payed the employee. Another percentage would get added to the budget of the next year. When invested into a project, the investing employees get a certain part of the ROI of that project.

Certainly not the best solution. But certainly better then what is going on in companies right now.

Scrum is a Social Thing

Scrum is about team building, Scrum is about the relationship to your customer and the relationship to your users. Let me elaborate, why I think this is the case, and why it is so important for success.

So lets start with some practices of Scrum that are inherently social:

• The complete Team does the estimates. This makes the estimates more reliable, but possibly more important, it is team building. Everybody in the team makes an estimates, everybody commits to the sprint back log, so noone can go “I said all the time it doesn’t work”. We commit as team so if we don’t succeed, it is we that failed, not him.
• The Product Owner is present during estimates. Of course this is important to provide information about the user stories, but it also means she knows all the discussions going on. So if there is a crucial part that everybody forgot about she can’t go: You are professionals, you should have known we need this feature as well. If she didn’t spoke up during planning, she obviously forgot about the important obvious task as well. So everybody is in one boat again.
• Tracking impediments makes sure the impediments get out of the way. But it also communicates, that somebody (the Scrum Master) cares about the problems of the team and works hard to make the environment as productive as possible. This makes a big different, even if some impediments can’t get resolved. Also the team is encouraged to work on the impediments themselves. And trust me, rearranging office furniture together is better then an expensive team building training.
• The Product Owner determines what to achieve in terms of business value, but the team decides how to implement that. This makes a big difference in motivation. If you don’t believe me, get a copy of “Drive” by Daniel H. Pink it will tell you the same.

Hopefully I have convinced you that Scrum contains a lot of social engineering in its practices. But why is this important? Because Agile projects today are done with the same people who did waterfall projects last year. The practices of Scrum don’t make the software development process any better or faster in a direct way. It avoids some waste in the form of irrelevant documentation and features nobody really needs, but when looking at failed projects I don’t think that little avoided waste would make much of a difference.

But team building does. Motivation does. Compare tasks you enjoy and tasks you love, done with a team you hate or fear or a team thats rightly called so. For me an example would be filing my tax compared to creating software. There is easily a factor of ten in productivity … so there is a silver bullet. There is a single thing that might boost performance by a factor of (or close to) ten:

Get the team motivated.

Scrum might help you with that. This also explains why Scrum will be done wrong in many cases: You can’t just apply rules, since rules are a killer for motivation. You have to understand the ideas in scrum, listen to the team and foster the right kind of environment. Then and only then Scrum will increase your chances for success.

“Planning is the death of any project” http://bit.ly/bFYkAW Just an entertainment story, but fun nonetheless

I’m certainly proud to produce something that is considered fun. Yet my little story actually has some serious background. Of course the simple task of making coffee doesn’t justify elaborate project planning. But which task does? As we have seen, simple tasks don’t.

So how about complex tasks? Tasks that depend on circumstances in many ways, like e.g. balancing a stick on a finger, or playing table tennis. It would surely simplify the task, if we knew exactly when to make which movement. But we can’t plan this kind of thing, because the tiniest deviation from the intendend movement at some point in time will greatly change the required action some time later.

The coach teaching me project management had a great example of a project needing very accurate planning: When you build a nuclear reactor, the core will get encapsulated in a huge steel chamber. There are only very few cranes huge enough to move this thing. And they need a rail track to get to the building site, as well as a foundation for the crane to stand on. Rent of this crane is expensive as hell and you have to fix the dates years in advance. Everything that was needed for this crane and the needed structure, was planned with great care, to make sure everything was in place.

Few of us build nuclear reactors. For all others check these rules as a guide for the amount of planning justified:

• How plannable is it anyway? Don’t try to plan the unplannable. Get it out of the way instead. This is what many agile approaches do, when they implement the most risky stuff first.
• Do you have fixed dependencies between tasks? A plan becomes more helpfull, when you have many dependencies between tasks, possible with long ramp up or preperation time. As with the crane: The task of moving the steel shell wasn’t  very long, but the preperation had to start years ahead. Without a plan it gets easy to kill a deadline long before it comes into sight.
• What is the damage done, when you don’t stick to the plan. In some projects, the only damage done is that somebody has to adjust all the plans. In that case, you might just as well scrap the plan.

A cup of coffee

Are you able to make a pot of coffee? I guess you are. At least until you try to plan it. Here is the first version of a plan to make coffee:

• put a filter in the coffee machine
• put coffee in the filter
• put water in the coffee machine
• switch the coffee machine on
• wait until done

But wait, there are tons of things that could go wrong with that plan. So let’s make the plan a little more complete:

1. ask everybody in shouting distance if he or she want some coffee
2. find out if there is a filter available for the coffee machine, if not go buy some. If this takes longer then 5 minutes, restart at 1.
3. put the filter in the coffee machine.
4. calculate the amount coffee needed for the number of persons determined in the last occurrence of step 1
5. find out if there is enough ground coffee available. If not check if enough coffee beans are available and a mill to grind them. If not ask a neighbor if she has enough resources. If not buy some. If this takes longer then 5 minutes, restart at 1.
6. if you have coffee beans grind them.
7. put the ground coffee in the filter.
8. calculate the correct amount of water for the number of people
9. put that amount of water in the machine
10. make sure the coffee machines power plug is plugged in
11. switch the coffee machine on
12. find the manual for the coffee machine and find out how to determine that the coffee machine is actually done. If you can’t find the manual, download it from the Internet. If you can’t find it, buy a new coffee machine and restart at 1.
13. wait for the described symptoms to appear
14. proceed with the instructions from the manual

Now that is awfully complicated. I’d guess there is a lot of stuff that could go wrong, so we need a Quality Assurance Process. So every step should get done by two independent persons, both well trained in coffee making. The result of each step should get reviewed by a third person. Coffee making is only allowed to proceed when the results of the process of both cooks is within the allowed tolerance of the target values. Target values and acceptable tolerances are to be defined during the project inception phase by a committee of experts.

That looks very promising, but since there are so many people involved there is some risk of problems, so we better setup a project management office for monitoring progress. And while we are at it we get some lawyer involved to proof read contracts made with neighbors or shops selling coffee and filter. Also a chemist might be useful for testing water, coffee, filter and air for pollutions and harmful substances.

In the mean time I’ll grab a cup of tea. Let me see what I’ll need …