One week in the staging environment

Some things are hard to change. A policy that seems to haunt me is that you must stabilize (or harden) a release candidate for a certain period of time (for instance in the staging environment), before you can deploy it in production.

Last week I tweeted:

One reason for establishing this kind of policy might be that it’s related to a (predefined) release schedule. The system simply has to stay there until it’s time for the next release. The problem, from a lean perspective, is that most of the time stabilizing is waiting (or idle) time. You build inventory.

Ideally you should try to minimize the waiting time by deploying more frequently. If you don’t know where to start, you can read up on continuous delivery, but you can make thing better simply by moving the value adding activities earlier. This makes sense because you shorten the feedback loop.

In other words:

Dealing with large tasks

Are you facing a large and complex task? Sometimes it’s hard to even get started, right?

A natural response would be to start analyzing the task searching for the most efficient way to deal with it. But it’s easy to over engineer a solution, and for me this is never the most efficient approach. I simply don’t (yet) know enough about the task to do this kind of thinking up front.

This is why I prefer to start with the smaller tasks that I actually do know how to deal with – without giving the bigger picture much though. I move on, one (sub)task at the time. This seems to work magic. I now naturally know the next natural step, and can create more (sub)tasks. All of a sudden, the large and complex task seems manageable.

I know this sounds trivial, but it’s really about the mindset. Of course, you have to put some thought into it, but over analyzing a task before you start working on it is waste. Instead, start with what you do know, and make it a habit to split tasks early if it’s too big. It’s better to do this early than late.

Every now and then you will get stuck in a task, because you made wrong assumptions. When this happens it’s hard to take a step back and start over (the right way). This is a muscle you have to train, so make sure you reward yourself whenever you manage to do so.

Related:
http://hunskaar.com/how-to-boost-your-personal-productivity-part-2/

Effective meetings – is it possible?

How does the culture in your organization go along with possibility of achieving effective meetings? A month back I wrote a post at the company blog about this, why it might be difficult, and how to improve it.

If you understand Norwegian you can read it here:
http://open.bekk.no/er-effektive-moter-i-det-hele-tatt-mulig-i-din-organisasjon/

Agile and congruent leadership

You’re a leader in your organization, and you want to improve efficiency. You think you want an “agile transformation”, because you heard others have been successful with it.

Then remember this:
Agile is not just a label you just put on the development department. Agile is a behavior and should affect everything you do.

So if you’re still up for the “agile transformation”, then it’s your job, as a leader, to do whatever is in your power to pave the way for every team, project or department, so that they can carry on with their agile transformation.

Start by truly understanding how agile works and how it affects the organization. Be congruent in actions and words. Ask for elements that are in harmony with agile. Don’t ask for reports, estimates or commitments from a bygone era, just so your way of reporting upwards in the organization is easier. Take that fight yourself. Show that you have confidence in your people. Give honest feedback.

Agile transformation is more than words, it’s behavior, and it affects the entire organization. Start by changing your own behavior.

Talking with carpenters

We are currently renovating an entire floor at home, and yesterday I tweeted about a Kanban board I put up for my carpenters. This was only meant as a “joke”, of course, but it generated some feedback and therefore, upon request, I share the board with you:

image

The intention was not to create a complete work list for them, but I wanted to visualize where their work and my work meet. A couple of examples are; “Pick up new kitchen from [vendor]”, “Tiles will be delivered between 0800 and 1400″. For now I use the columns Later -> Tomorrow -> Today -> OK!

And how did they respond to this? They seemed to understand the concept right away. They even pulled me over to the board today, pointed at a note to discuss possible changes for this particular item. That’s a good sign, if you ask me. They might never move a note on their own, but I think we communicate better this way. Luckily, the carpenters are early birds, so we even have time for daily standup before I leave for work.

To be honest I’m not sure if this goes under the definition of a Kanban board, but once again I see that a visual representation of how we work is powerful.

One word: Feedback

With all the different management models out there, chances are you’ve come across a model that can help you solve or improve a particular problem. From a bird’s perspective, they might look simple, but to fully grasp how to apply them in your organization, you need a deeper understanding than you can get from only reading a book. You need hands-on experience.

This triggers a question: How do you apply a generic model you don’t even understand the complete extent of, to a specific situation of high complexity?

Normally, when you get a question like this, you know you won’t get an answer in just one sentence. But the answer can be rather simple, actually just a single word: Feedback.

It doesn’t matter what the model is for and what it is designed to solve, but once you decide to give it a try, remember this: Get the feedback you need, as fast as you can, so that you’re able to take corrective actions. The more complex the situation is, the faster you need feedback.

No feedback is synonymous with failure, and the model certainly won’t do you any good. You need hands-on experience and you need feedback, that’s how you truly understand how to apply the model.

How to boost your personal productivity? (English version)

A while ago, I wrote a blog post in Norwegian about how to improve your personal productivity, by combining Personal Kanban and Pomodoro. This blog post was recently published as an article, in English, by ProgramUtvikling in their magazine – The Developer (No 1, 2012).

Read the full article: The-Developer-1-2012.pdf
(Page 12-16 according to table of contents, page 7-8 in the PDF.)

Take a look, and let me know what you think!

Page 1

Page 2

Please note that you always can read the latest number of The Developer here.

Exploring WIP limits

A few months back I was involved in a highly developer centric project (very unlike my current project). Non-developers were basically only involved and available upon request, so most of the time the team was not very cross-functional.

The team was using Scrum at the time, but the flow obviously had a few glitches and user stories had a tendency to pile in the test column, until very late in the sprint. A huge team effort at the end of the sprint made us finish most of the user stories just in time for demo, but the hurry was at the expense of quality.

It seems to me that most developers prefer starting on a new user story, rather than truly test and complete the ongoing user story. There’s really nothing strange about this, because often the fun part is gone as soon as the problem is solved. In the good old waterfall days, as a consequence to this “law of nature”, none of the features in an entire release might have been tested properly until very late in the project. Needless to say, this didn’t work out very well, and agile emerged to address these problems.

To fully complete ongoing tasks faster, we need to build in mechanisms in the process that enforces us to finish tasks before starting new ones. Iterations (sprints) do this by limiting the number of tasks we can have ongoing during a shorter period of time.

In our case, this didn’t do the trick alone. We shortened the sprints to only one week, and admittedly things got better, but the symptoms were still present. We decided to apply Kanban. First we put a WIP limit of 3 in the test column, later we added WIP limits to other columns as well, to be able to regulate the flow better. To improve the quality on the deliverables, we introduced a rule stating that the person testing a feature must be different from the person developing a feature.

In the beginning, the limits worked more as a guidance than actual rules – just to start changing the mindset from “push” to “pull”. After a while we paid more attention to the WIP limits, and lowered the limit in the test column even more (WIP = 2) to amplify the importance of finishing tasks. This turned out to be artificially low, but it was a great “pull” lesson for the team.

After a while the flow improved and the team effort was more evenly distributed over time. Initially, I thought we might have to “force” people into testing, but our board made it clear what had to be done, and the developers were eager to contribute wherever necessary (an indication of the power of visualization). As a bonus, the number problems we had earlier in the demos went down.

I should probably add that some of the developers took more than their fair share of testing. Over time that could have been an issue we might have had to deal with, but for the short period of time the project was ongoing, it didn’t turn into a problem.

Still, these small changes made a huge difference to us. We no longer had to rush into demos with poorly tested features, and the “boring” parts of process were no longer only at the end of a sprint.

A simple tip for more efficient standups

A while ago, I was asked for advice on how a team could improve efficiency on standup meetings. The team was growing, and their standups were taking an increasingly amount of time. I didn’t have much time looking into why this happened, so I simply suggested they could try walk the board instead of using the traditional Scrum meeting.

As it turned out, it didn’t have much effect. People on this team are usually responsible for one ticket (user story) each, so they all end up speaking anyway. I took a closer look, and realized their great team spirit might be of the reasons why their standups takes too much time. They like working together, there are many outgoing personalities, and they like solving issues directly in standups. In addition to sharing information and solving problems right away, the standup meetings function as a social meeting place.

This is all fine with me, actually I would even encourage it, as long as the discussions are relevant for most people, and they finish up within 15 minutes. As soon as the team grows, however, not all discussions are relevant for everyone. So, the question is, how to improve the efficiency without killing creativity and good team spirit?

In similar situations, we have had to establish some ground rules to add some discipline and structure in the standup meeting. One way of doing this is by establishing a “parking lot” next to the board.

Whenever a discussion starts, we take a collective responsibility to end it gracefully and note the topic down in the “parking lot”, so that the discussion can continue after the standup meeting. Putting names of whom should participate in each discussion, can help determine the most efficient order of dealing with the topics afterwards. Here’s an example:

This usually works quite well. It helps us focus on the meaning of standups, which is sharing status and relevant information – and it shortens them down. You should try to identify problems in the standup meetings, but you don’t need to solve them all right away. To make this work, you need to add some amount of disciplin, but only with rules the team have agreed upon.

If the team is involved in creating the rules, then you have made the first step building a collective responsibility within the team. I believe there’s subtle, but important, difference by how individuals interpret “ending a discussion” vs. “postponing a discussion and create a new arena for discussing the topic”. We don’t want strict rules to get in the way of good team spirit, do we?

Please share your tips for efficient standups!

How to boost your personal productivity?

I published a new blog post on the company blog; “How to boost your personal productivity?”. It describes a combination of Personal Kanban and Pomodoro, and how this works well for me.

It’s written in Norwegian, and you can read it in full-length here:
http://open.bekk.no/hvordan-booste-din-personlige-produktivitet/

For my English-speaking readers, I recommend reading the article that inspired me to combine these techniques:
http://paulklipp.com/images/PersonalProductivity.pdf