It’s always nice to look at real data and these two studies are worth their read.
Wow, it’s been a crazy period. Sydney, Trondheim, Oslo, 10 talks in 2 weeks! Didn’t really plan to do that much, but one thing led to another. Fun, but exhausting! 4 internal talks at several large banks in Sydney Keynote at Scrum Australia, Sydney. Topic: “Scaling agile @ Spotify” (slides) Keynote at Trondheim Developer Conference.
Continue reading
Här är mina slides om Agila kontrakt från Devlin 2014. Jag hoppas det skall inspirera fler företag och myndigheter att börja använda sig av dem, då de medför väsentligt lägre risk än traditionella kontrakt. (Använder du Agila kontrakt idag – tveka inte att höra av dig!) Vi har i Sverige dåliga practicies för upphandlingar och
Continue reading
If you are working on an agile project, it is almost certain that you are using Stories to describe your backlog of work. It is another near-certainty that if you are using Stories, you write them down using this format:
“As a <user or stakeholder type>
I want <some software feature>
So that <some business value>”
As someone who cares about the state of agile practice, I want to offer some alternatives, so that agile teams remember that the point of the story is in the telling, not the template. The shared understanding comes from the conversation, not the card. By offering you different ways to ‘tell’ the story in its short written form, I hope you will be able to re-ignite a greater level of meaning, interest and engagement in your team’s discussions about the work they are doing to build great software that matters to people.
Crisp’s Youtube channel has made a new release – introducing Concepts. Concepts is used to let passionate people run with ideas, a different approach than that of traditional product ownership. If you do use in conjunction with a product owner, it allows that person to spend more time on the field with customers. Ps: The
Continue reading
Here are the slides from my tech talk Agile @ Scale at Sony Mobile. Full house & very high level of engagement, I was impressed by this crowd! And thanks for the awesome recommendation on LinkedIn 🙂 Some sample pics below:
Continue reading
(this post will be in Swedish since it is a response to Swedish legislation describing how to sell and buy software. If you still are interested, Google Translate is your best friend 🙂
LOU – Lagen om offentlig upphandling är fröet till många katastrofer för statliga och kommunala mjukvaruprojekt. Tänkt som ett verktyg för att hushålla väl med statliga medel, genom att konkurrensutsätta erbjudanden bidrar LOU tyvärr till att skapa dåliga förutsättningar för att lyckas med mjukvara.
Det knasiga med LOU är de felaktiga incitamenten: Om vi antar att de funktioner som är användbara är relativt okända i ett tidigt stadium av projektet så är default practice vid användandet av LOU att funktionerna skall specas i början och sedan skall billigast leverantör väljas. Det vanligaste sättet att jämföra leverantörer är att skapa en lång lista av den sammanlagda funktionaliten i deras produkter och sedan låta dem bjuda på minsta kostnad. Inte oväntat kommer vinnande leverantör efter kontraktet’s inskrivande att snabbt flytta på senior kompetens ur projektet till fördel för junior och vips befinner både kunden och leverantören i en långsam dödsdans där kundens användare blir förlorarna.
LOU innehåller dock ett antal möjligheter som du som upphandlare kan nyttja smart.
When is a so-called requirement really required? And is it the “right” requirement? The answers depend on many facets: stakeholders, value, planning horizon, and so on. This article explores using options as a means to identify high-value requirements, at the last responsible moment.
Product requirements are needs that must be satisfied to achieve a goal, solve a problem, or take advantage of an opportunity. The word “requirement” literally means something that is absolutely, positively, without question, necessary. Product requirements must be defined in sufficient detail for planning and development. But before going to that effort and expense, are you sure they are not only must-haves but also the right and relevant requirements?
Continue reading
Here are the slides for my talk What is an agile tester from the Colombo Agile Conference in Sri Lanka.
Here are the slides for my keynote How do you know that your product works, from the Colombo Agile Conference in Sri Lanka.
Just back from Mix IT in Lyon. A bit rare to visit a French conference so was cool to meet people from the French community and see what they are up to. Some reflections: Saw a cool presentation on Prioritizing portfolios using Cost of Delay by Özlem Yüce. No doubt mr Don had an idea
Continue reading
One of the most common questions we get is whether to estimate in time or points. It seems like points are used only “to avoid thinking about time” and they are essentially the same. Wrong.
Let us give you the travel metaphor to give you an idea about how we are thinking.
This years Lean Kanban Nordic conference will be something extra. The focus in on improving the full value chain, from concept to cash. You will get an unique opportunities to listen and discuss with practitioners sharing their experience of how they have improved their companies using Lean thinking. For example, learn:
The use of traditional contracts when purchasing software carry a flawed assumption – thinking the contract is the right mean to regulate risk.
The insight is key risks are : skill of the provider, the maturity of the client (yes you!) and ability to communicate honestly during the project. Few of these are effectively regulated using traditional contracts focusing on features, time and money.
Which are the key risks when purchasing software?
Grunden i traditionell User Experience (UX, användarens upplevelse av en produkt) består av iterativa användarstudier och interaktionsdesign under krav- och designfaserna, för att säkerställa att produkten kommer att uppfylla användarnas behov och ha god användbarhet. Vi ser till att ta reda på vad vi ska bygga innan vi börjar bygga det. Det finns två huvudsakliga problem med det här (som båda beror på vattenfallsmetodikens inbyggda brister). Dels överlämnas resultatet av arbetet i krav- och designfaserna till utvecklarna i stora och svårförståeliga dokument, ofta bestående av flödesscheman och annoterade wireframes som inte speglar den tekniska verkligheten. Detta rent felaktiga sätt att bygga en produkt leder ofta till att man i slutändan bygger fel produkt. Dels sker oftast leveransen av produkten till slutanvändarna långt senare än det var tänkt och då har marknadsläget vanligtvis ändrats, vilket också innebär att fel produkt levereras.
Agila metoder löser problemet med att leverera produkten snabbt nog. Lean Startup (innovationsdriven produktutveckling) löser problemet med att marknadsläget ändras genom att fokusera på affärsmålen genom hela utvecklingscykeln. Inget av dessa paradigm är dock användarcentrerade. För att möta detta problem har två tankesätt utkristalliserats:
“Rörelse trumfar stillasittande” är den första och viktigaste av de sex principerna för lärande från Sharon Bowmans bok “Using Brain Science to Make Training Stick”. Att bli certifierad Training From the back of the Room lärare var en resa med många steg och moment. En av uppgifterna bestod av att göra en presentation. Jag valde
Continue reading
Already convinced? Sign up for ToDo by Projectplace! Want to know more? Read on.
I juni kommer min kollega Jimmy Janlén och jag hålla kurs i deltagardrivet och upplevelsebaserat lärande. Vill vi hjälpa andra att upptäcka och praktisera sätt att skapa sant engagerande och lärande undervisning, presentationer och workshops. Kanske slipper ni då mina egen långa resa bort från katedern.
Så vitt jag minns det var jag 24, kanske 25 år. Jag och min vän Göran hade blivit inbjudna att hålla föredrag inför en större samling människor. Det hade jag aldrig gjort förut. Visst var jag van att prata inför andra människor, från seminarierna på universitetet till redaktionsmötena på vår lilla tidsskrift, men inte att hålla tal. Jag gjorde det som kändes säkrast. Jag skrev ett tal och läste sedan upp det.
Förutom att det tog jättelång tid att skriva talet, så kändes det inte bra att stå där och läsa rakt upp och ner. Visst försökte jag läsa med inlevelse och dramatik, ungefär som när man läser högt för barnen, men det kändes ändå inte bra. Höll inte åhörarna på att somna? Lärde de sig alls något? Det går att trollbinda en publik med högläsning, om man berättar en riktigt bra historia. Göran var bra på det, men inte jag. Något behövde jag göra annorlunda.
Role Expectation Mapping is a series of workshop that explores, clarifies and establishes which expectations members of a group, team or project have on each other.
If you suspect that collaboration is undermined because of mismatch of expectations between people, then this exercise could boost the team’s ability to collaborate efficiently together. It is also a powerful way to jump start a new team and give them a structure to relate to.
People always have certain expectations on each other, behaviors, responsibilities, etc., but if those aren’t made clear and agreed upon among everyone – you are bound to have unconstructive conflicts, colliding agendas, difficulties in collaboration and things that fall between chairs.
In this episode of our YouTube channel Crisp Agile Academy I talk about Sprint Burndowns. I discuss the value of having one and that it is a tool for the team, not anyone else. I also give examples of different kind of burndowns: Remaining Hours, Remaining Story Points, Remaining Tasks, Things in progress, and Confidence level. I wrap up the episode with a little quiz.
http://www.youtube.com/watch?v=qoMZoppaf0U
Igår hade jag äran att få gästa SAST Stockholm Q4, där jag fick hålla en presentation om utvecklartestning. Med handen på hjärtat, så blev det lite mycket information på få tidsenheter ibland. Dock brinner jag verkligen för ämnet och vill säga så mycket jag kan. Efter att ha checkat runt lite, gläds jag åt att
Continue reading 
In september I had the great pleasure of speaking at the http://agileprague.com/ conference. It was the second time I attended and I was equally pleased with the event this year. Last time I just attended while my wife gave a talk, but this year I decided to share my thoughts on Test Driven Development. The talk was
Continue reading
Viaplay broadcasts TV over the web and to wireless devices. No need to wait for another build.. they have the worlds fastest CI! Let me share with you how it works! 1. State normal – everything works We can code along or have another coffee. 2. Big trouble! Mainline is clearly broken! All hands on
Continue reading
Återigen har ni diskussionen om “working software over comprehensive documentation” verkligen betyder att man inte behöver dokumentera någonting alls. Eller diskussionen om det är ok att förlänga sprinten med några dagar för att hinna klart den sista fixen på den där storyn. Eller diskussionen om vad det egentligen innebär att vara “lean”. Känner du igen dig? Kan det vara så att alla har nytta av att ha samma grundförståelse av centrala begrepp i och runt “agile”? Läs vidare för ett enkelt sätt att skaffa den kunskapen!Continue reading
Met a great crowd in Kiev at Agile Eastern Europe. I’d love to stay longer! Here are the slides on my presentation on Visualization – what’s my brain got to do with it.
Continue reading
Here comes a new post from Ellen Gottesdiener who comes to Stockholm to hold her highly appreciated course Agile Requirements Analysis and Planning for Product Success.
In a recent interview in the New York Times, Panera Bread co-CEO Ronald M. Shaich talks about the importance of developing an organization’s “discovery muscle” as well as its “delivery muscle.” Most companies have worked hard to perfect delivery—how they get work done—he says, because delivery “feels rational, people feel much safer with it, and you can analyze it.” But discovery—the activities you undertake to define or change your product, service, or market—is about “leaps of faith. It’s about trusting yourself. It’s about innovation.” The key, Shaich says, is for the discovery muscle to be at least as strong as the delivery muscle.
He took the words right out of our mouths. This need for balance between discovery and delivery applies in spades to software development. Our new book, Discover to Deliver: Agile Product Planning and Analysis, explicitly makes the case for equally balancing your commitment to these key activities. We define the relationship between them: In lean/agile software development, discovery and delivery are interwoven, interdependent, continuous activities (see figure 1). Each feeds the other.
MongoDB är en schemalös, dokumentorienterad databas som har fått stor popularitet i den agila världen bland annat därför att man inte behöver underhålla något databasschema.
MongoDBs schemalöshet gör att många leds att tro att Continuous Delivery blir en promenad i parken, eftersom det ju inte behövs några datamigreringar när man driftsätter en ny version av koden!
Rent teoretiskt är detta sant, men är ett sluttande plan in i Land of Crappy Code™ !
För att slippa onödig komplexitet i form av varierande utseende på lagrade domänobjekt beroende på deras ålder, rekommenderar jag att man utför regelrätta datamigreringar även när man använder MongoDB!
Jag rekommenderar även att datamigreringen är en del av applikationen — till skillnad från skript som skall köras vid sidan av innan applikationsstart — helt enkelt för att eliminera risken för misstag.
Jag har i mitt sidoprojekt Varmfront.nu utvecklat en kompakt liten lösning som i MongoDB implementerar det som Flyway gör för SQL.
Mönstret bygger på Spring Data for MongoDB och Spring JavaConfig, och migreringarna är skrivna i Java. That’s right folks, no XML here 😀
Läs vidare, så får du se hur man kan göra!
Ellen Gottesdiener is an internationally recognized leader in the collaborative space where agile requirements + product + project management converge. She coaches, trains, and presents to thousands of people globally and has facilitated hundreds of discovery and planning workshops across diverse industries.
She will hold her popular workshop in Stockholm 25-27 September 2013.
In agile development, what happens to the traditional business analyst? Consider Scrum, currently the most popular agile method. In Scrum, there is no “business analyst” role. In fact, there is not an explicit role for tester, project manager, architect, developer, data administrator, user experience designer, customer support representative, or product trainer. Instead, Scrum has three roles: the product owner, the Scrum Master, and the delivery team. Their collective goal is to deliver high‐valued product needs continually. So, where and how can a business analyst contribute?
Improvement Theme is a tool in the form of a poster that works as a conveyor belt for continuous improvements once the Retrospective is over.
I’ve been reading a little bit about Toyota Kata and seen great presentations on the concept. In order to make it practical and useful for me I found myself tweaking it and packaging it in a concept I’ve come to call Improvement Theme. I’ve tried this concept a couple of times now and found it to be a good tool to extend improvements beyond the Retrospective and bringing it into the daily work. In this article I describe how to create the poster and how to use it as a tool for continuous improvements.
The Improvement Theme is a poster. I’ve been using magic charts since they are easily moved between the room in which the retrospective is held and the teams wall.
The charter consists of five areas.
1. Name of the Improvement Theme
2. Now/Problem – Description of the current situation
3. Definition of Awesome – How would we like it to be?
4. Next Target Condition – X weeks from now, what has changed?
5. First Steps – 3 slots for three post-its that describe the first (next) actions we will take?
It’s a living document, preferable put up next to the scrum/kanban wall. Once or twice a week the team reviews the theme and agrees upon new actions as they get completed.
When X weeks has passed the team does a review of the theme itself. If they want to continue on the same theme they identify a new “Next target condition”. Otherwise they create a new Improvement Theme poster.
Here follows an extensive description of how I’ve been using the concept as a tool for improvement and a more in-depth description of the different aspects of the poster.