Sustainable Pace

This spring I had weeks where I was in complete overdrive mode. The attention I needed to give to work and personal life peaked simultaneously, and I was all in all pretty much constantly stressed out. This was not sustainable in the long term. Fortunately I managed to deal with the issues and cut down on work load and after a while things settled down. But I still wanted to take something useful out of the experience, and I’ll talk about it here!

Within Extreme Programming, Sustainable Pace is an important practice.
It’s a principle arguing that when developing software, having a consistent workload in each iteration increases measurability, predictability as well as code quality and employee well being. I find this principle to grow more and more worthy of recognition, and not solely out of a software perpsective.

For me, “sustainable pace” can be applied in a broader sense. So let’s first look at how it applies to one of my hobbies: jogging! I think anyone knows that if you sprint, you can’t go very far before you need to stop and catch your breath. Whereas if you jog along in a pace suited to your condition, you can run quite far! Sprinting increases the risk of injury and makes you unfit to handle surprises. Let’s say you’re running in a 10km race, and you believe that you have only 500m left, so you start sprinting. After a while you reach a sign post, indicating that you’ve got 2km left! Since you’ve pushed your body into running near its maximum capacity, how are you going to cope with the extra 20% of track to cover? Another point regarding jogging as a means of keeping fit, is that if you push yourself to your limit in a run, you might simply not enjoy it that much. Maybe you won’t notice the beautiful sights, the good weather or the nice, fresh air, that you would have done if you kept your pace. Thus, at the next scheduled time for a jog, you might decide not to run at all because your previous experience was just too rough.

To complete the jogging analogy we need to include the quality aspect somehow… is it there? Well, as Pheidippides should know, you can run far quickly and and make it in time
to your preset goal, but it always comes at a cost. For the ancient Greek runner who, according to myth, completed a Marathon distance to deliver news of the Greek victory over Persia, it meant his death.

I believe that you can also draw parallels to our daily life. If you’ve managed to fully pack your schedule of working overtime six days a week while taking an evening Spanish course and going to the gym four times a week trying to lose weight, you might just make it. But any unforseen event is much more likely to cause big trouble for your scheme than with a less dense plan, and such an event may actually cause all of your activities to suffer. Had you had more unscheduled time available, that could have been used for crisis management, you could possibly have continued with most of your planned tasks. When looking at it like this, I find that the value of allowing enough slack in your schedule is fairly obvious, and I think most people would agree. Yet very often we overestimate our capabilities and try to achieve too much.

Sustainable pace does not apply only to jogging, obviously, but practically to all practices where there is some finite resource involved (such as stamina, time or money); it is about managing the resource and making sure that supply matches consumption and that there is enough in reserve to handle extremes.

Let’s now focus on software development and why this topic is so important there. Unfortunately many projects are running way too fast for their own good. This includes many Scrum teams that take the ‘Sprint’ concept in the wrong way; they literally sprint, blind folded, during the whole iteration and usually end up crashing into the Sprint Demo Wall at the end! Near deadlines, many teams crunch hours and management demands overtime. Corners are cut, and features dropped. When you’re sprinting in software development, you’re not only risking burning out your core resource: the developers; you are also creating a greater and greater need for a ‘recovery’ period, when the team and code can settle. This recovery period would typically be the time when the built up technical debt is dealt with. However if the team is not allowed such recovery, the time needed for recovery will increase. Further risks that are induced on the project include the incapability to handle unplanned events. If the team is already running at maximum speed, how will you manage a crashed build server or several team members falling ill?

You may wonder how one determines that one’s running at an optimal pace. It’s easy to imagine situations where you are running much too slow, or where you have an abundance of slack. This would cause your competitors not only to overtake you, but to stay ahead of you! Hm, what about setting out at a reasonable pace and adjust your pace as you go? After a couple of complete races, sprints or releases, you’d probably have adjusted your pace several times and be very near optimal pace. E.g. you noticed that during the last Scrum Sprint, the team was feeling quite some pressure to finish the last tasks in time, and there was a test server that crashed that no one had time to fix. So when planning the next Sprint the team’d make sure to commit to less work.

As a summary I argue that for any activity, by keeping a pace where there are margins, you’re more likely to:

  • increase the quality of the activity,
  • increase the length of time that the activity can be performed,
  • increase the predictability of the activity being performed (on time and in time),
  • increase the capability to handle extreme situations that directly, or indirectly affects the activity,
  • increase participant satisfaction in the activity.

Now it’s time for all of us, I hope, to go and spoil ourselves with a Christmas spent doing things at an unsustainably low pace with an unsustainable intake of fat and liquids!

Merry Christmas and see you all in the Happy New Sustainable 2014!

Just Read: Personal Kanban

I’ve previously told you about my experiences of Personal Kanban (PK), at work and at home. I recently got the opportunity to borrow the book, Personal Kanban by Jim Benson and Tonianne DeMaria Barry, from a good friend and it did not disappoint.

Immediately notice the book’s subtitle “Mapping Work | Navigating Life”, because that gives an excellent insight into the mindset of the authors! The book takes you through the basics of PK such as its keystones of visualizing your work and limiting your work in progress. It continues with describing how to create your own Kanban board, with a value stream and backlog, and sends you off ready to start pulling tasks!

Further topics include optimizing flow vs. capacity, slack, push vs. pull, the horrors of to-do lists and the need to continuously refine your own PK process. You’ll learn about swim lanes, additional value streams, the PEN, and more. But if you only take these concrete subjects with you, you’ve missed the whys of the book.

Existential overhead for example, is something you will immediately recognize: You know “in the back of your head” that there are a million things you need to do. You don’t know exactly what they are or when you’ll do them, but they are there, right? PK helps you minimize existential overhead by visualizing and mapping the work ahead of you into something the authors like to call a narrative. Could it be possible that your organization suffers from existential overhead? How do you think your developers feel about that technical debt they know exist all across the code base?

Another interesting subject, is the Ziegarnik Effect, which is the strong propensity for humans to remember incomplete tasks over completed ones. We simply need to have closure on those things we have started, and with PK we get this in a very strong manner: by moving the PK cards to that final column on the board that emanates success: DONE!

This book is full of life and examples of how PK helped people in various situations and that gives it a very humanistic tone. Not only does it teach you everything you need to know about PK as a method, it follows up with why it is such a good method and how it will affect your life. This book is a must have for Agile exponents and anyone who likes to get things done with effectiveness.

Agile Life: Personal Kanban Revisited

In my previous post on personal kanban, I showed how I used a simple piece of cardboard to implement the flow at work. Having accustomed myself to the method, I tried to give it a go also at home:

Nothing done yet!

The picture above depicts my bedroom door, and you might notice (I suppose it might not be obvious) that my Kanban flow is vertical and not horizontal. It doesn’t really matter though – I just thought that the three areas separated by the wood working and the visibility of the door made for a splendid Kanban board for my purposes.

There is nothing new here, the method is the same as the one I used at work, but I’d still like to point out two things.

I’ve actually tried this exact method on a couple of weekends. You know the feeling you get when you have a couple of days off (perhaps even a few weeks of vacation), and in the back of your head is a long backlog of various things you need to get done. BUT, instead of organizing these tasks in your mind and start ticking them off, you let them slip and you go watch a game of football or some other completely unrelated thing.

Now, with this extraordinarily simple method, I usually get 80-90% of the tasks done, which is a vast improvement over a “no method” approach and oddly enough, also an improvement over writing all these tasks down on a piece of paper! In addition, some of the tasks that I couldn’t complete were impossible, or very hard (because they required to be done on a weekday for a certain retailer to be open, or similar impediments), which makes the statistics even better.

The second thing is, again, transparency. I suspect the reason why this method is better than “no method” or “paper method”, is the visibility of the tasks glaring at me from the top row of the door. Not to mention my cohabitant’s reaction to having a part of our home filled with little, yellow, beautiful(?), post-it notes :-). She even took a picture and shared it on a particular social networking site… Furthermore, she was WELL aware that I hadn’t completed certain, “important” tasks on the list and kept bugging me about them.

Hmm, I guess there are “some” drawbacks of this method after all…

Just Read: The Two Second Advantage

Coincidentally, the topics in the book “The Two Second Advantage” by Vivek Ranadivé & Kevin Maney, are both interesting and fascinating out of an Agile perspective and I’ll discuss this here in my impression of the book.

The book tries to show how some parts of human talent comes from wiring the brain in such a way that it perceives things just a little bit ahead of time. Phenomenal individuals, such as hockey virtuoso Wayne Gretzky and pickup artist “Mystery” are brought forward as examples of humans having acquired such talent. The authors argue there a number of factors required for this wiring to take place along with the now famous 10 000 hours of deliberate practice. To be able to predict the future, or assess situations, very quickly, the authors argue that the brain does something called “chunking”. This means that the brain, upon repetition or practice, over time builds up a “chunk” of knowledge of a certain topic. It can then use this chunked, mental model for predictions instead of having to look at all available data stored in the brain’s neurons. Supposedly, this is partly due to the substance myelin building up along frequently used neurons.

All this is quite fascinating but has a focus on the human body and its capabilities. However, these topics are just the beginning of the book and the authors soon progress to transpose their arguments to the business world. Here it starts to get even more interesting for us in the software business. They talk about the data explosion going on in today’s connected world, and about how 20th century solutions to finding important statistics and other information from what is gathered in a company’s servers, are simply not enough anymore.

Conventional data mining and analysis has a couple of problems namely that it deals with how things used to be and not how they will be. With the amount of stored data growing, there are also situations where it simply cannot be mined fast enough.

So, what has all of this got to do with Agile? Well as I see it, companies taking the necessary steps to introduce forward looking software, to gain a prediction advantage over competitors will need to have an Agile organization. They will need this because when their new predictive system tells them what to do, they must be able to pivot, and quickly put the knowledge to use before it gets old and useless. If done right, that must be the nirvana of Agility. To have a brain-like software constantly mining the business related data to predict what customers or clients will want to have in the future, and have the organization and delivery procedures ready to carry out the necessary changes ahead of time, with exactness.

The book is short, on topic and connects the workings of the mind with 21st century business processes, as well as includes a vast amount of fascinating stories and references. You can say it gets your mind spinning, and it’s worth a read.

Elevate: Continuous Delivery

This Monday, Neil Ford of ThoughtWorks held a talk about Continous Delivery at an Avega Elevate. I wanted to give a brief recap of this, not only due to the quality of the lecture but also because the topic touches on issues about moving organizations towards a Lean or Agile process.

With continuous delivery you strive to keep track of every change in your product. Not only does this mean to version control the code but it also includes keeping track of changes to the platform you are running the system on, the dependencies or 3rd party libraries, the application configuration files, the database schemas etcetera. You strive to build and thouroughly test each of these changes made to your product, so that there is always some deliverable ready to be shipped to a potential customer.

Now, continous integration in some shape or form is something I think most teams do today, or at least that’s my experience from the last couple of years. But what Ford argued is that you can now, with the increased quality in tools, automate a great deal of the, usually arduous, process of acually building and deploying your product. The idea here being that if you have total control of what components your product consists of, and you continously build and test it against a homogenous environment, you will be able to not only deliver, but also deploy, your product to production at every change in the product.

I won’t delve further into contious delivery here (I might retread the topic), because I think Ford hinted at other benefits of this than minimizing human resources and effort. If you really want to have an Agile organization, you would ideally want to be able to change your mind on a whim, and cast your product straight in the opposite direction of where it’s going, wouldn’t you? Ford didn’t like the abundant buzz around the word ‘pivoting’ but I’ll use it here, because it’s a very good word for this. How much time does it take for your organization to put a change of one line of code into production? If you have two companies in which one can deliver four times a year, and one can deliver 365 times a year; which one would most likely be most competitive? For me, this is a huge thing to think about when striving for agility.

I’d also like to mention the way Ford described the way his company worked when producing software. Everything needed by the developers, including IDE, machine setup (Ford reminded us a couple of times that yes, nowadays machines can be built from source code) was in version control. At the office, the work stations each had an exact copy of the version controlled environment so that every developer used replicas when developing. Furthermore, each day a work station would be manned by a pair of developers, pair programming for that day. The next day, the pairs were rotated and each developer might end up at a different work station where a new developer constellation would take on the challenges of software production (I should mention that each employee also had their own laptops that could contain personal software such as Itunes etc).

What a great way of incorporating XP practices, Agile, and team learning and interchange!

Agile Life: Transparency

Ever wondered what benefits Agile and Lean methods such as Kanban actually provide? Ever wondered what transparency ever did good to the world? I’ll try and provide an example right here, straight from my own ordinary life!

My cohabitant uses a medication. She’s supposed to take it every morning, and that will make her feel better. If she doesn’t take it, bad things can happen during the day. Not necessarily, but they might. If she takes more than one, it’s apparently not A-ok either.

A while ago, I found this thing (photo below), lying on the bathroom sink. Now, if you’ve looked at the picture (and know Swedish) I hardly need to explain where I’m going with this or what the benefits of transparency are in this particular case. But hey, let’s say for the sake of it, that the picture isn’t showing up in your browser.

Transparency Tool!?

The thing she brought home is a plastic box, with seven compartments, one for each day of the week. She fills these, one pill in each, so that each time she takes a look at it she knows whether she’s taken the pill that day or not.

You know where I’m going with this now, don’t you? Since this box is in OUR bathroom, I happen to see it too, every time I visit the place. What do you think happens when I see a pill in the Wednesday compartment and it’s Wednesday afternoon?

Another effect of the box in this simple analogy, is that I, an external part of the process, become much more aware of the details of it. Immediately after she started using the box I recognized how often she takes the medication, how many pills she takes each time, the size of them, etcetera. Questions I previously couldn’t have given answers to when asked about. In effect, she’s shared the process with me, in a vary unobtrusive way…

Right, so I reckon transparancy works like this also if you scale it up, and use it in software development. Wouldn’t you agree?

Don’t Underestimate…

You know it happens all the time. You know you’ve done it yourself. Indeed, I’ve done it too: Underestimated a story or task that is. This may seem like an innocuous thing at the time it happens, but of course it can have pretty dire consequences.

In my experience, people tend to underestimate tasks for a whole range of reasons. It easily happens in groups or teams where the members aren’t fully secure where they stand on a professional level compared to the other members. Many people hesitate to tell a room full of new acquaintances that their estimate is way off target, and fail to realize that precisely that may be the ‘senior’ thing to do. Obviously, newly created teams are prone to this issue.

There’s also the issue of pressure on developers to ignore risks in certain situations. When your estimates decide whether your company will get that ‘fat’ contract – a job you, as a developer, are desperate to land due to the nature, size, importance or technical aspects of the project – it may feel like the most natural thing in the world to underestimate. Pressure can also come from management or from expectations on a person elevated to ‘architect’ status to perform miracles in no-time.

Yet another another underestimation trap to fall into is our tendency of pure wishful thinking. Nothing bad could possibly happen to my progress when using this pre-alpha document database, I promise!

I’m not talking about zen agile projects that have the same team running for years, in a business area where the money is flowing and everything is hunky-dory. The software world is not that perfect, and the above mentioned constellations of new teams, short-term projects and up-front estimates are not uncommon.

Anyway, there’s a scientific term for this, namely ‘Planning Fallacy‘, which automatically makes it more comfortable; we know others are experiencing the same thing. Unfortunately that doesn’t mean we want this ever to happen.

Thinking back, I remember a smaller contract project that a client requested offers for. I estimated the total effort to something like 50% more than the winning bidder. The project was supposed to run for about two to three months for a couple of developers. A year later the client had finally received an acceptable delivery. However, the code base of the product was not in a fully coherent state and thus my company got the chance to continue development. In the end, it would probably have been more profitable for the client to scrap the code base and restart from scratch.

If I would list a few recommendations to alleviate the problems, it would look something like this:

  • Management and project leaders or other stakeholders should try and conceal any preliminary budgets or estimates to the team. Otherwise developers could easily be influenced.
  • Architects and senior developers must take responsibility of having the mature view of the estimation of tasks. They should have the best apprehension of risk, and should try not to jump to conclusions.
  • The team should learn and use available estimation techniques, such as Planning Poker.
  • Everyone involved should be aware of that in the long term, it’s more profitable both for the client and the contractor, to cancel work that have very little chance of being completed within the given budgets.
  • It’s very hard to overestimate things by a large margin – stay on the safe side. Even if you manage to meet your daredevil estimates, will you be comfortable with the delivered code quality?

It’s not easy being a client; it’s hard to know which contractors can be trusted and which cannot. If you’re a manager looking at budgets there is an immediate pressure to find bargains. Developers also have a hard time, contractor or not, with the issues described above. But the next time you estimate something, anything, do our business a favour and don’t underestimate the cost of developing working software.

Personal Kanban

Personal Kanban

I’ve been doing personal Kanban at my current assignment for the last two/three months. A colleague had previously told me he was using it at home, and I wanted to see if I could benefit from it at work. Now, I didn’t actually look up the ‘correct’ way to do this, but instead opted to start with my current conception of the method. There was a leftover piece of cardboard laying around, so I took that and drew two lines on it for the ‘todo’, ‘doing’ and ‘done’ phases. On the bottom of the board, between the doing and done phase, I put my own ‘definitions of done’ to remind me of what it should mean to complete a task. The criteria I chose initially were

  • Reviewed (by myself),
  • Unit tested,
  • Javadoc written,
  • SoapUI/Selenium tests created and run,
  • Maven build and tests run,
  • Code committed,
  • Time spent reported into the time reporting software.

You can take a look at the picture below for the setup. Nothing revolutionary of course… I chose a WIP-limit of two and that’s been quite sufficient so far.

Personal Kanban Board

My experiences thus far are that I have become a little bit more structured and focused; I’m more aware of my current work load; I’m a little bit better at keeping track of tasks (the smaller ones that can easily be forgotten); and I’ve got an easier time filling out the time report for each day. Of course, the benefits of the method have not revolutionized my work day, but with the minimal effort involved I’d say the experiment is a success.

I’ve learned some lessons: that the company supplied post-it notes keep falling off the board, so I should look into buying some top quality ones. I also found that I sometimes put up a task on the board of too large scope, and that I failed to complete it quickly enough. That meant it clogged up the doing lane, while I had to expedite other urgent matters. I should have broken the task down into smaller ones, clearly!

As an experiment, trying out personal Kanban is something I can recommend. You should see the mentioned benefits quite quickly, and if you’re new to Kanban, you should get to familiarize yourself with the concepts. If you want to know more about this please visit Jim Benson’s Personal Kanban site!

From Ad Hoc To Agile @ Avega Elevate (2011)

So, yesterday we had an Elevate at Avega, where we discussed moving organizations from using ad hoc processes to Agile ones, using the fishbowl format. We were fortunate enough to have Håkan Forss with us, who contributed greatly! Thanks for coming down from Stockholm J

Although, the fishbowl format doesn’t necessarily produce amazingly quantitative results, it is excellent as a form of sharing knowledge and thoughts. The value of this kind of discussion is still great, and for me just raising the question and having a bunch of experienced consultants looking at it, is very important.

I think we concretized a few things though. We talked about what Agile methods can bring to the table for any organization or project. We talked about what impediments exist in ad hoc organizations that must be managed when trying to reform. Finally, we talked more in depth of how to actually accomplish this.

We agreed that Agile methods have a greater chance of avoiding building products or product features that no one uses (the 45% unused rule). Agile can give individuals and teams more freedom to act, giving a morale boost and possibly knowledge and responsibility expansion. One of the biggest impediments is an organizational lack of faith in Agile methods, i.e. there is a problem in providing method creditability to managers and teams. Does the new method really work? Do we benefit? Where are the results? Old organizational hierarchies and practices also exist; we fear what we don’t know and even though we logically could see a new method being superior, we cling on to the old ways. Certain people have strongly cemented roles, and can have a high resistance towards change.

Finally, we talked a lot about the merit in moving toward an Agile approach with an iterative mindset. Using an Agile change backlog and introducing small experiments such as letting the DBA help the developers to write scripts during one sprint and then evaluate the results, are examples of such an approach. You cannot create a cookbook recipe however, and you must look at the organization, its needs and its goals to be able to choose the right Agile method and way of reforming.

This was just a brief summary; there were many other good ideas and conclusions. The only way not to miss out is to come and join us! Next time, we will learn how to benefit from social media, invite yourself here: [] (that was 2011, this is a re-post).

Agile Issues In Öresund

There is one thing that has started to make me just a little bit uneasy about Agile and Scrum. It’s an issue that has come up in different projects, time and time again, and while I am an avid Agile proponent it makes me frown and even fume a bit on occasion.

It’s about how Agile teams perform and the correlation to the way people and organizations are transferred from working with a waterfall, ad hoc or other development process to Agile in general and Scrum in particular. In my experience, this metamorphosis is often not done in an adequate fashion and sets up the whole organization for confusion and nasty problems later on.

Sometimes the management gives a green light to start the transformation, but doesn’t bother to learn what is required of it and lays the responsibility on the development organization. Sometimes the new Scrum Masters are old project managers, molded into a new role and forced to think in a way that is quite different from their previous experience of PMI and the like. Sometimes the new Scrum Masters are skilled senior developers, brilliant architects, or simply unmotivated developers or test managers that have no other place in the project. Yes, that last one is more common than anyone wants to admit. On occasion, someone gets the honorable Scrum Master hat but agrees to also fulfill his other one or two full-time roles… A few times I’ve worked with developers that had such little training in Scrum that they didn’t know how to behave in the daily standup, or how and why to unit test, nor how to…. you get the idea.

Actually, none of the above are rare incidents. In my geographical region of work, they are instead commonplace and not exceptions. My question is simply: Can a person really go from knowing little about Agile to being proficient enough for it to work, in the twinkle of an eye, or say… two days’ worth of simple training? Of course they can’t, I just like using rhetorical questions!

Flaccid Scrum

Martin Fowler and Ken Schwaber have both acknowledged these issues that Agile is struggling with.

Fowler writes in his blog ( that although teams adopt the processes and practices of Scrum, Scrum doesn’t mandate any particular technical practices. After a few iterations, the code starts to hurt internally due to lack of technical attention. However, he also points out that many teams fail because the team itself fails, and most likely would have failed regardless of development process. I agree with this, but it certainly doesn’t help that many teams aren’t even getting the Agile processes right…

Schwaber mentions flaccid scrum in his letter ( on the inception of his new Scrum organization He singles out the need of better and more thorough education of all participants of Scrum via new course assessments and better instructors. Of course, according to Schwaber, he wasn’t allowed to do this at, and promptly started the new organization. Regardless of the intentions of each party I’m happy to see some competition in the field of educating Scrum recruits.

I believe that further improvements could be made if managers improved in their “Agile management” role. They can’t just drop Scrum onto the development team and hope for the best while old office divisions, roles and processes remain. An even bigger responsibility falls on the Scrum Masters and Product Owners. The collaboration between these and the team are almost always lacking in some regard; communication often being the aspect that isn’t working as well as Agile wants it too! In any case, this is a pressing matter that I would very much like to see improve quickly, before Agile gets the didn’t-work-stamp.

I’m very interested in hearing what the situation is in other geographical regions, and also what remedies or cures of these symptoms exist, be it an iterative introduction of Agile or perhaps a  Kanban approach. Feel free to share your thoughts below.

Finally, I am very pleased that my suggestion to bring the topic to my company’s public live forum was accepted. So, if you’re in the area of southern Sweden, you are more than welcome to join us in a heated fishbowl ( discussion on 11/16 (that was 2011, this is a re-post)!