I love to use the user story format when I help teams plan their work. It can sometimes be hard to break user stories down into useable chunks, but their format is very easy to use: As a <type of user>, I want to <do what with the product>, so that <this value will come about>. There are different ways to format stories, but the essence remains the same. Use a simple format to quickly shake out some key information about a given requirement.
Maybe you’ve noticed that it’s not just during planning that we have hard time putting our thoughts and desires into words. Teams that do retrospectives frequently find that it can be very hard to get valuable output from these meetings. One cause of this, which is easy to remedy, is the use of inexact language.
If you’ve brainstormed improvement suggestions with your team, you might have seen a suggestion like this (written on a post-it note): “Better test”. Or maybe even terser: “Cooperation”.
These notes are a good start, because there’s an interesting story behind them. The problem is that we might have to spend considerable time pulling that story out. There is a simpler way to get there.
Nowadays, I use the story format not only in planning meetings, but also in retrospectives. Whenever I ask a team to brainstorm improvement suggestions, I ask them to do it using a template I supply. I ask them to write Improvement Stories.
An improvement story is quite easy to write, and looks like this:
Because <description of problem or situation>
we should <description of suggestion>
so that <description of desired result>.
I find that asking teams to supply their suggestions in this format results in contributions that are well considered, easy to understand and quick to process.
Have you tried using improvement stories? Drop me a note in the comments section!
På konferensen Agila Sverige 2009 gjorde jag ett blixttal på temat lättrörlighet och lärande, med titeln “Att lära sig tillsammans”. Konferensarrangörerna filmade alla tal, och mitt har nyligen blivit publicerat. Bäddar in det här nedan.
I spent the better part of last week at the Eurostar 2009 testing conference in Älvsjö, Sweden. I’ve never worked as a professional tester myself, but the topic of testing is gradually becoming more interesting now that more effective and humane approaches to testing are spreading widely.
My reason to go to the conference was to meet friends from AYE, to network and to scout the world of test. For almost seven years now, I’ve been using, teaching and introducing agile development with Scrum at all kinds of companies in Sweden, and while I’m no testing expert, I often meet testers who struggle with how to be of best value in their new cross-functional teams. I need to understand the realities of testing to be able to help my clients.
Before I got into consulting to project teams, I was a programmer. I remember one time when I tried to convince a contract tester at a client company to help us test the product we were developing. He was very hesitant, because he was a busy person. His services were in high demand, because he could find bugs everybody else missed. After some cajoling, he at least agreed to consider it, and said he might be able to help us if he found some spare time. He also added: – I will help you under one condition: I will execute no written test cases from you.
Turns out this sought after tester was actually a student working extra hours doing testing. Because he had no formal training in testing, he would exercise the product in many different ways, and apparently in many more ways than the employed testers would, since he found many more defects than they did. He used his intelligence and skill to test the product.
In the end, he never found the time to help my project, and we had to manage our own testing using a combination of automated unit tests and manual testing. While doing this, we found a possible bug in the software embedded in the hardware we interfaced with. We presented our theory to the responsible developer, who dismissed us by explaining that a bug in that code was impossible, because it had been tested and used for some time. Besides, wasn’t it quite unlikely that two Visual Basic programmers would find a bug in C++ software?
As luck would have it, a colleague from a previous project was still on site, and he was a true C++ ace, who I knew had learned how to avoid many of the vicious traps in that language. We asked him if he could help us, which he gladly did. Late one day, he checked out the code on his laptop to have a look at it. The next morning he came back and told us we had indeed found a defect, and he knew where it was. We asked him how he knew, since he couldn’t possibly have run the software from the comfort of his living room couch, where he told us he had found the bug. He told us he had simply read the code line by line until he found the defect.
With our C++ ally as backup, we went back to the programmer doing the embedded programming. Our ally simply proclaimed: – You have a bug, to which the embedded guy replied. – Oh, do we? Ok. They then worked together to fix it.
So what does all this have to do with agile? Well, agile is about being able to clearly understand our true progress, so that we can behave more effectively as we learn more about reality. Among many other things, this requires insight into the current status of the product under development. Testing can give us this information.
I’ve noticed that those who struggle most with testing in agile projects are those who either cannot see the need for testing, or who can’t let go of the traditional scripted way of testing software. They insist on doing no testing at all, or on creating detailed test scripts for manual execution, and this causes problems for them.
If you want to learn more about alternatives to scripted manual testing, you should check out the videos I’ve inlined below. The first one is an interview with “testing naturalist” (gotta love that) James Bach, the second is (a few years old but still excellent) Google Talk with Elisabeth Hendrickson.
På AYE-konferensen häromveckan nämnde jag i förbifarten för Jerry Weinberg att jag håller på att skriva en bok, och att jag kommit ganska långt med den, även om den är långt ifrån klar. Jag följer Jerrys råd att helt enkelt först skriva den bok jag själv vill skriva, för att sedan se om den är publicerbar. Skulle den aldrig komma ut har jag ändå lärt mig enormt i processen, och i dessa dagar är det ju heller inga problem att publicera den som en PDF på nätet som alternativ lösning.
Jag vet sedan tidigare att Jerry tycker att det är dags att marknadsföra sin nya bok långt långt innan den är redo för tryckning. Eftersom kongruens är ett nyckelord för honom agerade han i enlighet med vad han lär ut, och passade på att berätta om min kommande bok i en fullsatt workshop på konferensen. Det var lite överraskande förstås, men helt OK. Varför inte berätta om det? Eller vänta, jag har massor med anledningar (“någon knycker idén”, “den kanske aldrig kommer ut, och då får jag skämmas”, “man ska inte räkna pengarna innan smöret är sålt” och “jag som inte ens kan komma ihåg ordspråk rätt, hur ska jag kunna skriva en hel bok”). Men alla de anledningarna känns som svepskäl, så jag struntar i dem och skriver glatt vidare.
Vad boken ska handla om? Lättrörlig utveckling med Scrum, såklart, eftersom det är det jag ägnat mig åt i snart sju år. Det finns många andra böcker på temat, men jag tycker att det saknas en lättläst bok på svenska, som dessutom hittar rätt balans mellan teori och praktik.
Min bok ska ge praktisk handledning, men framför allt hjälpa dig som läsare att förstå varför ett visst sätt att bete sig kan vara mer effektivt som ett annat.
Jag vill hjälpa dig att komma vidare även när grundreglerna i Scrum visar sig svårare att leva upp till än du först trodde. Jag vill dessutom immunisera dig som läser boken mot metodövertro. Inget verktyg går att använda till allt, men det kan ändå vara användbart att lära sig det. Så även med Scrum.
Boken ska den vara lättläst också, nämnde jag det?
Vad vill du absolut ha med i en svensk lättläst bok om lättrörlig utveckling med Scrum? Du borde berätta om detta för mig i kommentarsfältet härnedan!
I’m currently cleaning up my trusty old Mac Mini G4. I’ve been cleaning out old stuff I don’t need to save, and a few days ago I installed a cheap 1 gig of memory. That upgrade did not make the machine notably faster. Today, however, I ran a bunch of maintenance tools, which seemed to do the trick. There’s a noticeable improvement in the speed of the little things, like how long it takes to fold out a menu. There was a delay before, and now it seems to be gone. Hope it lasts.
Energized by my success in speeding up the old can, I started another round of file cleaning. I found an old NeoOffice file called “Russ Ackoff – 95 Percent”. Because NeoOffice has always been extremely slow on this old machine, I wanted to see how fast I could open it. That, and the fact that I’m always interested in Ackoff’s teachings.
NeoOffice turned out to be as slow as before, but the file contained pure gold. Not new gold, but pure gold. In it was a little piece of knowledge that I’ve been using in my scrum master classes for a few years, ever since I came across it on the web.
Here are the contents of the file, which I remember transcribing from a sound file as I listened to it:
“http://www.open2.net/systems/practice/rus12.html
1900 – 95% of the people in the US could not do the job as well as their bosses could.
If the foreman retires from a group, you pick the best man to become the new foreman.
He can thus do the job better than any of his subordinates.
He will continue to rise as long as he is the best in the group.
All managers thus rise to the level of their own incompetence.
Today, 95% of the people can do their job better than their bosses.
You cannot manage them the same way.
Don’t manage what they do – manage the way they interact.
Requires different organization, and a different type of management.”
In his newsletter, David Schmaltz writes: “I’ve taken an article I previously published and reconfigured it into a format that seems to play into the shrinking attention spans and expanding information need. A Bed Time Story.”
David is here to remind us to trust ourselves, not just pre-packaged methods. Here is one of his efforts towards that goal. Enjoy, I myself really like it.
Out of all the conferences out there, the Amplifying Your Effectiveness conference is surely one of the most curious. Started in 2000 as a challenge (so he told me) from Jerry Weinberg (“so do you think you can do better”) to his protégés who were complaining about talking-heads conferences (“of course we can”), the AYE conference has been going strong for almost 10 years, and has garnered a loyal circle of attendees.
What stood out for me when I visited AYE for the first time in 2007, was how welcome I felt from day one. It was a stark contrast with a completely different gathering that I visited in Stockholm the year after. At the Stockholm gathering, I remember walking up to one of the hosts, and introducing myself. I explained that I worked for one of the companies sponsoring the conference. His reply was short: “Ok. Nice to meet you”. Then he turned around and walked away. I did not feel welcome.
Contrast this with the AYE approach. Before the conference begins proper, a pre-conference tutorial is arranged. Intended for first time visitors, this full day session not only works through the core topics of the conference, but also gives ample time for letting people get to know one another. The exercises used aren’t rocket science, which is probably why so many other conferences shun them – they seem almost silly. Participants show and tell their stories, and listen carefully to each other. It works wonders for relationships.
When the desert sun (AYE is held in Phoenix, Arizona) finally sets on the tutorial day, the conference is kicked off with a big outdoors welcoming dinner. A simple thing too, but very effective. People are seated around round tables of course, so you can really see each other.
Another seemingly minor detail stands out for me. AYE participants all create their own name tags, and carry them around their neck using a green strap. This means that, as you walk around the large hotel, which is flat rather than high, you constantly say hello to other participants (even those you don’t yet know very well) wearing the signature AYE neck strap.
If you haven’t tried it already, and you’re interested in the topics covered (teamwork, communication skills, leadership, change) give the AYE conference a chance next year. I’m sure I’ll be there again. And if you think this reads like a commercial, then so be it. Some things are just so good I feel I absolutely have to help sell them.
Babbitt’s blog post talks about how focusing on cost reductions often increases costs. One reason is that cost reductions are often approached by centralizing services in organizations. When this happens, a feedback loop is broken. Those who produce the services are no longer those who consume them. This means that they loose their understanding of how well the services work. When the consumer of the service sees the service degrade, they cannot easily improve the service, because they don’t control the production of it. Instead, the consumers work with what they can control, which sometimes means reproducing the service locally, thus increasing total costs.
How can we use this insight to improve software development?
In software development, we sometimes see this phenomenon with centralized platform teams. A platform team is formed to develop shared functionality, to be used by teams that develop actual product features. In reality however, platform teams often have a hard time living up to the expectations of the feature teams. Because of this, feature teams sometimes choose to locally develop functionality that was supposed to go in the shared platform.
Another example that comes to mind is when organizations set up project management offices, and these offices proceed by pushing out standardized methods of work, instead of listening to the needs of the different areas of the corporation. Again, the idea here is to save money by standardizing, but the result is often frustration, because there is no such thing as a one-size-fits-all way to manage projects.
One final example: the central database administration group. Created to gain control over database services, it soon becomes the bottleneck more than anything else, stopping projects dead in their tracks.
In Ackoff’s solution, departments within organizations should be free to procure the services they need from internal services and from anyone on the open market. If top management wants to override a department’s decision to procure externally they can do so, but will have to use their own budget to compensate for the losses the buying department suffers through this decision.
In other words, if a sales department is forced to procure their new IT support system from the internal IT department, even though they could have gotten the same solution for a cheaper price from an external provider, the overriding manager will have to compensate the sales department for the difference in cost.
Well, this is really a bit outside of my area of expertise, but interesting nonetheless. My learning goes on.
What are your experiences of centralized services? Good? Bad? Why?