Bloggarkiver

Fra rebelsk ungdom til moden gaselle

Hvert år presenterer DN lister over landets såkalte gasellebedrifter.  For å sikre seg status som gaselle, må selskapene kunne vise til høy omsetningsvekst og sorte tall på bunnlinjen over minimum fire år (DN). Det finnes flere eksempler på gasellebedrifter som har mestret kunststykket med å opprettholde en bratt vekstrate i flere år, en økning som gjør seg gjeldende i omsetning og antall ansatte. Den smittende entreprenørånden, engasjementet og de lyse framtidsutsiktene har fått flere investorer til å finne frem sjekkheftene, og historisk sett har slike gaselleforetak gitt dem respektabel avkastning (Bastesen). Dette betyr naturligvis ikke at samtlige hurtigvoksende foretak vil ekspandere inn i evigheten. Investorenes evne ligger her i å skille en moden gaselle fra en overivrig, rebelsk ungdom. Det finnes flere årsaker til

Jakten på enhjørningen i Sand Hill Road

Enhjørning (Unicorn) er amerikanske investorers begrep på en ny type digitale bedrifter som raskt oppnår en selskapsverdi over 1 milliard dollar. Kjente eksempler er Instagram, Snapchat og WhatsApp. Det er slike bedrifter Silicon Valley-investorer nå er på jakt etter, siden fondene deres stadig blir større og avkastningslogikken de må levere på er like ubønnhørlig som før. Kvalifikasjonsprosessen deres er om mulig enda mer brutal. Jeg møtte en av de ledende VC-ene i Silicon Valley rett før sommeren. Her får hver partner i gjennomsnitt 1-2 forretningsplaner hver dag, gjennomfører 1-2 møter med oppstartsselskaper i uken og gjør 1-2 investeringer i året.  En av partnerne var tydelig på at han ikke hadde

Drep et møte!

Siste uken før ferien var rolig, med kunder og kolleger på ferie, eller i samme modus som meg – med tid til refleksjon over halvåret som var gått, analysere resultater og samle løse tråder. Denne første uken etter ferien er også relativt rolig, med tid til å snakke lenge med kolleger, få tak i den nøkkelpersonen som ellers alltid er utilgjengelig, drodle rundt nye tanker man har fått etter en tid borte fra jobben, og med tid til å planlegge neste sesongs oppgaver og mål. Dette er en periode der man kan fokusere på det som er viktig, og ikke bare det som haster. “Fra neste uke begynner det igjen”,

Why do projects fail?

… and how easy is project recovery? Project failure facts and figures are in the eye of the beholder unless the statistics are granulated into a level that explains the exact science behind the numbers. Failure percentages vary from 40 to 80 percent and are, logically and primarily, based on qualitative information gathered through interviews. This percent of failed projects, whether it be 40 or 80, is a tragedy and is an indication that the project management profession as a whole has a lot of work to do in the times to come! But which are the main reasons why projects fail? Through studies of three similar analyses conducted within

When Scrum fails

David Andersen used his Meetup talk i Oslo last week to describe a start-up’s journey from Scrum to a more Kanban based way of doing things. I seldom work with start-ups, but David’s talk resonated with my experiences in contexts that have little do do with start-ups. I summarized the insight in a tweet: “The Meetup with @agilemanager yesterday reinforced my belief that Scrum works best when you are in a state that you should avoid being in” I freely admit that as tweets go, this one is pretty cryptic. A lot of people did not understand what I meant. Others stumbled into false logic and thought I was implying

Failure demand in software

A lot of people seem to like John Seddon’s concept of failure demand. Me too. But Seddon mostly talks about service delivery in areas such as call centers and housing repairs. I tend to work with software development organizations. When Seddon mentions IT, it is in the context of how the workflow systems we create end up reducing the quality of service delivery in call centers and housing repairs. After having used a number of different workflow systems over the years I too have come to the conclusion that most of them are counterproductive. But what about software development itself? Can the idea of failure demand be applied to software

Are estimates worthless?

If you take a picture while on vacation, is that picture yours? You are probably thinking: “What a stupid question. Of course it is mine!” But what if a stranger had asked you to take a picture of her with her camera? Is the picture still yours?

The second death of agile

The 10 year anniversary of the agile manifesto has just passed. As part of some kind of distributed retrospective, there has been a lot of discussion about what will happen with agile now. I think that agile will be dead in ten years – I just hope it will be a good death. This will actually be the second death of agile, but I need to set some other things in context before describing the first one.

Standardized work versus checklists

Atul Gawande has written a fascinating book called The Checklist Manifesto. The core message in this book is that many professions have advanced to an unprecedented level of sophistication and complexity. The main obstacle in getting optimal results is increasingly the practitioners ability to remember which things to do and when to do them. Atul proposes a simple but effective tool to alleviate this problem: checklists. The idea is of course not new, people have been writing checklists for ages. What makes the book interesting is Atul’s journey through a number of professions in search of insights into how to create useful checklists. The difference between a good checklist and

Three perspectives on better software

The agile perspective When the agile manifesto was published a decade ago I welcomed it. I had been building applications for a decade pretty much according to the principles in the manifesto. During this period I had watched in horror as RUP quickly became a de-facto standard. It was such a derailment of the agile ideas that had started to get momentum in the early nineties. For me the agile manifesto was primarily a wake-up call to developers to get them back to the roots of how you build software systems in an optimal way.