Full stack management consultant.
Planning is great. Too bad it’s so hard. Too bad it so often results in weird plans and deadlines that jump around in the calendar like drunken fleas.
Here’s an idea (yet untried by me) for a counter-measure: The Visible Planning Calendar. Goal: to make planning more transparent by at least making dates somewhat less jumpy. Contents: an agile, or at least iterative, development methodology, plus some extra rhytm to it.
Just an idea. Inspired by others. Credit given in pdf above.
Tjabbigt att behöva återkalla 987 000 bilar när man byggt så mycket av sitt varumärke på att vara kvalitetsmärket nummer ett. Ingen är felfri.
Uppsala Nya Tidning rapporterar om 240 miljoner skattekronor som har östs in i ett system som är så dåligt att användarna väljer att sjukskriva sig.
Det som är mest fascinerande när det skrivs om den här typen av fiaskon är att man kan ana viss förvåning över slutresultatet. Själv blir jag inte längre förvånad, mest förbannad över att man aldrig lär sig. Framför allt är det beklämmande att läsa om de åtgärder man hoppas ska lösa situationen: “Bland åtgärderna nämns bland annat en riskanalys samt handlingsplan för utbildning, anpassad introduktionstid, så kallade lathundar och utökad support”.
Jag skulle vilja delta på en utbildning där någon från leverantören förklarar varför det krävs 24 musklick för att registrera en vaccination. Och ännu bättre: tänk att få se lathunden för samma process.
I’ve written a short piece on the importance of learning to use your senses to gather information. It’s published on the scrumalliance.org site.
Efficiency in an iterative mode of working requires that we have little overhead in all our processes. For example, if building a release candidate takes us several days of manual work, we will have a hard time working in two week iterations, since so much of the iteration will be consumed by release work. Add to this slowness in detailing specifications and test cases, and we’ll get even less product created in the iteration. Then add cumbersome and manual design/coding (developers have not yet learned how to utilize whiteboards to visualize holistically, and refactoring tools to fluidly change the source code), and we start to understand why so many development organizations have a hard time adopting iterative modes of development.
What to do? Well, for starters, maybe we can try to look at our organization and how we work, and see where the time goes. Create an overhead scorecard, a simple table outlining how long activities take. Or try the value stream mapping technique, in an attempt to really nail down how you spend your development time.
Then, attack your worst bottleneck. And, no, you do not have to be an expert in theory of constraints or some other thinking technique. Just scrutinize your own behaviour, and do something about the things that look bad. The need for this way of approaching challenges is, paradoxically, becoming greater and greater in the software industry as ideas about new ways of working spread. I see lots of people interested in learning about things like Scrum, lean, theory of constraints (of which I know very little myself), test-driven development and so on, but when it comes to going home to your back yard and do some cleaning up, many fail.
So: try approving a bit, pluck some low-hanging fruit (there’s typically lots of it). When you start to see the limits of this simple approach, go ahead and learn about advanced techniques. There’s lot to learn out there, but you don’t have to know it all to be able to improve.
Idag hittade jag äntligen en skön editor för Mac OS X som både är gratis och har den rätta Mac-känslan: Smultron.
Tidigare har jag kört en utvärderingsversion av Rails-folkets favorit TextMate, men den gick ut idag. Har också prövat TextWrangler, en gratisvariant av den gamla Mac-trotjänaren BBEDit, men känslan är helt enkelt inte helt rätt. Detta problem gäller inte för Smultron. Efter ett par timmars användning känns allt bara bra. TextMate har fler roliga finesser, men Smultron räcker långt för mig just nu. Pröva!
Uppdatering: till slut har jag fastnat för en version av Vim för Mac OS X. Fullständigt omöjligt att ens komma igång med utan en bra guide, vilket jag sån tur var hittade, men väldigt kraftfullt när man väl ägnat några dagar åt att förstå hur det är tänkt att funka.
Uppdatering igen: självklart är det TextMate man ska köra på Macen. Jag hade faktiskt prövat denna editor som är en favorit bland rails-utvecklare, men inte riktigt fastnat för den. Nu har jag testat igen, och lagt mer tid på mig att utforska alla finesser. Slutsats: oslagbart! Pröva själv.
Uppdatering, 2011-01-03: Läste häromdagen om ett open source-projekt som kan bli intressant. Kolla in editorn Kod, på kodapp.com.
Donald Reinertsen är konsult och författare till “Developing Products in Half the Time” och “Managing the Design Factory”. Hans approach är särskilt uppfriskande i dessa tider, när metod ställs mot metod. Lättrörligt mot traditionellt. Istället för att ge sig in i såna strider föredrar Reinertsen att utforska hur olika faktorer faktiskt påverkar varandra. Han går tillbaks till ekonomin, och visar till exempel hur kostnaden för en försening kan ställas mot värdet av en ny feature.
Den 3 maj kommer Reinertsen till Sverige i regi av IVF Industriforskning och utveckling.
Den 25:e till 26:e april kommer jag och min kollega Mikael att hålla en Scrum-workshop i Uppsala, i Citerus regi. Fullgjord workshop innebär att deltagaren kan titulera sig “Certifierad Scrum Master”. Det blir två interaktiva och roliga dagar på temat lättrörlig projektledning.
Elektroniktidningen har ett scoop: agile är en finsk metodik.
…Noel Llopis, who writes about what it’s like to work in an efficient and agile manner at High Moon Studios.