Estimation Considered Wasteful

Estimation, to predict some attribute of the future, is a common method tool. Estimation has long been a standard, some would say overused, tool in the tool box of most development teams. However, these last years estimation has been called out for questioning.

Estimation has always been problematic. One problem is that estimates are often perceived as promises, which they are not. They are only forecasts. Another issue is that estimates, just as weather forecasts, are often wrong. Putting too much weight on an estimate spells trouble. The majority of the criticism, though, does not focus on these problems, but instead on the inherent wastefulness of the practice.

I was recently part of an interesting session, arranged by Johannes Brodwall and Lasse Koskela, at the ØreDev 2009 conference, where we performed a ”shoot-out” between some common, agile estimation techniques. The ensuing discussion got my brain started and at the end of the session I blurted out a suggestion for the ”Rules of Estimation”, which everyone seemed to like. These were also inspired by Michael Jackson’s wonderful ”Rules of Optimization”. So here they are, in a slightly enhanced form. First the rules, then the explanations.

Rules of Estimation

1. Organise the work to make estimation superfluous.
2. (If avoidance is not possible) Do estimation quickly, relatively, iteratively, in collaboration, and with as little precision as allowed.
3. (For experts only) Do estimation in a blink, using gut feeling.

Or in shorter form:

1. Avoid it
2. Do it (if you must)
3. Feel it (for experts only)

Explanations

1. Organise the work to make estimation superfluous

There are pretty clear indications that estimation often is wasteful. By wasteful, I mean it does not add value to the customer. No customer ever ordered an estimate. Some people may regard it as ”necessary waste”, work we need to do to perform the really important work, but Toyota and Lean has shown us that this is actually a fallacy. We are capable of organising our work to make estimation unnecessary.

To be clear, I am not talking about breaking down large tasks to smaller tasks to understand them. Also, I am not talking about discussing the need or ROI of a certain feature, nor designing a possible solution to these needs. I am simply talking about the act of estimating for the purpose of guessing how ”big” something is.

If you think about it, the only objective of estimation is to give a basis for some kind of promise. For example, we may estimate a project to be able to offer our service at a fixed price (a promise). Hence, if you are able to organise your work in a way that promises are not needed, you may save yourself the time and the energy of estimation work.

Examples of techniques that help eliminate the need for estimation are supply chaining, i.e. close collaboration with suppliers thereby removing the need for scoping contracts with attached deadlines, active maintenance, i.e. the marriage of business and IT in a continuous business development activity, thereby removing the notion that one part is a customer and the other a supplier even though both work for the same company, and Kanban, part of which involves working without iterations, thereby eliminating the need for committing (promising) during iteration planning.

There are certainly occasions were some estimation is beneficial, for example to coordinate a large marketing campaign with a major product release, but these cases are outliers and may be handled in a much more agile way than is standard practice today.

To work without the need for estimation is the route that should be preferred and we must insistently strive to get there.

2. If avoidance is not possible, do estimation quickly, relatively, iteratively, in collaboration, and with as little precision as allowed

For some situations, and for most teams today, avoiding estimation is simply not feasible. Some developers are caught by sales people to make off-the-cuff project estimates for their next tender. Most developers estimate projects, even if done in-house. Even agile teams estimate, for release and iteration cycles. While you are working on the cultural change of removing unnecessary work you have to estimate.

If you must estimate, then I suggest you do the work with these principles in mind:

• Quickly, using simple tools. It is pretty obvious that we should at least keep wasteful work to a minimum.
• Relatively. Estimate the size of each item in relation to other items. Then, derive the length in time as soon as we know the duration of a few items, as suggested by Mike Cohn. This is a self-correcting, ego-free system.
• Iteratively. Estimate several times, with additional information and justification of estimates between rounds. This page lists some scientific research that support collaborative, iterative estimation.
• In collaboration. The best estimates are made by more than one person, preferably a team coming from different perspectives (cross-functional).
• Imprecisely. Use as little precision as you are allowed. It is more important that the estimate is correct rather than precise. ”In the future” is a better answer than ”Oct 2″ if you really have no clue when you’ll be done. Use a range and a unit that communicates the level of uncertainty you experience.

3. (For experts only:) Do estimation in a blink, using gut feeling

As I am sure the reader can tell, the second route is a lot of work. It is also a difficult and treacherous path that may lead you horribly astray. Anyone who has been in a fixed-price project that is overdue knows what madness that may surface in these stressful circumstances. But there is actually one pretty powerful short-cut: Use experienced experts.

If you can get a number of experts in the same room, estimating in collaboration using the techniques mentioned above, the estimation may be done quite quickly. These expert can tell in a blink, using questions and gut-feeling, if this is going to be a three-week, three-month or a three-year project. How this works is really a little bit outside of what we know, but ”intuition” or ”pattern matching” can be quite trustworthy in these cases, see ”Blink”, by Malcolm Gladwell.

The first caveat to this is that they would have to be true experts. They must be seasoned veterans (at least 10 years of experience in the field) that have performed similar work in the past.

Another issue is that they may not be willing to do it, often for good reasons. If you have questioned their estimates in the past, or passed on the consequences of a missed forecast to them, they will certainly be suspicious of your intentions.

Conclusion

To conclude, I believe we are better off viewing estimation as a wasteful practice. Since it is wasteful, we should strive to organise our work to make estimation unnecessary. If that is not possible at this time, perform estimation as quickly, simply, and cleverly as possible. Always remember that estimation is a forecast, not a promise. Communicate that uncertainty in the estimates. Using true experts is a powerful way to make good enough estimates in an efficient manner.


This post is a summary of my impressions from the 3rd and last conference day of ØreDev 2009.

If you’re looking for write-ups of the other two days, go here:

• First day >>
• Second day >>

Scott Hanselman, ”Information Overload and Managing the Flow”

Scott is a real super hero when it comes to being efficient. He has been so efficient that Microsoft has swooped him up and turned him into a manager. He utilised this to the full in his talk when he said ”I work for Microsoft” and showed a picture of the death star.

Scotts talk was about how you can handle the information flow and be efficient, doing things right. Of course, there is no point being efficient if your not effective, doing the right thing.

Scott covered the work of some prototypical gurus on becoming more effective, e.g. Stephen Covey’s 7 Habits and David Allen’s GTD (Getting Things Done). Covey prioritises using importance on one axis and urgency on the other, creating four quadrants. Allen talks about 4Ds: Do it, Delegate it, Defer it, and Drop it (I think they were). As Scott pointed out, very few things are really urgent. ”Are the children on fire? No? Then it can wait.”

Scott talked about the psychic weight we put on ourself with our ToDo lists that grow longer and longer. What was once a pleasure to do can turn into a burden. Scott: ”Tonight is the night! Let’s just push through the whole season of Prison Break. Be done with it!”. I can relate to that, having had half a season of 30Rock to look through for many months.

Here were some effectiveness/efficiency tips from Scott:

• Use bosses rule in you e-mail program (use filters to mark them especially).
• Don’t check email in morning. It may ruin your whole day.
• Conserve your keystrokes. Most e-mails can be ignored. The more e-mails you send, the more you get.
• Use Pomodoro Technique. Really focus for 25 minutes.Read aggregates of things that you like but don’t have time for.
• Use ”43 Folders” (a GTD technique), one for each month and each day of the month. Put stuff in there for the day that you need it.
• Use tools like Evernote, Remember the milk, and LifeHacker.

Niclas Nilsson & Hans Brattberg, ”The Pair Programming Show”

This session was completely different from anything else we saw in the conference. Hans and Niclas performed some pair programming theater scenes, complete with acting (well), props, graphics, and sound effects. We still mourn for poor Hans that was hit by that bus. Heart-breaking.

They started out showing the good stuff, how pair programming should look. We saw intense conversation, focus, common goals, and different roles.

After the proper version they showed some anti-pattern scenes:

• Professional Driver: Niclas acted wonderfully in how not to behave as the more experienced in a pair. I will never forget the content look on his face as his fingers were flying and he glanced over at Hans. Very funny! Instead, you must display patience, share equally, transfer knowledge, talk not show. Learning in cooperation must be the goal.
• Backseat driver: When one person of the pair leans back and is disconnected from the work it is less productive than sitting alone. Again, Niclas dominated the scene with annoying remarks and an air of absent-mindedness. For risky or expensive work you really need two people, think of surgeons and pilots. Pair work eliminates big mistakes. Pair also helps handle the pressure. It gives us courage. Another factor is that it gives transparency. No more ”private backlogs” (you know, the stuff that people have in their note books to do on a better day).
• New companion: It is risky to be alone. More often than you think do you wander off in the wrong direction.

I really appreciated this session. Not because I didn’t know most of these things but because of the trouble they had gone to illustrate something that felt true for everyone. Well done!

Lasse Koskela, ”Acceptance Test-Driven Development”

Lasse Koskela has written what is probably, up to now, the best book on TDD and ATDD. It was a pleasure to meet him. Lasse was also one of the guys in the big agile adoption project at Nokia Networks.

Lasse’s message was that ATDD is not (only) about verifying. It is about understanding things together. In his view, ATDD consists of 1. Validation (are we doing the right thing?) 2. Specification (how do we know?) 3. Verification (are we done?). He separates tests from checks (an idea from the contextual testing school), to illustrate that testing is more than checking.

ATDD always includes facilitation and is driven by examples. It does not necessarily have to be automated or performed before programming, but that is recommended and normally the case. ATDD is team activity. It has lower value without the business side and minimal value doing it alone.

My reflection is that maybe ATDD should find a better word than ”test” the same way BDD has, instead of trying to turn the word ”test” into ”specification”? To most people, testing will always be just checking.

Lasse is a calm and assertive presenter. I was a bit disappointed about the models galore in this session. The lack of examples was striking (quite ironic in a session about driving work using examples…).

Cucumber, Aslak Hellesøy

Aslak Hellesøy is one of the real pioneers in BDD, having been an contributor of RSpec and creator of Cucumber. Both these tools are really top-of-the-line when it comes to BDD at this point in time, in my opinion.

Aslak explained briefly the motivation behind BDD. He meant that ”TDD got the names wrong”. BDD involves the ubiquitous language. BDD involves customers. In BDD we work ”outside-in”, meaning we start from the UI and drive the rest of the functionality from what is really needed.

My reflection: I believe BDD people perform a bit of a straw man on TDD, saying that it’s all unit testing and no customers. This is very much not true. ATDD or ”customer tests” as they are called in XP have been a part of TDD all the time.

Anyhow, to do BDD we need to have a common understanding of what ”done” means. One facet of ”doneness” is that all test scenarios run. In BDD these are often called acceptance criteria and are formed using ”Given – When – Then”. Note: ”Thens” are always outputs from the system.

After this, Aslak went into the main topic: Cucumber. Cucumber is a ”story runner”, meaning that you can write descriptions of features and acceptance criteria in a domain language and having that executed by the framework. Gherkin is the underlying language of Cucumber (the tool). It sports full I18N, which is critical for having a natural communication with customers.

Some Cucumber statistics from GitHub: 80 000 downloads, 180 contributors, 40 integrated tools, 1 550 followers on GitHub, 20 screen casts.

No tool talk is complete without a demo, in this case a RPN calculator. My colleague Måns commented at this time that mathematical examples may be convenient for the presenter, but they are irrelevant for most spectators. Hint: Choose your examples wisely.

Aslak showed some Cucumber goodness. Not everybody knows this but it is possible to have templates with tables beneath for sample values. Cucumber will run one example for each row in the table. This is inspired by FIT. A few things that were new to me were backgrounds, tagged hooks and tagged execution. Backgrounds are fixtures for a whole feature. Tagged hooks are used to decide which scenarios should get what part of the setup. Tagged execution is used to decide which scenario should be run, e.g. based on the current language.

One downside with the BDD tools compared to Fitnesse is the availability. Fitnesse tests are on a wiki page, meaning a lot of people may read, edit or even execute them. This helps pull the product owner into the team. When confronted with this Aslak said they were working on a web interface to see and run tests, but that it would not be open sourced. Ouch!

Kevlin Henney, ”Modelling in the Age of Agility”

Kevlin Henney is a developer conference fixture and he is always entertaining and thought-provoking to listen to. For this talk, Kevlin had chosen to talk about modelling and how he thinks we should approach it in these agile times.

Often, he says, the perception of modelling is a problem. Models are not correct. Nor are they specifications. Models are abstractions from a point-of-view for a particular purpose. To create an abstraction we need to omit stuff. Not everything is equally important. One classical example: Underground maps.

The usefulness of a model is what is most important. Powerful question: What is the problem we are trying to solve? The basic usefulness lies in the ”ing” of modell-ing, i.e. sharing and discussing different views. Modelling is exploration.

Some common model pitfalls: Poor model, Model not needed, Wrong model.

My thoughts when hearing about modelling is always to remember that the code is also a model – a very detailed model of reality. And hence, as a model, code can also be the common form we use when discussing and communicating solutions between developers.

That concludes my reporting from the sessions at ØreDev 2009. I will be posting some spin-off reflections on specific topics in the upcoming weeks. Thanks for reading!

This post is a summary of my impressions from the 2nd conference day of ØreDev 2009.

If you’re looking for write-ups of the other two days, go here:

• First day >>
• Third day >>

Rebecca Wirfs-Brock, ”Responsibility-Driven Design”

Rebecca Wirfs-Brock is one of the early though-leaders in object-orientation. Her book on RDD came out in 1990.

Rebecca’s keynote speech was a run-through of different ideas about OO design, from the early days up to today. Maybe it was a little bit too basic and sententious for my taste. She described the early thinking with CRC cards (Class, Responsibility, Collaboration) and how those expermints evolved into RDD. In RDD you describe any role from its stereotype. The stereotypes are: Information holder, Structurer, Interfacer, Service provider, Coordinator, and Controller.

Rebecca tried to describe the greatness about emergent design when using TDD/BDD but did not quite succeed. I got the feeling she had only read about it (I may be wrong). For example, she failed to see where design happened in TDD (she said ”it seems to happen between the lines”). Or was it because she had totally missed the refactoring step?

The most interesting parts of this talk came at the end, where Rebecca alluded to the work of Christopher Alexander, the renegade architect from which the design patterns movement emerged. He had tried to identify properties of things that have life, e.g. ”strong centers” and ”boundaries”. He called this liveable design. The idea, if I understood it correctly, is that no matter which design methods we use, we should always strive to create ”liveable software”, i.e. software whose design display signs of life.

Dan North, Neal Ford, Stuart Halloway, et al, ”Making the sausage”

After RDD I went to an impromptu session that replaced a late programme cancellation. I had heard that Dan North, Stu Halloway and some other guys sat up late the night before, trying to come up with the design for a new BDD tool for Clojure. On this session they would present a super-early draft of what they had. I mean, BDD and Clojure! Any cooler than this and it would be Day After Tomorrow. Who could resist going!?

After an introduction by Dan and Neal, the session mostly consisted of Stu showing their ideas in Emacs. Obviously, they had written a whole bunch of specs they would like to able to write, but for which there was only limited support so far.

It was interesting to hear about some of their guiding design principles. Dan was, predictably, very adamant about ”getting the names right”. Stu thought it was important to use idiomatic Clojure. They wanted to support having tables (like in Fit) and use ”bubble words” like ”should” and ”it” (they are called bubble words because they don’t actually do anything, they just bubble away). Stu wanted to utilise the support for metadata that already exists in Clojure.

Currently, it works through the Clojure reader, using reader macros to convert from the specs to clojure.test code. They were quite unsure if this would be the final design though.

One reflection I had afterwards was that there is a small, but inherent, conflict between the goals of BDD and FP. BDD wants specs to sound like natural language; ”<result> should == <expected>”, but idiomatic FP is more verb-noun; ”== <result> <expected>”.

Scott Bellware, ”Test-Driven Web UI Development”

Scott Bellware, one of the founders of the ALT.NET movement and BDD for .NET guy had a pretty confused session on test-driving a Web UI. It was really hard to understand where he was going with and he never did make it to the finish line.

Scotts idea, if I understood it correctly, was to start by using Selenium IDE to record the interactions with a web GUI. Translate the generated code into Ruby. Then, move this code into RSpec. But instead of stopping there, the developer should continue, by creating abstraction in the ”contextual language” (domain language) to make it easier to add further tests. However, Scott never managed to get it working because of an FF quirk when offline. Also, he had a lot of troubles using MacOS X Exposé (probably due to the dual screen screen). This gave the whole talk an unfinished feel.

Scott was also questioned and disturbed by loud-mouth test guru James Bach in the back, asking why developers insist on automating everything (in a rather derogatory tone-of-voice)? My reflection is that I wonder if James has ever participated on an agile team? How are they supposed to do regression testing without automation if you deliver to production once a week? Or what about those who deliver almost every day? Or 50 times a day that some teams do? There is clearly a large gulf here between the leading testers and the leading BDDers. And it’s a shame! I really like how the contextual school of testing (which James founded) fits into agile work perfectly.

I think I liked what Scott was trying to do. However, I have one caveat: Don’t call it TDD when the tests are generated by a recorder. That’s just plain wrong.

Tyler Jennings, ”Strangling a Java Web App with Rails”

The title of this talk was truly electrifying. I guess that’s what a lot of us Java/Ruby guys will be doing this coming decade (a joke with maybe a bit of truth in it). However, I managed to miss the first half of the talk. Secondly, I think Jennings had too much material; the word ”strangling” popped up the first time after 52 minutes (of the 50 min talk…).

However, I managed to understand that the basic idea is to hook in a servlet filter after the Java application and handle the call if it was not handled by Java. His application used JRuby-Rack, an adapter for the Java servlet engine into, for example, Rails. That way, pieces could be first implemented in Rails and then removed from Java. Of course, JRuby was used from Ruby to call into to the Java app if the need arose.

Michael Samarin, ”Making Web Applications for iPhone”

This talk was a disappointment as it basically turned into a commercial for Dashcode, Apples RAD tool for web applications. Samarin did show some cool stuff though. He quickly and easily created an iPhone web app that controlled a video show on his MacBook. Tools he used were Dashcode, NetBeans, Quicktime, AppleScript, and XMPP.

If you want to quickly get an iPhone web app up and running you really should have a look at Dashcode. There is no need for approval from AppStore and with Safari you can make it look a lot like a real app.

Adam Skogman & Emil Eifrem, ”NoSQL”

This session was packed. I had to stand at the end of the room. Apparently, NoSQL databases are hot hot hot. And luckily, we got a really good presentation on the topic from the two well-rehearsed and knowledgeable speakers.

NoSQL databases were created to handle two major problems with SQL databases: Scalability when the amount of data is huge, and flexibility, when the domain is complex. They come in four different flavours: Key-value stores, Big table, Document, and Graph.

Key-value stores are most suitable for scalability. They are essentially ”bit buckets”. Some notable contenders are Oracle’s Berkeley DB and LinkedIn’s Voldemort

Big table is a Google invention. The basic idea is that you can have any column for any row and instead of creating a lot of tables you simple have a lot of columns. And I mean a lot! There could be hundreds of thousands of columns. Google App Engine and Apache Cassandra are two candidates here.

Document databases store ”documents”, e.g. a JSON structure, to handle the semi-structured character of most worldly things. Couch DB and RIAK are two popular examples.

Graph databases model the world in nodes with relationships, creating a graph. Attributes may be placed on both nodes and relations. These are mostly aimed at the flexibility problem (not scalability). Graph DBs have ”whiteboard friendliness”, meaning that’s normally how people model their world. Look into Neo4J or Allegrograph, for example.

Since very few have the scalability problems of, say, Amazon or Google, in a poll most people predictably were interested in Document and Graph databases.

To end it all the speakers were very clear that they were not being confrontational against relational DBMSs. NoSQL is pronounced ”Not only SQL”. Believe it if you will…

Gojko Adzic, ”Specification Workshops”

Gojko Adzic is the author of two books on how to bridge the communications gap between developers and customers. He is a funny, no-nonsense guy. He told a very entertaining story about how he could not get a bank account when he moved to the US because he was not registered as a voter. In the US people really believe the content of their DBs, he said. After a lengthy discussion he was allowed to move on in the process, but now it was blocked because he had not payed taxes last year. He tried explaining that he had migrated to the US only two days ago and had payed tax in Serbia. However, they honestly believed that their databases contained all information. Gojko answered: ”This is ridiculous! There is no way. The two government computers in Serbia are busy playing Mine Sweeper”.

Acceptance testing is based on the idea that better customer acceptance can be achieved if we discuss and define examples of how it is supposed to work before we design our solution. Only unit tests will not do, since customers simply don’t understand them. Furthermore, they often hide this because they don’t want to sound stupid. What may sound obvious to me is not obvious to you.

Two good tips around requirements from Gojko: 1. Ask ”why” more often. This will help you understand the true need. 2. Never accept solutions from customers. Instead, say: ”What do you need?”.

About the customer/product owner I think Gojko is right on the money. He said that ”know-it-all customers” are as mythical as dragons. Customer is a role. Understanding the true needs should be a team effort, a collaboration between those who know the need and those who can fulfil it.

A ”Specification workshop” is a meeting where you discuss needs, requirements, and examples for upcoming development. Gojko thought that name often worked better with busy people than ”Example-writing workshop”, which sounds unimportant to them.

Here were Gojko’s advice for these types of workshops:

1. Collaborate on specifications.
2. Challenge requirements.
3. Discuss examples.
4. Involve the whole team.
5. Schedule meetings well in advance (for busy people).

My reflection after this session was that it is certainly true that customers don’t know what is needed. However, I think Gojko’s solution could be improved. His solution was this: Let the team work with the customer. But that doesn’t really solve the problem, does it? The customer doesn’t know much more from this. The problem is this: Nobody really knows! It is software we’re talking about. You could ask users but they won’t know either. They feel the pain directly, but often lack the overview. Or know what’s possible. However, there are professionals out there that know how to talk to users and distill their needs. They are called user experience (UX) specialists and are experts on user research and user-centered design (UCD). I believe they have a really important role to play if we want to be effective, not only efficient, with agile methods.

Robert Sabourin, ”Out of the Frying Pan and Into the Fire – Efficiency in Scrum”

The day ended with a keynote by Robert Sabourin, a very loud Canadian methods expert. He talked about different ways that people get methodology wrong. I didn’t find it very amusing, I am sorry to say.

One nugget of coaching though: As a coach, start by asking the staff for recent stories when thing went wrong or went extremely well. For each story, drill down in full detail. This may help you find where the problems and strengths lie.

This post is a summary of my impressions from the first conference day of ØreDev 2009.

If you’re looking for write-ups of the other two days, go here:

• Second day >>
• Third day >>

Marc Lesser, ”Accomplishing More by Doing Less”

Marc Lesser is a speaker with an interesting background, having spent 10 years as a zen monk but also started and managed businesses. His talk started a little unusual, with 60 secs of meditation.

Lesser has expressed his thoughts in what he calls the Less Manifesto. The manifesto is basically saying that if we have less fear, assumptions, distractions, resistance, and busyness we can focus on doing more of the things that really matter to us.

I liked how Lesser expressed that he, as a boss, was responsible for all his employees – not the reverse, which is common in management echelons.

My personal reflection was that all in all the talk was maybe not as mind-blowing as one could have hoped, but a pleasant and interesting way to kick off the conference.

Joris Kuipers, ”What’s New in Spring 3.0″

This talk was basically a run-down of features of the upcoming Spring framework 3.0. Since I am hardly a power user of Spring, my impressions are a little sketchy.

So, what’s new? Configuration annotations has been possible for a long time, but they have been extended with new annotations. Also, there is work on the JavaConfig project, where you may configure your system using code. Also, there is a new Spring EL, an expression language how to use values from other places, e.g. properties files.

Another big thing is improved support for integration tests, by making it easier to build the context for the tests. Spring already has its own test runner and tests can transactional tests.

Spring has added support for REST, or JAX-RS ”Spring style”. For example, they have included a HTTP method conversion to enable the use of PUT and DELETE.

I should also mention better support for embedded databases like Derby.

Douglas Crockford, ”JavaScript – the Good Parts”

Douglas Crockford is a famous programmer, one of the 15 selected programmers in the book ”Coders at Work”. He is the founder of JSON and has written a great book himself about JavaScript.

This talk was basically a personal characterisation of JavaScript, both the good and the bad. JavaScript (JS) is a language of many contrasts. It has some catastrophic flaws as well as brilliant design ideas. It is programmed by everyone from non-programmers to experts. Everyone seems to think that they can use JS without learning, which is strange for a programming language. Another factor is that if you want to program in the browser environment you have no other choice. It may not be what we want but that’s just so. Often when people complaining about JS, the are really annoyed with the DOM. But it’s not all bad. JS succeeded where Java failed miserably.

Crockford described some of the really bad stuff in JS, e.g. global variables, semicolon insertion by the compiler, and fake arrays. From C it has inherited some awful stuff: blockless if statements and expression statements, for example. Crockford gave a wonderful explanation of why curly braces always must go on the right side in JS. If not, a series of unfortunate design decisions may conspire to totally change the meaning of some code without any visible error. Crockford has written a tool that checks for these things called JSLint.

So, what’s good about it? Most people don’t realise it implements lambdas, anonymous functions. The language supports dynamic objects that can change behaviour. Also, loose typing and object literals where mentioned on the good side.

Klaus Silberbauer, ”User Experience – Because Nothing Else Really Matters”

Klaus Silberbauer is a ”Concept Director” from Creuna, DK. In his talk, he described his model of UX and how they work with UX at Creuna.

One insightful comment he made was that UX is nothing that can stand on its own. It has no value until it is implemented. Another was: Users don’t think – they feel.

Towards the end, Silberbauer presented a contrasting model to Jesse James Garrett’s famous UX model, which included more than design.

Andres Almiray, ”Java Testing in the Fast Lane”

This was a talk about testing Java from Groovy. Groovy is a dynamic language on the JVM and is ”98% Java” (a few things are missing, like inner classes).

Groovy is excellent for testing Java code. For example, Groovy has assertions built in. You can mock nicely with closures and construct DbUnit tests with compile-time checked XML data set. BDD tools he recommended were Easyb and Spock. Almiray also recommended FEST for testing Swing UIs.

Petri Haapio, ”Agile Adoption at Enterprise Level”

Petri Haapio told us some tales from the agile adoption at Nokia Networks (about 14 000 employees) with clarity and truthfulness. He was part of a task force called ”Flexible R&D”. They constructed the so called ”Nokia Test” for determining the agility of their teams. He noted that this was only to be used as a base for discussions, nothing else. Bas Vodde and then Craig Larman were brought in as external experts.

The adoption was based on volunteering, information sharing, and hands-on coaching. It very much seemed like a bottom-up approach. He said it took 18 months before anyone in the top-management team knew about the transition. Some severe impediments he mentioned were the needed change in management culture and the tool department, trying to enforce poor tools for the job.

Today, ca 60% of all product development efforts use agile methods at Nokia Networks. The biggest product group doing agile contains about 600 people and is developing embedded software. Haapio also presented a study showing that the more agile the more people were satisfied with their work life.

Stuart Halloway, ”Clojure”

Clojure is one of the new language kids on the block. It is a Lisp derivative with great Java integration and some interesting concurrency solutions. Stuart Halloway has written the first book on Clojure. Stuart is an energetic and very witty guy. Just one funny idea from this slide: He had prepared and marked particular slides suitable for tweeting with a little bird in the corner.

His motivations for using Clojure were these:

1. Java interoperability. In sugared form it contains less parenthesis than Java so don’t worry about that.
2. Lisp. The language is homoiconic, which means that the language itself can be expressed as data structures of the language. Thereby, very powerful meta programming is available. Clojure also contains a very useful feature called ”destructuring”, which means data structures can be taken apart directly by the function args.
3. Functional language with higher order functions (functions that take functions as arguments or return values). Some common Lisp operations have been renamed. For example, ”car” is called ”first”, ”cdr” is now ”rest”. Heresy for true lispers, but very logical in my view.
4. Concurrency/State. Data is immutable by default. Mutable data must be changed in STM, Software Transactional Memory. One interesting idea was that the data becomes the contract between parts of the system (not the operations). This may sound fragile but its not, since the data transformation operations in Clojure are so powerful and fast.

In perhaps the quote of the day Stuart called Design Patterns ”essentially a turd that could not be abstracted away”.

Bloggande terriern har härmed glädjen att presentera sin första gästbloggare. Herbjörn och jag har träffats en del på konferenser. Han berättade i veckan att han hade gjort en intervju med Jim Webber på Thoughtworks som för närvarande inte fanns på nätet och undrade om jag ville publicera den. Det vill man ju inte undanhålla sina läsare! Håll till godo.

- Joakim

”Affärsfolk har spaghettihuvuden”

av Herbjörn Wilhelmsen

Som arkitekt eller utvecklare försöker vi kämpa emot komplexitet i alla dess former. Det är sällan framgångsrikt och enligt Jim Webber som leder brittiska konsultbolaget ThoughtWorks globala arkitektursatsning är det inte heller ändamålsenligt.

Att förstå affärsprocesserna är en utomordentligt viktig förutsättning för att kunna bygga en tjänstearkitektur, Service Oriented Architecture – SOA, som verkligen stödjer verksamheten.

-Om du inte involverar affärssidan så vet du inte om du gjort rätt eller om du gjort fel. Med SOA får vi chansen att spegla affärsprocesserna i systemen så att de kan förändras och utvecklas på ett samordnat sätt.

Oberoende av teknik så baseras en bra SOA på en god förståelse av affärsprocesserna . När den förståelsen ökar kommer också förståelsen om vilka tjänster som behövs öka.

IT-proffs vill ofta minska spaghettin i system samtidigt som de önskar att bygga system som avbildar verksamhetens behov på ett bra sätt. Dessa två önskemål står i konlikt med varandra. Jim Webber förklarar:

-Affärsfolk har spaghettihuvuden, och det menar jag på ett sympatiskt och medkännande sätt. IT-proffs tänker mer i abstraktioner, olika lager i lösningarna och framförallt gillar vi raka linjer i systemkartorna. Affärsfolket däremot arbetar ute i den verkliga världen. Vi sitter i en europeisk stad och jag kan inte se en enda rak gata utanför, för så fungerar det i den verkliga världen. Det är rörigt, grötigt och spaghettiaktigt.

Jim Webber är van vid att hantera spaghetti

Nya och mer eller mindre slumpmässiga kontakter är en viktig del i det som för affärerna framåt. De kontakterna kan vara, och är ofta, annorlunda än den egna verksamheten. En beskrivning av en sådan rörig verklighet kan kännas motbjudande för många IT-proffs . Deras omedelbara reaktion är att försöka räta ut spaghettin, men detta lyckas sällan och om det lyckas tillför det inte så mycket värde. Så istället för att försöka få bort all spaghetti behöver vi en spaghettivänlig integrationsstrategi – och det är just det SOA är enligt Jim Webber.

Organisationer har alltid varit intresserade av företagsövergripande arkitektur, s.k. Enterprise Architecture, det är det som får affärsverksamheten att fungera ihop med IT-stödet. Enligt Jim Webber är lösningen på problemet enkel:

-Vi borde sätta affärsfolket in i förarsätet som arkitekter. Att uppnå verklig Business Agility är endast möjligt om affärsprocesserna avbildas i tjänsterna så att när en process ändras så kan tjänsterna ändras på samma sätt.

Det är inte nödvändigtvis enkelt att bygga en SOA på det sätt som Jim Webber förespråkar, eftersom det kräver hårt arbete och omfattande ingenjörskunskaper. Målet är att ekosystemet av tjänster som produceras enkelt och rättframt matchar det som verkligen pågår i affärsverksamheten. Alternativet är knappast önskvärt:

-I den värsta av alla världar går affärsverksamheten och IT-systemen i olika riktningar. Det gör det svårt att föra ihop dem för det gemensamma syftet som självklart är att skapa affärsnytta.

Fakta: Dr Jim Webber har en doktorsgrad i högpresterande databehandling (high performance computing) men har efter sin akademiska karriär fokuserat på informationsintensiva system, Web Services och SOA. Han höll ett föredrag om ”Guerila SOA” på konferensen Developer Summit i Stockholm 2008 och intervjuades i samband med denna konferens. Intervjun spelades in och återfinns här.

Återigen braskande rubriker: Bara en tredjedel av IT-projekten lyckas. ”…så har det sett ut i 40 år” säger prof. Torsten Cegrell i Computer Sweden 18/10 2009. Cegrell menar att det nästan alltid är i beställarkompetensen som det brister och att kravspecifikationerna är alldeles för stora. Jag håller med Cegrell om det, men han missar ju helt poängen. Jag tycker faktiskt att det är på tiden att vi begraver den här myten om vad som utgör lyckade eller misslyckade projekt. Diskussionen är alldeles för viktig för att vara baserad på en meningslös definition.

Anledningen till min njugga inställning är definitionen av vad ett ”lyckat projekt” innebär. Är du intresserad av agila metoder är du säkert inte förvånad. Innan du läser vidare, tag gärna 10 sek och fundera på vad du tycker att det borde innebära om någon säger att ett projekt blev lyckat. Och stopp! Försök att komma förbi den där inlärda definitionen. Vad känner du i magen vore rätt?

Klar? OK. Min gissning är att du tänkte det som de flesta tänker: Att det man ville uppnå med projektet infriades. Kanske tänkte du att det ledde till något positivt? Att världen är bättre än den var tidigare? Att folk trivdes och att det blev en långsiktigt bra lösning? Att nyttan var större än kostnaden? Alla bra och värdiga mål. Men hur ser den vanliga definitionen ut, den som alla blivande PL får lära sig?

I tid. På budget. Med överenskommet innehåll.

Men vad i själva…!? Men oj, vad galet det här är! Och alla verkar använda den här definitionen. Utan att ifrågasätta. Utan att tänka. Är det inte dags att sluta sprida det här tramset? Allvarligt… sluta. Snälla…?

För det första, nyttan med projekt är inte med i definitionen alls. Det betyder att vi kan ha projekt som anses lyckade som inte levererade någon som helst nytta eller värde för kunderna till projektet. Undrar om kunderna håller med om att projektet var lyckat? Eller tvärtom så kan vi ha ett projekt som alla experter anser misslyckat men som senare visar sig vara extremt lyckat på andra sätt.

Ett exempel, som jag hämtat från Jesper Blomberg, ek.dr på Handelshögskolan. När bygget av Globen stod klart räknades det som en total katastrof. Man hade kraftigt underskattat kostnaden av bygget och blev klara på tok för sent. Eländes elände. Globen var ett fiasko och ett åtlöje. Men se, vad händer? Den marknadsföring och dragkraft som skapades blir en magnet för hela området. Köpmännen och människor dras i drivor mot den stora bollen. Evenemangen i Globen lockar sjuka mängder turister (och pengar). Globen blir en symbol för hela Stockholm. Man hade nämligen underskattat en annan sak också: Nyttan! Globen räknades 10 år senare som ett av Sveriges mest lyckade byggprojekt. Någonsin.

Sanningen är faktiskt den omvända. Många av de riktigt lyckade projekten drar över både tid och budget. Det är helt naturligt. Om något går bra, varför sluta? Varför ändra ett vinnande lag?

Nästa problem: Start- och slutpunkter för ett projekt är helt godtyckligt valda. När börjar vi egentligen? Slutdatum är lika godtyckligt och dessutom helt taget ur luften baserat på hypoteser och gissningar om framtiden. Vad är det som säger att vi ska utvärdera projektet just där och då? Det är helt godtyckligt. Och som vi såg i globenfallet kan omvärldens syn på projektet variera över tiden. Så hur ska vi veta när vi ska utvärdera?

Ta projektet att skriva det här blogginlägget som exempel. När började det? När jag skrev det första tecknet? När jag fick idén till inlägget? Eller när jag första gången funderade på frågan? En vecka sedan eller 10 år sedan. Det går inte att säga. Är det slut när inlägget är publicerat? Eller när jag har fått pengar? Vad gör jag om jag sa att det är slut, men sedan vill någon annan publicera det? Vad händer om jag gör en ny version?

Ni hör, det blir löjligt. Varför ha med något så godtyckligt som ett slutdatum i definitionen?

Det tredje och riktigt bisarra i det här är detta: Graden av hur lyckat ett projekt anses vara ska tydligen bestämmas av de värden på tid, pris och omfattning som vi uppskattade (det betyder ”gissade”, gott folk) i början av projektet. I början är en synnerligen illa vald referens. Det är den tidpunkt när vi vet som allra minst av vad som väntar. Ursäkta en ärlig fråga men vad har detta överhuvudtaget att göra med om projektet är lyckat eller inte? Om värdena skiljer sig från de ursprungliga (gissade) är det är väl kanske snarare ett vittnesmål för vår välkänt, begränsade förmåga att göra korrekta utfästelser om framtiden än ett bevis på projektets eventuellt uselhet?

Speciellt svår förefaller den här jämförelsen i fråga om kombinationen överenskommet innehåll och IT-utvecklingsprojekt. Användare och beställare av IT-system har nämligen notoriskt svårt att veta vad de vill ha. IKIWISI kallas den här effekten; ”I Know It When I See It”. Det är därför vi har uppfunnit iterativa metoder. En process med hög grad av förändring kan inte styras på annat sätt än genom att ta små steg, mäta och utvärdera. Vi styr försiktigt framåt och försöker så gott vi kan rätta oss efter den feedback som vi erhåller under tiden. Det är så man styr empiriska processer. Punkt. Så varför i all världen skulle vi tillmäta något värde till en jämförelse mot en ursprunglig beskrivning som vi vet är fel? Eller ännu hellre, varför skulle vi ens ge oss på att i detalj beskriva (specificera) omfattningen av ett utvecklingsprojekt? Det är bara fel. Fel och missledande.

Till sist vill jag säga det här: Jag har inget emot projekt. De är varken goda eller onda. Projekt är verktyg. De passar för vissa situationer, inte till andra. Till långsiktig, kontinuerlig produktutveckling passar de sällsynt illa. Projekt är en social konvention som vi kan ta till då och då för att entusiasmera människor och skaffa medel för speciella jobb. Något viktigt som människor kan samlas kring. Inget annat.

Lycka eller olycka kring projekt är lite som sanningen; förvånansvärt subjektiv när man ser närmare på det.

I mitt förra inlägg presenterade jag en modell för prioritering med olika nivåer. Inget speciellt överraskande eller provocerande där, kanske. Anledningen till att jag tycker att prioritering inom utvecklingsarbete är värt att skriva om är två fundamentala poänger som jag tycker inte uppmärksammas tillräckligt:

1. Inom produktutveckling kan de minsta detaljerna vara avgörande. Hur många iPhone har inte Apple sålt efter att människor har sett och känt på den underbara rullfunktionen? Eller ett annat exempel: Hur rappa systemsvar till användare i en stressad miljö kan utgöra skillnaden mellan acceptans och motvilja. Hur ”läckert” eller användbart systemet är ner till minsta pixel kan vara avgörande för dess framgång.
2. Prioriteringar görs, vare sig vi vill eller inte. Om inte rätt personer är på plats kommer prioriteringarna att göras ändå – helt enkelt för att de måste göras. Enda skillnaden är att de då görs omedvetet, alternativt av personer som inte ser helheten, inte helt förstår vad som är viktigt, inte exakt vet hur användarna arbetar eller hur företaget tjänar pengar.

I det här inlägget tänkte jag utforska prioritering på lite olika nivåer ännu mer. Hur fungerar traditionella metoder? Hur kan man nå högre nivåer och mer finkorning prioritering? Vem ska egentligen prioritera?

Låt oss börja med den rådande, det man kan kalla för den traditionella modellen (handen på hjärtat, det är ju mest en tradition, eller hur?). Hur brukar det fungera? Jag bedömer lite löst att konventionella metoder eller utkontrakterad utveckling ungefär når upp till nivå 1,5 i modellen (en bit över produktnivån). Prioritering görs ofta på produkt- eller projektnivå, men därefter är det sämre. Typiskt stödjs inte prioritering på finkornigare nivå än projekt/kravspecifikation.

Vad som i stället sker är en indirekt och omedveten prioritering på intressentnivå. Verksamhetsprocesserna är vaga. Beskrivningarna stämmer inte. Kopplingen till projektet är oklar. Användarna är osynliga. Användarroller okända. Kravspecifikationen är skriven och ”allt är lika viktigt”. Det här är en beskrivning av en svag modell för prioritering eftersom 1. den är inte medveten 2. den görs på mycket grovkorning nivå när det egentligen är så att det finns både viktiga och oviktiga saker inom varje område som produkten rör.

Hur kan man då göra för nå högre nivåer på prioriteringsskalan? Det första vi behöver göra är att tydliggöra vilka prioriteringar som faktiskt görs så att de blir medvetna. En typ av prioritering mellan intressenter är den mellan olika verksamhetsprocesser. Ska vi stödja inköp med bättre lagerkontroll eller är det säljanalysen som behöver bättre underlag? För att göra detta behöver vi givetvis förstå hur våra verksamhetsprocesser ser ut och arbeta för att optimera flödet genom dem.

En annan typ av prioritering är den mellan olika typer av användare (roller). Vi skulle till exempel kunna välja att prioritera Adam, 21 år, från nätgenerationen eller är det kanske informationen till David, 28 år, finansanalytiker på SHB som måste bli bättre? För att kunna göra detta krävs en djup kunskap om sina kunder och användare. Det är tyvärr fortfarande skrämmande vanligt idag att utvecklingsteam ”skyddas” från sina användare, vilket gör att kunskapen om dem är begränsad.

För att nå ännu högre skikt, prioritering på tema eller funktionsnivå, krävs ett regelbundet samarbete mellan kund och leverantör. Det här brukar de flesta agila/lättrörliga team klara av eftersom det är inbyggt i de agila metoder som de försöker följa. Tyvärr missar man lika ofta process- eller rollprioriteringen som jag nämnde ovan, vilket gör grunden som hela prioriteringen står på skakig.

Har vi kommit så långt vi kan nu? Absolut inte. Moderna, lättrörliga metoder är baserade på samarbete mellan roller. Det är svårt, men om vi utnyttjar samarbete har vi stora chanser att låta prioriteringen fortsätta i än mer detalj. Om vi har alla kompetenser på plats, varför inte utnyttja det? För att ta ett exempel: Hur kan programmerna avgöra om det är viktigast att lägga tid på att göra en läcker animering på startsidan eller lägga till en hjälptext vid formuläret som många missförstår? Det kan de inte, eftersom det både kräver kunskap om företagets affärsutveckling och användningen. På detaljnivå vid design av ett system kan en framgångsrik prioritering bara göras om områdeskunniga, specialister på användbarhet och tekniskspecialister alla får komma till tals. Tillsammans kan de göra välbalanserade avväganden i den aldrig sinande ström av beslut som måste fattas. Att rätt personer ges chansen att tycka till kan göra hela skillnaden.

För att sammanfatta: Jag är övertygad om att prioritering är viktigt ned till den minsta beståndsdelen av en produkt eller ett system. Det är därför viktigt att organisera arbetet på ett sådant sätt att prioritering på olika nivåer kan göras och dessutom ske i samarbete mellan rätt personer. Många arbetar idag på ett sätt som skapar obalans i utvecklingsarbetet. Är du som kund frånvarande eller oengagerad ökar risken markant för att det görs felaktiga prioriteringar, vilket leder till att du får fel sak levererad – eller kanske rätt sak men utformad på fel sätt. Hur som helst minskar värdet du får ut av din investering. Är du beställare av produkter eller IT-system, ställ dig gärna följande fråga när utvecklingsteamen kallar till nästa möte: Har du råd att inte samarbeta?

Visst vore världen underbar om vi kunde göra allt vi ville?! Om vi hade all tid i världen, ständigt fyllda av positiv energi, vadandes i drivor av betalningsvilliga kunder som gladeligen väntade på sin tur…

Riktigt så verkar det inte fungera.

Tyvärr kräver våra ”moderna” liv prioriteringar; familj framför arbete, löpning är viktigare än en öl med en bekant, skriva blogg i stället för att sova. Ständigt krävs nya prioriteringar och beslut i en aldrig sinande ström. Eftersom vi inte kan göra allt vi vill göra måste vi välja. På samma sätt är det när vi utvecklar produkter eller system. Detta inlägg handlar om det svåra arbetet att prioritera inom utvecklingsarbete.

Prioritering handlar i grund och botten om det svåra beslutet att välja att lägga sin tid och energi på det som jag just nu anser viktigare än annat. Samtidigt väljer jag bort detta andra. (Det här sista brukar kallas för att ”prioritera ned”, vilket ungefär är lika ologiskt som barnens ”jättelite”.) Frågan är bara, vad finns att välja på? Och vem bör välja?

Det första vi måste inse är att prioriteringar och val finns på olika nivå. Figuren nedan ska föreställa en slags prioriteringsmodell. I modellen har jag valt att lägga den grövsta nivån av prioritering underst (stora block ligger alltid underst). Denna nivå kallas ofta för produktportfölj, det vill säga att vi prioriterar mellan olika produkter. Så här kan det låta: ”Öka på Modell CX, lägg ned aktiv utveckling av Card Reader”. Denna typ av prioritering förefaller rätt vanlig idag bland produktutvecklingsföretag.

Om vi kliver upp en nivå i modellen hamnar vi mitt i vidareutvecklingen av en produkt eller kanske ett egenutvecklat, internt IT-system på ett företag. På denna nivå måste prioritera mellan intressenter av systemet. Den här typen av prioritering är vanlig idag, men görs enligt min mening ofta på ett ganska indirekt sätt, kanske genom att godkänna ett projekt eller genom hur en kravspecifikation utformas.

Nästa nivå av prioritering är något som vi kan kalla teman, användaraktiviteter eller funktionella block, det vill säga större funktionsområden för produkten. Ett exempel på det här kan vara att rapportmöjligheterna inför årsrapporten är viktigare än administrationstjänsterna. Om du arbetar med flexibel (eller ”inkrementell”) kravhantering, en del av moderna utvecklingsmetoder, arbetar du fram detaljerna i behoven parallellt med utvecklingen. Här finns alla möjligheter att prioritera. Typiskt kan man göra detta någon gång i månaden eller kvartalet i samband med en övergripande planering av en ny version. Intressant är att om vi öppnar denna möjlighet varierar ofta prioriteringen kraftigt – ett tydligt tecken på att den behövs.

Vi kan gå längre än så. På högre nivå måste vi besluta mer precist vilka funktioner eller ”stories” vi vill utveckla. Använder man Scrum eller någon annan lättrörlig utvecklingsmetod görs detta typiskt vid förberedelserna inför eller vid en iterationsplanering. Det handlar helt enkelt om att man som produktutvecklingsledare någorlunda vet vad något är värt och hur mycket det kostar så att man kan välja det som ger mest värde för företaget. ”Ska vi utveckla den snygga produktpresentationsrutan eller ska vi gå in på platsönskemål?” kan vara en typisk prioriteringsfråga på denna nivå.

Nästa möjlighet till prioritering hittar vi i scenarier – eller testfall som en testare skulle säga. På hur många sätt kan funktionen köras igenom? Vilka felsituationer kan uppstå? Vilka scenarion är viktiga att stödja just nu och vilka kan vi vänta med? Notera att det här kan vi bara göra om vi för varje funktion beskriver ett antal exempel som vi vill se fungera. Alla dessa kommer inte att kännas lika viktiga. Är det till exempel viktigt att visa ett meddelande om att en sökning fick noll träffar eller räcker det kanske att man ser en tom träfflista till vidare och i stället lägga tiden på validering av kreditkortsnummer?

Och det är faktiskt inte slut här! Inom varje testfall, hur implementationen utförs, finns ett stort antal prioriteringar att göra. När nu funktionen ska utformas finns givetvis saker i användargränssnittet som inte är lika viktiga som andra. Exempel: ”Ska länken verkligen få en ny bild och ny text när fliken är utfälld?”. Och givetvis har utvecklare och testare sina egna tekniska beslut och prioriteringar att göra.

Så vad vill jag säga med allt det här? Jo, att prioriteringar inte bara finns på övergripande nivå (portfölj eller projekt) utan kan faktiskt göras ändå ned till den minsta implementationsdetalj. Och det visar sig vara en essentiell egenskap.

Nu har vi en gemensam modell att utgå ifrån. I mitt nästa inlägg tänkte jag försöka beskriva varför det är viktigt med alla dessa nivåer och vem som egentligen bör prioritera. Tills vidare, fundera på om ni inom er organisation gör medvetna prioriteringar på dessa nivåer. Hur högt når ni?

För några veckor sedan meddelades på lite omvägar att Thoughtworks (TW) kontor i Sverige är stängt. Tidigare svenske chefen har lämnat eller fått lämna sin post och försäljningsarbetet har därmed avstannat. TW har för närvarande bara en anställd i Sverige idag; Ola Bini, som formellt inte är anställd i Sverige och spenderar mycket tid utomlands. Enligt uppgifter från TW lägger de inte ned verksamheten i Sverige, bara lägger den på lågvarv ett tag. En ny chef för svenska kontoret ska rekryteras så småningom.

För oss utvecklare som är lite ”fans” av TW är det här givetvis nedslående nyheter. Det är tråkigt att inte ett erkänt duktigt bolag som TW ska kunna lyckas i Sverige. Det kan vara intressant att fundera på varför. Varför har TW så svårt att etablera sig här?  Är det deras eget fel eller beror det på hur marknaden fungerar i Sverige/Stockholm? Här är mina teorier, med betoning på teorier:

1. Ramavtalen. Alla myndigheter och många organisationer handlar bara efter ramavtal. De har ingen möjlighet att ge ett helt projekt till TW vare sig de vill eller inte.
2. Säljstrategi. TW:s attityd har varit att de vill helst ha egna projekt, möjligen ta expertkonsultroller, men inte underkonsultjobb. De vill heller inte använda underkonsulter. På en marknad som den för konsulttjänster i Stockholm, som mer kan likna en slags ”katten på råttan, råttan på repet”-konstruktion, blir detta problematiskt.
3. Bristande självinsikt och tålamod. TW har eventuellt överskattat sitt namn en hel del. TW är kända bland somliga utvecklare, speciellt de som har en dragning mot agil utveckling, men helt okänt för andra. Högre upp i organisationer, som IT-chefer, ”CIO”:er eller inköpare är de oftast helt okända. Att arbeta in ett nytt namn är ett tungt och tidsödande arbete.
4. Finanskriseffekter. Givetvis har TW påverkats, speciellt i Australien och England har en del konsulter hamnat ”på bänken”. Det löfte om stöd från de etablerade kontor har uteblivit när fokus har legat på mer närliggande problem.
5. Bristande säljerfarenhet och kontaktnät. Försäljning handlar till stor del om vilka du känner och har bra relationer med. Känner du inte rätt personer är det väldigt svårt att sälja stora saker eller projekt.

Jag tror alltså inte att det här misslyckandet enbart beror TW, ej eller på marknadens i Stockholm utan troligen en del av båda. TW:s strategi och inställning har passat extremt illa till den rigida, skyttegravsliknande IT-marknaden i Stockholm. Låt oss hoppas att de kommer tillbaka.

Klockan är strax före kl 10.40, då starten ska gå. Det är lördag, sent i september 2009. Det är soligt och ca 17 grader varmt. Jag står på startlinjen tillsammans med S. Plötsligt säger hon ”Där står Börje Salming!”. Jag säger ”Näe…”, men när jag vrider på huvudet ser jag att, mycket riktigt, tre meter till vänster står Börje. Han ser tuff och vältränad ut. Helt oberörd. ”Jag ska fan ta honom”, tänker jag.

Uppladdningen inför loppet har varit helt ok för min del. Kanske lite väl hård träning förra söndagen och möjligen att gröten i magen från i morse fortfarande känns tung i magen, men i stort sett är jag förberedd. Ingen sjukdom på länge. Folk har undrat varför jag inte springer 30 km och svaret är väl att jag inte har tränat för det. Jag har tränat med S och vi har medvetet tränat på kortare distanser (6 – 17 km) för att bli bättre på milen. Vi har inte kört stenhårt, men sommaren var rena träningslägret och efter sommaren har vi tränat tre ggr i veckan. Tempoträning har vi kört varje torsdag sedan sommaren. Två gånger har vi varit i Lill-Jansskogen bakom KTH och kört backträning.

Mitt mål idag är 1.20 men min förhoppning är 1.15. Men jag är osäker eftersom jag aldrig har sprungit distansen förut. Milen är ju i stort sett en sprintdistans och halvmara är långt för mig. Men 15 km? Jag räknade så här: Jag springer milen på ca 45 min (en bra dag). Lägg på 50% för 5 km extra ger 67,5 min. Lägg på 5% för det är en längre distans så jag kan inte hålla samma fart (tumregeln är ju att lägga på 10% för varje dubbling av distansen), vilket ger ungefär 71 min. Sen måste man lägga på tid för att Lidingöloppet är så sjukt kuperat. På 15 km är det 3-4 km som är riktigt hårda så en minut extra för var och en av dessa ger 75 min, dvs 1.15 tim.

Vi står i startgrupp 2 av 4. Starten går (någon minut för sent?) och jag sticker iväg ganska fort men inte överdrivet. Jag har något hundratal löpare framför mig i gruppen. Det är lite trångt vid vägen efter några hundra meter, men det släpper snart. Jag har ingen löparklocka och tänker springa mest på känsla. Efter ca 1 km frågar jag en kille vad tiden var. ”4.15 hade jag” blir hans svar. ”Hörde jag rätt?”. Jag sänker farten något och hoppas att jag inte ska få betala för detta.

De första 5 km är relativt flacka med undantag av km 2. Jag har därför haft som taktik att försöka kapa lite tid här, vilket jag behöver väl senare. Problemet är att magen känns tung och jag mår lätt illa. Känns inte riktigt som min dag. Försöker sträcka ut stegen i stället. Efter Kyrkviken, när vi närmar oss 5 km, gör jag en ny kontroll med en medlöpare. ”Du snittar 4.50″ säger han. Det är jag nöjd med, men jag är helt klart påverkad av tempot.

Några km senare kommer vi in på 30 km-spåret igen vid norra Lidingö. Det är här det riktigt jobbiga börjar. Efter fem långa lidingölopp och ett antal träningar i terrängen är det givetvis ingen överraskning. Det är små korta backar upp och ned mest hela tiden. Det här kan suga musten av den bästa löpare. Här har jag bestämt mig för att hålla igen, men det är jobbigt ändå och relativt orytmisk löpning, vilket förstärks av alla andra löpare i spåret.

När jag kommer upp till villaområdet strax före Grönsta gärde är jag så trött att jag stannar till vid villaägarnas egen vätskekontroll. Jag hinner inte stoppa mig innan hjärnan har stannat kroppen. Jag går ca 15 m innan jag tänker: ”Vad håller jag på med?” och drar iväg igen.

Vid Grönsta är jag sliten. Jag minns då att jag har en ”nödraket” (kolhydratgel) i bakfickan. Jag trycker i mig halva ungefär och tar vatten vid vätskekontrollen. Hemligheten vid Grönsta är för mig att aldrig snegla åt vänster, där man tydligt ser målet. När jag startar den tunga backen efter kontrollen är jag mycket trött. Inte alls den känslan jag ville ha i detta läge! Jag tänkte mig att ta det lugnt men spänstigt uppför de två jobbiga backarna och sedan släppa loss alla krafter. Men jag är för trött.

Någon kilometer senare är det ungefär samma läge. Jag är dock pigg nog att se en Charlotte Kalla som, röd i ansiktet efter loppet, gående är på väg åt andra hållet. ”Heja Charlotte!” ropar jag till. ”Heja Heja” svarar hon, mest med ryggmärgen. Varför jag hejar på någon som inte tävlar är mer oklart.

Efter ytterligare någon km till är jag nära ”väggen”. Jag har sprungit så många år att jag känner igen det vid det här laget. Hjärnan protesterar, pulsen slår vilt och man riktigt känner mjölksyran rusa runt i armarna. Händerna börjar kännas bedövade. Inget annat att göra än att hålla igen. Försöker att minska lite ”lagom”. Och det verkar funka! Efter några minuter kvicknar jag till litet grann och kan öka något igen.

När man börjar närma sig målet tar viljan över, det tror jag gäller för de flesta löpare. Vi kan stå ut någon km med illamående och alldeles för högt tempo eftersom vi vet att det snart är slut. På sista rakan före gärdet skriker jag ”Kom IGEN nu sista biten!!!”. Det känns bra. Några löpare som har stannat sätter igång igen. Jag spurtar så gott jag kan, men jag vet att det inte ser ut att vara mycket till spurt från åskådarnas vinkel. Klockan ovanför målet står på 11.58.30 när jag kommer in på gärdet. Jag gör mitt bästa för att klara mig under men kommer in ungefär kl 11.59.05.

Så här efter loppet är jag ganska nöjd. Lidingöloppet verkar ha ”slarvat bort” min tid för jag finns inte med i resultatlistan, men med tanke på klockan ovanför målet borde jag ha fått en tid på runt 1.19 tim, alltså någon minut under mitt mål. Kanske till och med lite bättre. Ss tid justerades ned något (troligen för att starterns och målklockan inte var synkroniserade). Jag är mest glad för hennes skulle eftersom hon klarade sitt på 1.30 helt perfekt.

Uppdatering: Jag fick igår ett brev från kansliet med följande innehåll:

Du fick tiden 1:19:05. Hemsidan kommer att uppdateras imorgon.

Hur gick det då för Börje? Jo, det gick mycket bra. Han sprang ett helt jämnt lopp på 1.24 ungefär. Men jag tog honom! Jag tog Salming.