Tobias Fors

Category: Agile

  • Code as Design

    When I first read it a number of years ago, I immediately found Jack Reeves’ article “What Is Software Design?” useful, intelligent and correct.

    In the article, Reeves presents his arguments for why the source code is the artefact that constitutes the ultimate design of software. Apparently, this article resurfaced with the publishing of Robert C Martin’s book on Agile Software Development, after having led a quiet life in hibernation since its first publication in 1992. It is now often referenced in the agile community.

    Why is this important? It is because our perception of what source code is influences our perception of what programming is. If the source code is the design, then programming is designing. If programming is designing, it becomes natural not to accept the opinion that programming should be like factory work. Of course, people who insist that other people’s work should be more factory-like will continue to insist on this until the end of time, but at least knowing there’s a solid argument saying that they’re wrong makes you feel good.

    Sadly, outside the circle of agile aficionados, few attitudes seems to have changed. When I talk to people from mainstream organizations that live far from the current agile trends, the word “design” is still associated with the creation of UML diagrams, and the task of “design” is sometimes thought best performed by seasoned specialists. This of course, will be followed by mechanical implementation of said design by monkeys with keyboards.

    This is truly a sad example of how easily we settle into inefficient and creativity-strangling stovepipes. A programmer without the mandate to design will either have to fail or break the rules. Luckily, many choose to break the rules, but this has the side effect of creating completely unneeded psychological stress. We all deserve to be able to do our best without having to bend stupid rules. Wouldn’t that be a great world to live in?

    If you have not already read the article, do so now.

  • CIO Sweden manglar beskrivningen av Scrum, men vinner en gratis kursplats

    Intresset för lättrörlig utveckling i allmänhet och Scrum i synnerhet är enormt just nu. Många av de företag vi jobbar med börjar uppnå avsevärd förståelse för och framgång med arbetssättet. I denna situation är det lätt att få för sig att även resten av världen förstått vad det handlar om. Men, vi är inte riktigt där än.

    I artikeln “Projektledarskolan: ABC för ledning av IT-projekt” presenterar IDG-publikationen CIO Sweden en illa tilltygad beskrivning av Scrum.

    Så här beskrivs Scrum, vilket gav upphov till en hel del munter/arrogant mailcirkulation på Citerus:

    “Den tredje metoden för IT-projektledning kallas Scrum. Den har fått sitt namn från ett rugbylag och använder också olika steg som planering, kodning, genomförande och test av programvara. Scrum har en egen terminologi och fasta regler kring möten, delmål och hur länge olika planeringsfaser ska vara.”

    När jag först läste artikeln reagerade jag inte bara på påståenden likt detta, utan också på det märkliga språket.

    Författaren har ett anglosaxiskt namn – Joseph Philips – vilket gav ledtråden att artikeln är en översättning. Lite sökning på den engelska upplagans sajt visade att så är fallet. Här upptäcker man också att inte all skuld ska läggas på artikelförfattaren. När det gäller Scrumcitatet ovan är det istället den svenska översättaren som är ute och cyklar. Så här lyder nämligen originaltexten:

    “Scrum is the final leader in IT project management. This approach, named after a rugby term, also uses iterations of planning, coding, executing and testing software. Scrum employs its own vernacular and has some rigid rules about meetings, hitting milestones and the duration of planning activities.”

    I den svenska översättningen händer alltså ett antal intressanta saker:

    • Scrum slutar vara en av de ledande metoderna
    • En “rugbyterm” blir ett “rugbylag”
    • Omnämnandet av iterationer försvinner helt, vilket väl får ses som olyckligt när man pratar om en metod som helt bygger på att använda anpassning och granskning för att undkomma de problem traditionell projektstyrning visat sig inkapabel att hantera
    • “Duration of planning activities” blir “hur länge olika planeringsfaser ska vara”, vilket slutligen bevisar att översättaren vet väldigt lite om Scrum och lättrörliga metoder. Planeringsarbete i Scrum görs ju kontinuerligt, i början av varje 30-dagarsiteration (eller sprint som vi scrumnördar säger), och är begränsat till max 4 timmars övergripande urval av produktkrav som ska implementeras, plus max 4 timmars detaljplanering av hur arbetet i sprinten ska gå till). Så långt ifrån en traditionell “planeringsfas” man kan komma alltså.

    Jag brinner för att sprida en bättre förståelse för den typ av radikalt nytänkade inom projektvärlden som Scrum representerar, och utsträcker därför ett erbjudande till tidningen CIO: i Citerus namn tar jag mig friheten att bjuda på en gratis kursplats för en av era medarbetare – men ligg på – våra kurser blir snabbt fullbokade!

  • Kopplingen lean och Scrum

    Scrum är en praktiskt orienterad grundstomme för hur man kan bedriva lättrörlig mjukvaruutveckling. Lean är en etikett satt på det system av principer som man uppfattat legat till grund för bland annat Toyotas sätt att organisera sig.

    Hur förhåller sig egentligen Scrum och lean till varandra? Att förstå detta är användbart både för den som vill ha en teoretisk grund för att förstå eller argumenta för Scrum, och för den som idag använder Scrum, men som vill förstå hur man kan justera och vidareutveckla arbetssättet utan att göra supoptimala justeringar.

    Ett sätt att se på förhållandet är detta: scrum är en implementation av lean.

    Vad innebär detta? Det innebär att Scrum i praktiken är utformat så, att arbetssättet stödjer de principer som lean baseras på. Scrum är alltså en tolkning av leanprinciperna, som den hågade kan utgå ifrån för att komma igång med en effektivisering av sitt sätt att utveckla mjukvara.

    Jag och Mikael Lundgren höll för rätt länge sedan en dragning på detta tema i Dataföreningens regi (PDF). Då var intresset ganska litet, men jag misstänker att vi får tillfälle att återkomma till denna koppling, nu när intresset för både Scrum och lean ökar. Ju fler intresserade, ju fler som funderar över detta.

    Här är en snabb sammanfattning av några kopplingar mellan Scrums handfasta riktlinjer, och leans teoretiska principer.

    Lean-princip: Eliminera slöseri
    Scrums implementation av principen:

    • detaljplanera i aktiviteter endast en iteration framåt (eftersom detaljplaner snabbt blir inaktuella och måste göras om),
    • ha ett enkelt, “tillräckligt bra”, system för tidsestimat och statusrapportering – fokusera på åstadkomna resultat, inte på tidrapportering,
    • se till att teamet har arbetsro under iterationen.

    Lean-princip: Ständigt lärande
    Scrums implementation:

    • teamet tar själva ansvar för kravförståelse och utformning av den mest optimala lösningen på givna problem,
    • daglig uppföljning i hela teamet och tydlig statusrapportering utåt till intressenterna,
    • återblickar i slutet av varje iteration – kombinerat med planering av förbättringsåtgärder

    Lean-princip: Ta beslut sent (så sent att du har maximal information, men inte så sent att skada hinner ske)
    Scrums implementation:

    • rullande produktplanering,
    • detaljplanering just-in-time i början av varje iteration,
    • se till att så många beslut som möjligt är lätta att ändra – använd disciplinerad refactoring för att ständigt förbättra produktens design och därmed göra den lätt att ändra

    Lean-princip: Leverera snabbt
    Scrums implementation:

    • fokus på tidig releaseförmåga, varje iteration slutar i en intgrerad produkt av hög kvalitet,
    • implementation i nyttoordning ger möjlighet till tidig leverans,
    • minimal administrativ overhead – en dags gemensam planering första dagen i iterationen och en dags gemensam uppföljning sista dagen i iterationen,
    • effektiv utveckling tack vare fokuset på att bygga upp ett självorganiserande team,
    • möjliggör snabba buggfixar med hjälp av automatiserad testning och integration

    Lean-princip: Bygg in kvalitet (istället för att försöka “testa in” den i slutet)
    Scrums implementation:

    • skapa ett team som förstår kundens definition på kvalitet genom att jobba nära kunden och kundens problem,
    • använd ett tvärfunktionellt team för snabb och effektiv problemlösning,
    • varje iteration slutar med “färdig produkt”/”done product backlog”,
    • använd automatiserade tester,
    • utnyttja “peer programming” – alltså att teammedlemmar från olika discipliner (testare, programmerare etc) angriper problem gemensamt,
    • etablera ett gemensamt klarkriterium – alla i teamet och beställaren ska vara överens om vad det innebär att säga att en given produktfunktion är “klar”

    Lean-princip: Decentralisera ansvar
    Scrums implementation:

    • små tvärfunktionella team med långtgående befogenheter och tydliga ramar,
    • aktivitetsplanering för varje iteration görs av teamet själva under varsam handledning av “ScrumMastern”,
    • det dagliga arbetet planeras, genomförs och följs upp av teammedlemmarna själva

    Lean-princip: Se till helheten
    Scrums implementation:

    • använd tvärfunktionella team för att garantera lösningar på hela problem och undvika suboptimering,
    • utveckla vertikalt – implementera per funktion “från skärm till databas” aldrig “ett skikt i taget”,
    • etablera ett resultattänkande – teamet följs upp på hur väl det implementerar en värdefull produkt snarare än på hur bra det är på att fylla i tidrapporter och annan administratrivia,
    • fokus på affärsnyttan – det är viktigare att bygga den produkt kunden vill ha när projektet är slut än att bygga den produkt kunden bad om när projektet började

     

  • Mike Cohn on Agile Estimation

    Author, consultant and speaker Mike Cohn has a two–part video out on YouTube. In it, he talks about his area of expertise – the planning and estimation of agile projects.

    Mike will be visiting Sweden this fall, and do a couple of his popular courses, hosted by Citerus. Don’t miss out on this opportunity to learn about Mike’s accessible methods of planning agile projects – they will be an excellent addition to your toolbox.

  • Adobe Goes Agile, Makes Life Easier

    In the article “Adobe edits the development cycle” on Regdeveloper, Mary Branscombe lets Adobe tell the story of how they switched to a more agile, incremental, development cycle. The result, according to Russell Williams of Adobe: “Better quality, plenty of features, fewer nights and weekends: what’s not to like?”

    Note especially the focus on developing by feature and how the maintenance of excellent engineering practices makes this possible. “The goal is to always have the product in a state where we could say ‘pencils down. You have x weeks to fix the remaining bugs and ship it’”, says Williams.

    Thanks to Jörgen Falk for the tip.

  • More Poppendieck on Lean

    Here’s a new interview with Tom and Mary Poppendieck on the topic of lean software development. Thanks to Rickard Johansson for the tip!

    Around 25 minutes into the interview, the topic of RUP appears. Tom points out the amount of knowledge available in the RUP, but also how it has often been implemented with a focus on the specific practices, rather than on the principles that lie behind the RUP: iterative, incremental software development.

    This problem is not entirely unexpected, since people who need the guidance provided by the RUP manuals are probably not yet at a skill level where they can work from principles. When learning something new, we need rules and practices. Unfortunately, in projects and management, the same rules and practices will not work for everyone. A skilled practitioner knows this, and works from the principles he believes in to deduce practices that are useful in the current context. When people “implement” the RUP by copying practices without knowing why, problems are likely.

    At around 36 minutes, Mary discusses the difficulty of applying lean and agile over company borders. This is an interesting question, but one that needs some care. Any project run over company borders is challenging. Lean and agile have the nasty and necessary habit of talking openly about uncertainties and risk, and recommending transparency. Obviously, this will put a strain on any relationship between parties who are used to contracting defensively with each other.

  • Ron Jeffries on Running Tested Features

    In this video on InfoQ, Ron Jeffries talk about agile software development. What is worth pointing out is how he emphasises the similarities between the different agile methods. One difference between how Ron explains things, and how Ken Schwaber does it, though, lies in the graphing of the growth of features. When Ken draws the line, it starts out growing slowly, indicating more focus on “architecture” early on (but still producing features every sprint). When Ron draws the line, it is more linear, indicating his desire to have a more constant growth of features with a really evolutionary approach to “architecture”.

  • The Power of Closure

    I have a new short article up on the Scrum Alliance site, where I look at Scrum from the perspective of closure. Don’t miss this weekly column, where good little articles pop up every now and then. Last week’s was by Ken Schwaber on the topic of sprint reviews.

  • Workshop: Testdriven utveckling och refaktorering

    Magnus Ljadas på Citerus håller snart en tvådagarsworkshop på temat testdriven utveckling och refaktorering. Missa inte detta tillfälle att förstärka din förmåga att hantera dessa kraftfulla verktyg!

  • Requirements: Still Need to Handle Them, Post-Agile

    Many problems we’ve traditionally had with understanding, communicating and implementing solutions for user’s needs are reduced or go away as agile development lets us shift our focus from requirements documents to frequent conversations about actual, current, needs.

    Still, these things in no way mean that we should stop thinking about requirements, even written ones. We’ll still be facing them even when the terminology and the means of handling them change. And context is key, as always: if you must have very formal written documents, if you really must, well, then you must.

    With no further ado, here are some books (see: it’s not a bad idea to write things down from time to time) that have helped me understand this aspect of communication in our projects.

    • To begin with, we need to understand that at the core of the challenge of understanding user’s needs lies a deeper challenge: that of knowing what the problem really is. This is what Gerald Weinberg and Donald Gause explore in their entertaining little book Are Your Lights On?, a true must-read in this context.
    • Next up, something completely different. Or not. While expressions like “requirements gathering” may have some believe that requirements are like pretty little flowers waiting around to be picked and catalogued by a jolly gatherer, this act of finding user needs is not seldom pretty challenging: we’re talking about facing and synthezing a multitude of opinions from a bunch of stakeholders, after all. So, we should be able to talk about potentially contentious issues in a productive way. In come the authors of Crucial Conversations, with their collection of principles for helping yourself keep even your challenging interactions with others sane.
    • On a possibly less far-fetched side, Mike Cohn’s book on User Stories describes a middle ground between the often bloated use case format and the context-disabled IEEE-style “the system shall” requirements. Simple and usable, but beware: XP-people will sometimes angrily remind you that they, not Mike, invented user stories.
    • In software projects, we have a long and sad history of estimating the cost of requirements, but not the value of them. Donald Reinertsen takes us one step beyond the (powerful and typically sufficient) product backlogs and teaches us how to bring back value to the table. See: Managing the Design Factory.
    • I think I liked this next one too, even though a few years have passed since I last read. Since its Gerald Weinberg again, I’m not worried about recommending it: Exploring Requirements: Quality Before Design, by Mr Weinberg and Donald Gause.