Blog Image


Agile - sharing experience

The idea with the blog is to share experience about Agile in practice, I have been facilitating CoP (Community of Practice) with Scrum Masters, Product Owners, Team members etc. since 2010 with the purpose of sharing learnings from team to team...

“Learn from the mistakes of others-you can never live long enough to make them all yourself.” quote from John Luther

Maintenance using Kanban

Agile in practice Posted on Sat, March 29, 2014 16:53:17

I will have a short (12 min) presentation at LeanTribe in Malmö May 6 2014 with the topic “Maintenance using Kanban”, the presentation is very close to the one I wrote about in post13 – I added a few things and made it a PDF file…
I added a comment to Valdims presentation here

Input to EASE – helping teams

Agile in practice Posted on Thu, February 13, 2014 10:13:48

I gave a short presentation today at our EASE workshop – I presented page 1 and 2, the rest should be read as input to the Executive summary…


Agile in practice Posted on Sat, July 13, 2013 15:01:32

have never done any real work – it is becoming quiet a cliché to
write things like this, but I believe that it is important to write
about it, the quote “Nothing is really work unless you would
rather be doing something else.” (James M. Barrie) is important
and have been my guideline over years.

is never black or white, but when things start to become more work
than fun, it is about time to find something else to do 😉

was sitting at work one day, I was having
real fun, laughting out loud and one of my colleagues gave me a
comment “you really enjoy your work!” – well it was half
trouth and half irony, the reason why I was laughting was because I
was reading an instruction of how managers should handle talents in
the company, a process to secure that they grow.

was thinking about my work experience with people, everyone have
talents, some have more special talents, but they all have something
in common, if they user their talent and are given space, they will
develop it as far as it can!

read this the other day
we empower teams, the IQ of the individuals actually goes up—that
is, we actually get smarter! And, sadly, the opposite is true:
Controlling teams actually causes team members’ individual cognitive
power to decrease…”
– this brings me back to the instruction from HR and process of how
to handle talents, if managers need a process to handle talent, there
is something wrong with them, no one is equal and no process will
ever work with the most talented people.

happen to work with some very talented people and it is fantastic to
see how they develop, to me the most important thing is to trust
them, empower them and allow them to fail – and yes you need to
guide them or rather coach them, i.e. listen to them and get them to
see solutions by themselves – which by the way is much more
powerfull than when they are “educated”.

what does this have to do with Agile? Everything!

is about empowerment, it is about making things work, there is no
such thing as Agile by the book – at least not something that works
fantastic – everyone is different, and every team is different, you
have to listen to them, have to learn to know them and help them to
develop their full potential. I read a job-application the other day,
they wanted a ScrumMaster who worked strictly by the book, I was
thinking about writing to them, but decided that it was not worth it,
you can truely get inspiration from books, from conferences, from
others etc., but no one is equal and no one should be treated equal,
unless you want to limit them in their development.

believe that you have to work a couple of years before you realize
this, which is strange, but it is the same thing when it comes to
being a parrent to 2 or more kids, you cannot raise them the same
way, it is impossible, however you usually don’t think about it, and
it is the same thing when you work as a leader, you rarely think
about it, but you have to, specially if you have a HR department who
make process for managers, if you follow them without thinking, you
will never be able to develop the full potential in the company!

Closing the loop

Agile in practice Posted on Wed, June 12, 2013 19:51:51

I did a presentation in Malmö at in late May, I have tried to write the most important content in this pdf file…

We had a lot of good discussions after the presentation, which I have not been able to write down, I guess most of it is on the blog already…

A challenge when working with Scrum

Agile in practice Posted on Mon, June 10, 2013 21:18:22

I recently had a discussion with a colleague – we talked about Scrum and the challenge we often face when we work with Agile in an organization who is use to work with water fall Project management.

The challenge is to understand that when you work with any kind of software development, you have 4 variable parameters:

  • Quality
  • Resources
  • Time
  • Scope

I thought it is clear that you can only fix 3 parameters, i.e. in waterfall development you fix Resources, Time and Scope, but the quality is the one which is suffering – in Agile you fix Quality, Resources and Time but the scope is flexible

There is no way you can fix all 4 parameters, and the challenge that we often see is that Projects want us to deliver all features at a given time, with given Resources and they expect the quality to be perfect – as we use to deliver high quality when the Scrum teams deliver Software

It is clear to me that we need to adress this problem when we work with PO and Projects who are not use to work with Scrum teams… 🙁

4+4 planning

Agile in practice Posted on Mon, February 25, 2013 22:04:38

I will here try to give a short version of how we do 4+4 planning at Sony.

Short overview:

  • 4+4 planning is a 1-2 days workshop for all teams, PO and SM.
  • 4+4 planning should be done every 8 weeks.
  • It is a great tool to give the project an overview of what will be implemented within the coming 8+8 weeks.
  • It gives the teams an overview of coming work and allow them to deal with dependencies and risks before they become a problem.
  • It is a fantastic way to get the teams commitment to the coming work (8 weeks).
  • Pictures and comments at last slide from workshop


We started to work according to Agile principles in the beginning of 2011

Team usually never had more than max. 2 weeks view of what was in the pipeline

Dependencies to other teams was a challenge

PO not available for some time was causing problems for the teams

Spikes was hard to plan for

Commitment from PO/manager caused problem for the delivery

Synergy effect through executing related stories was not possible


Let the team know the content of the backlog

Let the team commit to the scope delivery

Allow the teams to identify and address dependencies before they become a problem

Allow the teams to create spike investigation before implementing a user story

Scale Agile planning to meet our needs


Create a huge common backlog for the section

1 day workshop where the teams

* Plan 4 sprints ahead with right level of details to be able to commit

* Plan 4 additional sprints at draft level to know what is coming next

* Identify dependencies to other teams and address them immediately

* Identify risk and mitigate them

The workshop:

SM facilitate the workshop (I facilitated the first workshop)

The teams and PO created several stories before the workshop to ensure that we had enough work to plan for.

We expect that the PO have created the stories before our next 4+4 planning workshop, could involve part of the teams, but less intensive than this time.


4+4 sprint planning:

Purpose: The best planning for the next 4+4 sprints can be achieved when the whole team is doing the planning together. A common commitment to the plan from the whole team is a precondition for success.

When: 4+4 Sprint planning is done in the last week – i.e. every 8th week.

Outcome from each team:

One sheet: Statement of 4+4 sprint objectives

One sheet: Dependencies

One sheet: impediments and risk

Two sheets: Planned experiences for 4+4 sprints

The outcome could look like this:

A closer look at the sprint sheet looks like this:

Each sprint sheet has the teams velocity and how much they load the current sprint, each story have the story point – the team does not load the sprint with more than it believe is possible to achieve.

Building Team’s Detailed Plan:

Estimate velocity for all sprints

* Use current velocity, if known, or ideal developer days if not (8 IDD per team member per sprint)

* Factor in team size, team changes, holidays, vacations

Identify backlog items

* Identify all stories to meet vision/objectives:

* * Experiences, Enablers, other objectives

Estimate stories in (modified) Fibonacci points (0,1,2,3,5,8,13,20,40)

Continuously – Identify and discuss interdependencies

Building Team’s Detailed Plan

Load stories on your sprints until you run out of capacity

Split any stories bigger than 8

Identify any hard dates

State, negotiate, gain agreement on sprint objectives for your team

Identify Dependencies and solve them

Identify impediments and risks and try to solve them or propose solutions/mitigation

Prepare to present your plan

Last: Have your sprint objectives ranked by business value – done by PO


Include maintenance allocation in your schedule

Factor in demo, integration meeting etc

Holidays, training events affect velocity etc.


Dependencies (like advanced widgets, other teams review of our code, Governance board etc).


* Teams DoD for high quality

* Story DoD for right implementation

* Testing – manual, automatic, documentation, …

Architecture – discussions, agreements etc.

Spikes – do we need to investigate something, prove of concept…

Refactoring – Touching code that we need to refactor?


Agree to objectives, rank by business value PO will rank during planning sessions

This has a clear advantage – the PO re-think the value for each story and the team get a good idea of how important the stories are – in case they need to change something in the sprint and the PO is not available. Values should be 1 to 10, the higher the more value to the customer.

Identifying Risks

Identify those issues that may affect your ability to meet your objectives

Identify potential items first

Address as many as you can during planning

Leave the remainder on your –

risk sheet for broader discussions

Risk handling

At the end of the workshop, we go through all the risks and try to “solve” them according the the description below….

Risks categorized:

Resolved – has been addressed; no longer a concern

Owned – someone has taken responsibility

Mitigated – team has plan to adjust as necessary

Accepted – nothing more can be done. If risk occurs, release may be compromised

Agile and stress

Agile in practice Posted on Mon, February 25, 2013 21:07:34

When we
started to work with Agile, we changed a lot more than we think about.

traditional way of working with water fall can more or less be described as

This is a
little exaggerated, but it gives a picture of a way of working where we
gradually build up the work load and the stress and then return to a more quiet
time etc.

does the same work look when it comes to Agile? If we are true to Agile, it
should look something like this:

When we
work with Agile, we have a constant delivery, and we should have a very high
quality when we deliver at each sprint. When we start on a new project, we
often have to deliver a couple of sprints, before we have something that we can
send to the customer, but we should constantly have a strong focus on the
quality, both technical and UX quality.

we constantly deliver, we have the risk of increasing the work load and stress
if we are not careful – I believe that it is very important that we are aware
of this risk and focus on getting the most out of our teams in a human way and
mitigate the risk for stress, i.e. I wrote
about avoiding task switching, we showed that it was possible to produce 70%
more work with less stress, it is important that we work smarter not necessarily

I have a
couple of teams right now – they have a challenge due to the time of the year,
i.e. there is a lot of illness ongoing, in Sweden we use to call this time
VABuary instead of February (VAB is the abbreviation we use when parents stay
home to take care of their sick kids); the challenge for the team is that they have had an average of 4 VAB days
in each sprint, so when the team calculate the amount of hours available in the
sprint, they should consider to reduce the time with
4 man-days, to avoid the extra stress that the team members feel when they have
VAB (they often feel that they are jeopardizing the teams sprint goal due to
that they have to take care of their sick kids).

Another way to mitigate stress is to give the team a better understanding of what the future will bring – We use to do something we call 4+4 planning – it is a way for the team to get a
good view of the coming 8 sprints work, I will describe this later in another
blog, but for now it is a way that the team plan 8 sprints ahead (4 with some
details, and the last 4 only roughly), identifying the dependencies and risks,
this also have the advantage to avoid too many annoying surprises etc., it also
makes it easier for the team to identify when to create spikes to handle coming
challenges – and another benefit is that if a team does not manager to finish
all stories in a sprint, they will have a spill over, this will impact the
coming sprints; due to the planning work, the team and the PO will find it easy
to identify the impact on the coming sprints.

believe that 4+4 planning is helping the team to get a better overview and this
will again help them to reduce the stress!

Change Management – improving output with 70%

Agile in practice Posted on Fri, December 28, 2012 07:41:16

Executive summary

* This story is taking place in Beijing November 2008.

* I was responsible for building up UI development and maintenance on Nokia’s S30 platform (low cost phones).

* We were struggling with the lack of skilled SW developers and big maintenance load from various projects.

* The developers were working overtime when they were getting close to a project deadline, to keep up with the number of issues.

* The issues was assigned to the developers, typically the developers had 10-30 issues assigned and was working on 4-6 at the same time, to be more effective.

* This had been the way of working for many years and the experience was that the developers were getting burned out.

* The department was able to handle the maintenance, but most of the time we did not have the extra resources to do any new development.

* We had started to use Scrum for new development in October 2008 with fantastic results, so we wanted to try the same concept with our maintenance, we was measuring the average number of issues that we fixed per week, so we was able to see if our new way of working was making a difference or not.

* We quickly realized that Maintenance and Scrum did not work well, however after adjusting the model a couple of times, we ended up with a model that was looking very much like Kanban (another Agile discipline) – described in details in the coming slides – the main idea was the each developer was only allowed to work on one issue at a time.

* The developers was no longer working over time and actually had a little extra time during their working hour (i.e. waiting for compilers etc.), we were however able to handle the maintenance load and even had extra time to start new development projects.

* Our first thought was that the number of issues had decreased and this would be the reason why we had the extra time, however when we looked at the number of issues that we fixed per week, we realized that we had increased the productivity with 70%!

* The reaction from the higher level management in Beijing was mistrust, they believed that we was delivering poor quality and that was the reason for the big increase – so we started to investigate if we had lower quality in the new way of working, we looked at the code and at the amount of “bounce back errors”, however the quality was still very high and at least not decreased.

* The consequence was that the section could start new development even in the phase when projects was about to close, we even had resources to help other sections when they had extra workload (they did not use Agile principles and was still working OT).

* We continued to work with this model, and 2 years after I left, I talked with the manager for the section about how things was going, and he told me that they was still measuring the average number of issues fixed per week, and from time to time, he saw that the number was dropping, he could then walk around among the developers and found that they had picked 3-4 issues to be more effective. After getting everyone to return the issues and only working on one, the productivity went up to the normal level.

* Imagine that we start to use this way of working, i.e. get management and development resources to understand the importance of not doing task switching in the daily work, imagine where we could use the extra time that we would gain…

The Kanban flow

* Issue arrive to “Kanban chief’s” inbox

◦ Kanban chief investigate that the issue has a good description, enough log-files etc. – i.e. that the issue is ready for the developer

◦ “Kanban chief” will prioritize the issue and put it on the teams wall.

◦ The “Kanban chief” will be responsible for the issue until a developer have selected it.

◦ We call the “Kanban chief” for the QA-function at Sony.

* The developer will select “one” issue from the wall of issues, if any issue is marked as a SS, then that issue have to be selected no matter the developers competence, but those who have the competence will have to help this person if needed, this also ensure that there is a knowledge sharing in the section – the developer will put himself as responsible for the issue.

* If a developer need additional information, the developer will request the additional information, write all known information about the issue in the error report, so others (or himself) could get faster up-to speed, put the issue back as “impediment” and assign the “Kanban chief” as responsible – the developer then select a new issue from the wall, like normal.

* When the “Kanban chief” receive the requested information for issues marked as impediment, he will move the issue back to the “Backlog” and it will be possible for a new developer to select it.

* When the developer have fixed the issue, he will test it and call for a review – when this is done, the issue will be send to pool for testing, in Beijing we had a special team sitting next to us who did the testing.

* When the issue has been delivered for test, the developer will select a new issue.

* We removed an unidentified time consumer – task switching, people (developers, project managers and people managers) did not see that this was causing delays in deliveries, actually most people felt that they were less effective after the new wow, because they had idle time – however statistic showed that we were 70% more effective due to the focused way of working.

* We used the extra capacity to do new development, this was causing people to be more engaged than when they only did maintenance.

* We started to rotate people – the rotation secured that everyone did maintenance from time to time and new development from time to time

Next »