Posts Tagged ‘agile’

Black Cards – agile handling of technical debt

September 27, 2017

The deadline is looming. Your team is struggling. To ship we take shortcuts that don’t sit well, but necessary. We release, but with a bad feeling. After a while, our effectiveness goes down due to the hidden technical debt. Here’s a way to show and thus be able to follow up and fix these pain-points.

We’ve all been there at crunch-time. Everyone is giving their utmost to ship and take whatever shortcuts that will meet the deadline. All goes “well” and you get something out through the door, albeit with a long tail of bugs. The late evenings have paid off, and the project manager gives kudos to everyone. So why is there still a knot in the developer’s stomach?

At least the customer feels good straight away – or at least after a few weeks of bug fixing. Some iterations later we hear ourselves saying “why does it take so long to fix bugs?” Those shortcuts add up to “technical debt.” For every turn, we add to this invisible mountain of low quality or not good enough solutions.

We have a double-sided problem here:

  • programmers are “forced” to low quality (shortcuts) and feel bad about it,
  • this is “invisible” to the product owner, customer, etc.

This leads unhappy people on every side and slow cycle times. We need an easy way to describe this shortcut and to feed it back through the pipeline to the backlog.

Play the Black Card

Let’s go back to the point in time when we take the shortcut. The developer, that’s usually the person with the best knowledge, should create a Black Card that describes the alternative and possible remedies. Create this card as soon as you took the shortcut. It will be fresh in memory and not weigh on your mind. It is great if you can estimate it at the same time, but not necessary.

A Black Card:

  • Title: Describe the shortcut in business terms (as much as possible)
  • Describe the problem with a few sentences. Add possible risks or consequences if we do not address this debt.
  • Possibly estimate the cost of fixing.

Put it into the backlog. At this point, I always feel better. Unloading that bad feeling is good. Remember to bring it up in the next retrospective. Anything to add? Assign it to the PO for further handling.

Use "black cards" to unload the shortcuts that you had to take. Retrospective it and get them into the backlog at the responsible point in time.

Use "black cards" to unload the shortcuts that you had to take. Retrospective it and get them into the backlog at the responsible point in time.

Hey, as Scrum Master I can even sum up the cards from the iteration and construct a “technical debt diagram.” We can follow the trend. Maybe we should use a black background as to set the mood accordingly? 😉

My fridge & the phantom work jam

April 17, 2011

Have you ever had too much to do? Did you react by working even harder – like the rest of us? At first, the situation seems to improve and everything looks just fine. However, even though “harder” might lead to “better”, it still is not the same as “good”. Time passes and you keep putting in the extra effort and then some. By now you are quite busy, but not actually getting anything done. Congrats – you have met the phantom work jam.

I was in my car talking over a really bad connection. At the far end was Steve Denning, a renowned author of several books on management. He wanted to know how we work at Jayway. During a long interview, interrupted by countless GSM holes, we kept talking. Among other things I told him the story of our old house – a school from 1928. It is a good example of a renovation that had gone wild and how we managed to get on track again. It ended up in Steve’s new book which came out last fall, “The Leader’s Guide to Radical Management” (http://amzn.to/radicalmanagement). It is a great book and a funny thing happened while I was reading it: I took notes in the margin. That has not happened in the last twenty years, basically back in university. Denning’s book really made me think. I just had to scribble and make comments.

Shortly after the interview I got the transcript – boy was that a sorry sight. Not only did the bad connection play tricks, my half-finished sentences and fuzzy thoughts made the text almost incomprehensible. Therefore, I was thoroughly impressed when I got the following text from Steve Denning’s latest book. It was spot on.

“The Leader’s Guide to Radical Management”
CHAPTER 7— PRINCIPLE #4: DELIVERING VALUE TO CLIENTS IN EACH ITERATION

Björn Granvik lives in Malmö, a small town in the southern tip of Sweden. At work, he is the chief technology officer of a software firm called Jayway. In the evenings and weekends, he works on renovating the house that he occupies with his wife and three children. The house used to be a school and so it is rather large, but doesn’t have many rooms. Transforming it into a livable house requires a massive effort.

When he started the renovations, his wife would stand in the corner in one of the rooms, and she would say, “Björn, here’s something over here that doesn’t work.”

And Granvik would run over and start trying to fix it.

But then he would hear her from somewhere else in the house and she would shout, “Here’s something even worse.” And he would leave whatever he was doing and go over and try to fix that. So he kept running between projects in the house. There was so much to do that he was constantly jumping from one project to the other, hardly ever finishing anything. So one day he said to his wife, “This doesn’t work. We can’t go on like this.”

Granvik had encountered a phantom work jam! Too many inputs had jammed the system.

Given Granvik’s experience with the practices of radical management and the simplicity of the situation, the solution was fairly obvious.

“I know that there are a bunch of things to do,” he told his wife. “But we need to do them in some kind of order.”

So he cleared a space on the door of the fridge, and he said that they would have three available slots. There would be one slot for all the big things that needed to be done—things that take a lot of time like fixing the leak in the roof—and two slots for small items, something that would take less than an hour to do, for which he could squeeze in an hour here or there. That might be like: “Hang ten photographs on the wall.”

“Anything we put on these slots,” he said, “we can talk about. And we can get them going. I will concentrate on these three things. If something else comes up, we can put it on the side of the fridge, but I will not look at it. There’s no point in talking to me about this, because although I will listen, I won’t do anything about it. I will only work on the top priority items in the three slots on the fridge.”

So he and his wife began working this way. And it went really well. He was happy because his wife stopped bugging him about things that weren’t on the priority list. And she was happy because things that she really wanted done were actually getting done.

The interesting thing was: it turned out that his client—his wife—was equally happy if he hung ten photos, or if he fixed the leak in the roof. Fixing the leak in the roof is a big expensive project that takes considerable time and effort. But the amount of joy that comes from it was no bigger than a tiny task like hanging the ten photos.

By focusing on what his client really wanted at that particular moment, he found that increasing client delight didn’t necessarily cost more. A small thing delivered sooner could delight more than a big thing delivered later.

In order to become more productive, and generate more delight for his wife, Granvik had to restrict the flow of work. To go faster, he had to go slower.

Steve Denning goes on to talk about “phantom jam work” and the havoc it plays on our efforts. Doing too much at the same time invariably leads to less being accomplished. It certainly does not feel like it. Putting in the hours makes us count the effort and not the actual value we create. Just like tunnel vision, we are blinded by speed and forget that we are not reaching any goals.

Whenever you are stuck in effort blindness, stop and think.
– Am I really doing the right thing, the right way – is this value? Is it fun?
In my case I needed something that would focus our effort. Something to slow us down and get stuff done, really done. “The big and small list” was my solution of getting a good flow through my org… err, family.

Works for big people
So how did we do it?

Figure 1: Our fridge and the simple task board with a “small” (lilla) and “big” (STORA) list. Big stuff is “lift roof and fix it”, small might be “hang photo on wall”. Second from the left at top is the “build room” note (Bygga rum).

The first important step was to reduce the number of things going on at the same time. The lists are each limited to “3 notes”. This meant nothing could be introduced or worked on before there was a vacant slot in one of the lists. In order for this to work we have to prioritize the work. It is of no use if I go off on a fixing spree if it is not what both my wife and me needs or wishes.

Separating the small stuff into their own lists, or “swim lanes”, was the next step. As a parent I usually can squeeze in the 1 hour tasks somewhere into my calendar. Getting those smaller tasks done is an easy way to turn around a bad situation. It was baby-sized steps, as compared to the big list stuff, but at least it was a step forward. And remember, sometimes even small values are big wins.

Works for tweens
As Steve Denning writes in his book, we actually started to land projects, small and big. My wife was happy again, but my oldest son Max started to talk about the rooms I had promised him and his younger brother Felix. Since we live in an old school we have rather large rooms and no wardrobes. By Swedish standards we are apparently defined as “cramped living” (Swedish “trångbodd”). The statistics have us as living in a “small” house since our three sons shared a single bedroom. This is no small feat in the 360 m2 (3 800 square feet) that make up our ex-school.

My oldest son, Max, kept asking me (in a nice way) about his room. Being 12 years old, I could understand him. He wanted a room of his own. I recognized the earlier situation with my wife and yet again our fridge came to our rescue. This time around I made some more slots available – I needed to size up to include my sons. I explained why the “leak in roof” note came before “Build Max & Felix Room”. This worked really fine because it was now understandable and transparent to Max why he would have to wait. Moreover, our kids needed to be better included in the decision process. Roughly once per week we visit the fridge and check the progress. If there are any vacant slots open we discuss what needs to be done – both fun and important stuff get their chance. And of course, we constantly check to see if we have the right prio – something might have come up that needs to “push through” the other tasks.

In the spur of the moment I took a pen and asked Max for commitment.
– You could help, I explained. What do you want to do?
He took the pen and to my surprise he signed off on one of the jobs before his own room note. Despite being young he understood that helping me with some other task would make us as a team work faster on accomplishing his goal. Sure enough, when I came home one afternoon I found a big hole in the garden for one of our roses that my wife wanted to plant. It might not sound all that much, but digging through those layers of ice age clay leaves even a grown man panting.

Works for small people
My second son, Felix (8) saw and understood the fridge. One morning I came down and saw that one empty slot now had a new note scribbled with a child’s hand: “go bovling”. A couple of weeks later we did just that.

In order to get a sense of flow with the big tasks I introduced a “scratch”. Every man-day, roughly, was a scratch on a big note. Otherwise, they risked going stale – staying on the fridge “forever”. It also meant we got a counter and a “reward”. The quotes are needed, since a scratch is such a small reward, but none the less it works.

At this time we had introduced red notes. They were important high prio tasks that needed to be executed quickly, basically to push ahead of the ordinary yellow notes. This risked blocking out the fun stuff. Where is the R & R, if we just kept doing good? My solution was to introduce the green notes. It is a just such a natural color to indicate fun 🙂

Figure 2: The “before” image of the rooms.

Close to a year later, me and my children have finally built the rooms for Max and Felix.

All it took was: some 2,5 metric tons of building material, 97 man days of work (yes, I counted) and the ability to focus – all visible on our fridge.

Sometimes I even managed to find some work that was easy, but still important, for Bix (4). We were working on the roof/floor above the rooms and Bix had the important task of bending the floor boards. Boy, was he proud. All it took was some creativity in dividing the work.

Having a simple, visible system with understandable rules promotes transparency and understanding. As a parent this translates into less nagging.

Final thoughts

If you find yourself working really hard and being quite busy, without any real results to show – except for sweat – then stop and think. It will feel contradictory, but you need to limit your work so you can focus on getting something worthwhile done. Add some transparency and a shared prioritization and you get commitment. It doesn’t really matter if the people around you are colleagues or kids. We are all pretty much wired the same way.

Having learnt all of this, I’m I immune? Or will I repeat my mistakes and try to do too much at the same time? Most likely the latter.

The experience might make me quicker seeing a solution, but it’s still hard to convince myself – and others – that we need to do less in order to do more.

Figure 3: Max and Felix rooms.

Am I proud of what we accomplished? You bet.

//Björn

Scrum Shock Therapy, Part 1

November 17, 2008

Scrum consists of a straightforward process, half a bunch of roles and a few artifacts. Sounds simple enough, but according to an online poll 3 out of 4 projects that call themselves Scrum fail to implement even the simplest parts. To make matters worse, most of the mistakes are on the simple side of things. Is there a way to bootstrap the project? Might there be a sweet hard deal that we can use?

Scrum and Agile development has started to rock the world within IT in various ways. A simple, but powerful process that seems to deliver. Developers and customer alike are happy. What’s not to like about it? Still, there are signs of problems. Projects that claim to use Scrum do not reap the benefits, management looses patience with this new method and team members struggle to adapt an agile approach to their everyday work life. Why is this? And more importantly, what can we do about it?

The Therapy: Get off to a good start by directing the team with a careful set of good practices and a strict agreement that leaves little or no choice. The team can then, over a couple of iterations, gradually take command themselves.

Easy, but still so hard

Why then is Scrum so hard? Well, first of all it is fail-fast, meaning that any problems will be quickly apparent. There are no artifacts or process steps to hide behind. This is never easy. To this list we can add even more pitfalls that are just plain hard to deal with whatever method we are using.

Still, it does not explain why there seems to be so many simple mistakes with such a simple framework. One of the best examples is the failure to keep backlog that is prioritized and up to date.
– We’re doing Scrum, but we’re too busy to work on the product backlog!

That one has always short-circuited my brain. What can be more important than to decide what is important? This pattern of falling short and missing basic parts of Scrum even has a name – “ScrumButt”. If you look in the sentence above you see why.

Nokia created a test to make sure the projects are “Scrum enough”. These plain questions form a lithmus test that can be used to analyze most agile projects.

The Nokia Test
Iterative Development?

  • Iterations – time boxed, less than 4 weeks.
  • Software features – tested and working at the end of each iteration.
  • Iteration must start before specification is complete.

Scrum (in Nokia’s opinion)?

  • You know who the product owner is.
  • There is a product backlog prioritized by business value.
  • The product backlog has estimates created by the team.
  • The team generates burndown charts and knows their velocity.
  • No project managers (or anyone else) disrupting the work of the team.

The questions seem to be on the easy side. It turns out that this might not be the case.
One online poll, Nokia Test by Practice , about the ability to achieve the Nokia Test level gave some interesting answers. In essence, only one out of four give themselves a full mark. Half of the groups report that management interferes, not directs but interferes.

Informal queries by Jeff Sutherland among his audiences around the world give an even worse number – something like 1 out of 10 pass the Nokia Test. Hand on your heart: Does your project live up to this?

A survey by VersionOne tries to dig deeper into the current state of the Agile affairs. Under the headline “Top barriers to adopting Agile” we read the top four answers:

  1. Organisational culture, 45%
  2. General resistance to change, 44%
  3. Lack of people with experience, 42%
  4. Lack of management support, 32%

Take a long look at these barriers. No technical stuff. Nothing specific to agile. Just people.

What do we know?

Learn to walk before you run. Greek Proverb.

We could be a bit closer to today’s reality than these ancient words of wisdom. The Situational Leadership offers an approach to management that has been around since the 60’s. These theories say that there is no single leadership style that is optimal for all people in every situation. Situational leadership talks about four different leadership styles that need to be matched with the follower. Basically, when leading someone who is passionate, but have no experience, you should adapt and give clear directives. As the follower evolves his or her ability to execute, so should the leader using less directives and more encouragement. In the end the follower is able to perform with only a stated goal and little or no directives.

If this holds true for people, could it not be true for teams as well?

The Shock

So we have problems making Scrum and Agile efforts to run. What is the conclusion? Could it be that we adapt our leadership style to the group? Make them walk before running?

This is counter intuitive, at least to me: To go agile, we first need to control. We should not let our teams and managements start off without some kind of directives. Give them a good deal, some practices that make Scrum work. Otherwise, we are just repeating the same old mistakes as the next-door agile project. Set up an agreement with both management and team so that they can evolve and experience Scrum for real. Just reading a book (or article) or listening to some good speaker alone does not help you out there in real life. You have to experience it.

Shocking as it may feel: We need to exercise some control over the Scrum project start so that it can evolve and self organize! But, and this is a big but, this has to be done with compassion and genuine involvement, otherwise we stand the risk of destroying what we are trying to build.

The Therapy

So what can we do? We need to work the team, management and often the whole organization.

The Team Recipe

So how do we get started? Here’s a recipe for the team as it used at MySpace:
The Team

  • Scrum training session for everyone
  • Sprint 1 week long
  • Definition of Done:
    • Feature Complete
    • Code Complete
    • No known defects
    • Approved by the Product Owner
    • Production Ready
  • Story Points
  • Physical Task Board
  • All-in-one Sprint planning meeting.
  • No Multi-tasking, work in priority order.

Scott Downey, Agile Coach at MySpace

The idea of this recipe is to set a good practice right from the start. Instead of debating the details on how to work in an agile way, we can focus on getting going.

Everyone has to have a common Scrum understanding to start from, hence the training session. One-week iteration sounds really tight for any reasonably sized projects. The thinking behind this is to get as quick iterations as possible – the faster that the group gets going the better. Short sprints help in this aspect. We learn faster with more turnarounds.
This in turn affects the meetings where MySpace has elected to combine them all, except the morning meeting, into one single occasion. The time is just too short to in a weekly sprint.

MySpace’s definition of done is a good and basic list. However, as a programmer I lack for instance continuous integration, pair programming and so on. These are not mandatory to have, but I see them as enablers for Scrum and supporting your agile initiative.

The next two on the list – Story Points and Physical Task Board – are really effective. If you haven’t tried them out then please do. They work. Finally we have something that is a no-brainer to me even though I have great problems avoiding it, “No Multi-tasking, work in priority order”. Context-switching is expensive, just avoid it. The priorities are in order, you just have to follow them. In the Reference box you find a link to Scott Downey’s description of their therapy.

When the team matures, they should evolve and handle things more on their own and no longer need directives. At MySpace the group can “prove” that they are ready for prime time by reaching the following goals.

The Team Exit

  • Hyper-Productive (>240%)
  • Three successful Sprints consecutively
  • Good business reason to change the rule

The Result?

So how does this work out? At MySpace all groups achieved exit. All, but one, improved after that. One group even achieved a whopping 1,650% improvement after just four months (16 sprints). At Jayway one of the teams used such a bootstrap technique, primarily on the technical side, and reached 800% after 3 months.

The second part of this blog can be found here: Scrum Shock Therapy, Part 2 where I will look into how to handle management and organisation with some recipes.

/Björn Granvik, Jayway

Originally published at Jayway Team Blog.

Interview: Dr Jeff Sutherland, father of Scrum

February 2, 2008

Jeff Sutherland has piercing blue eyes – friendly, but probing – and a frequent smile. They are a bit like a distant uncle who wants to know what you have made of yourself.

After several CTO assignments at various companies, Jeff Sutherland found himself at Easel corporation where he created Scrum together with Ken Schwaber. Ken later presented this methodology at the OOPSLA conference in 1995.

A dozen years later I find myself in search for a good spot where I can concentrate on my interview. Jeff and I sit down at a café at the Øredev conference. My computer has been acting up going blue screen on me twice that day. Time is short and I wonder if it’s an omen.

Photo of Dr Jeff Sutherland.

Photo of Dr Jeff Sutherland.

Dr Jeff Sutherland. Photo by Mai Skou Nielsen, Trifork

Q: I hope I’ve done my reading. As far as I understand you’ve been a fighter pilot in Vietnam, an assistant professor in math and medicine and the CTO at nine different high tech companies. Moreover, you travel the world to teach Scrum. Does it take a resumé like this to invent a process like Scrum?

The key part of what makes Scrum work is “complex adaptive systems” and you need some understanding of this. Also you need to understand systems theory and how to optimise a system as a whole.

You do not have to be smart, but you have to thoughtful.

Q: How did Scrum start and from where does it draw its heritage?
Scrum and Lean both derive from complex adaptive system theory. Constraint theory is a narrow subset of complex adaptive systems thinking. Lean implementations of these theories have been created at companies like Toyota and Honda. Honda was actually more aggressive at this in the nineties, but then Toyota was more successful in the market. They also were more formalised and better known.

Q: Why does it work?
The first reason for all of this is important – super intelligent performance out of ordinary developers. In order to do that we need we need to set up a simple framework so that people will self-organize. The second reason is that there is no central point of control. The manager needs to back off. That is critical.

The third principle is behaviour that emerges in the team based on self-organizing in order to get max production.

The fourth reason is that the production is far higher for the group than any single developer. Groups actually achieve more than any lone bright developer.

These are the basic principles of a complex adaptive system. Any organization is a complex adaptive system. Software production is an organizational phenomenon. It is an empirical process that must absorb significant change in requirements, technologies, priorities, and people.

Q: You talk about managers, why is it important for them to back off?
A company needs to stop sub-optimizing locally. That is the thing that Toyota figured out, largely due to the efforts of Edward Deming and other Americans who trained the Japanese in WWII industry processes. Most managers just care about local performance. Managers have to work as a team to look across the whole spectrum. It is difficult for them. They’re paid and given bonuses on a single level, not the company as a whole.

For instance, look at the General Motors manufacturing plant in Fremont, California. GM shut down that plant 1982 due to several problems, among them quality. Two years later it reopened as a joint venture between Toyota and GM. Toyota needed a plant in the US in order to avoid import restrictions. In an agreement with the labour union they offered reemployment to the former employees.

Two years later the NUMMI plant was producing over 200 000 cars per year and was twice as productive as the typical GM plant. The thinking they applied is the same as “lean production” where Toyota makes the team responsible to figure out the best way to solve the problems and achieve the goals. NUMMI later won several awards for quality.

“Your battery is running low”, declares my machine solemnly. Jeff and I make a run for a power outlet and find one on the second floor. My power chord is too short so we stack up real close to the wall. It will do. More than that actually, it feels like we really are working together on this interview.

Q: Some parts of Scrum are frightening, like making the group totally responsible for an implementation. How come people in management buy this?

The best answer I can give you, is the discussion I had with my first CEO when I introduced the ideas of Scrum. We had a critical project with a hard deadline. It was a question of survival.

The CEO expected a Gantt chart [ed: a timeline specifying activities and their dependencies, showing the progress of a project].

  • How many Gantt charts have you received that actually worked? I asked the CEO.
  • None, was the short answer. In my 25 years I haven’t received a single one that was correct. I asked him if a 100% failure rate wouldn’t make it foolish of me to give him one.
  • What are you going to give me, he asked?
  • Working software. Decide for your self to if we’re on track. In return I made him promise not to disrupt the team before the deadline. At this point he started to worry.

I said that at the end of the month he could change everything he wanted, but not during that month.

  • If you do this, you will get significant more code with better quality.
  • I can live with that. Let’s do it.

Scrum was born in that minute.

It’s a basic contract between management and team. The team delivers twice as much stuff with twice as good quality (minimum) and the management supports the team in their efforts to self-organize and self-manage. If either party does not fulfil this contract then it will fail.

Q: Doesn’t Scrum fail?

Scrum itself is a set of rules that causes self-organization if certain things are put in place. It’s like the rules of soccer. Does soccer fail?
With Scrum you will fail significantly less.

The Standish Group \[ed: a company that specializes in IT studies\] reports that project in the range 3-6 million dollars with a traditional project plan fail more than 85% of the time. Scrum does a lot better than that!

Q: What are your top three tips on using Scrum?

Bas Vodde was the Lead trainer for Scum Master at Nokia Siemens Networks. He has the shortest set of questions to identify a dysfunctional Scrum team.

You must have iterations of 30 days or less with working software tested at system level at end of each iteration. You need an agile specification, just enough for programmers to start for that iteration.

You need a product owner who orders activities by business value of the feature set. The team estimates the product backlog.

And lastly, the team needs to monitor progress with a burn down chart and know its velocity at the end of the iteration.

Q: Finally, what is in the future for Scrum?

Hyper productivity on an economic and marketing level where companies consistently out perform their competitors. Scrum is a disruptive technology that will alter markets. Companies doing Scrum well will grow rapidly in both size and profitability and dominate their waterfall competitors. There is already a brain drain going on where the better developers are fleeing from waterfall companies to Agile companies. This will hasten the demise of traditional projects.

Q: Is this a shameless plug?
Oh no, we have achieved it in several departments at my company \[PatientKeeper\]. It is doable. Other companies I work with right here in Scandinavia are doing it as well.

Going away from this fast paced interview, I still have the feeling that I could have done more with my life. If Jeff can do it, then so can I …I hope

Originally published in JayView.