ManagementPosted by Rune Hvalsøe Mon, August 19, 2013 18:32:09
What is the ideal world,
not an easy question and I am sure that I cannot give an answer that
makes everyone happy, but from my perspective, when I look at SW
development, the ideal world is when you have a self organizing
teams, teams who have a great understanding of what the customer want
them to implement, which is not easy either...
The challenge we often
face - as I see it is this:
1: How does the team
understand what the customer want?
2: How do we get self
1. Understand the customer
Let's start with having a
team who understand the customer and what they want, I recently read
the biography of Steven Jobs by Walter Isaacson (fantastic book btw),
and it is pretty clear that the customer does not know what they
want, especially not if it is something really new.
Most teams that I have
worked with, have an interaction designer in the team to help them,
that does however not secure that the team create solutions that the
customer want, even if the interaction designer know what the
customer want, the team will most likely not interpret the design in
a way that is completely in line with how the customer want it –
and this is where Scrum works really well (and most other Agile
disciplines), we deliver often and we are very flexible, so we can
test our software with the customers frequently – and make sure
that you have the entire team with you when you let the customer (or
someone who represent the customer, i.e. in the mobile industry, it
close to impossible to reach all customers), the benefit from having
the team in the customer test (and not only the interaction designer,
which I sometimes see) is that the team interpret the design and in
most teams they also add stories to the backlog, so it is super
important that they have a good understanding of how the customer
There are a lot more the
team can do to be better at understanding the customer, it is all
about interaction with the customer, the simple test that I talk
about above is mostly a UX test to secure that we remove the worst
usability issues, however this does not give the understanding of how
the user think and use the software, it is often isolated to a
limited test, another way to improve the teams understanding of the
customer is to let the customer play around with your software and
software from competitors while the team observe, we are planing a
trip to the local café to get ideas and increase our understanding,
we will buy coffee to those who are willing to let us observe how
they use the software … ;-)
2. Self organizing teams
How do you create self
organizing teams – well it is contradictory to build self
But what you can do is to
create the framework and help the team to succeed... My experience
with self organizing teams is that they are fantastic at
collaboration, they are empowered, all decisions must be owned by the
team, they care about each other and trust each other, the team is
static, though it does work if one is leaving for parent leave (or
similar) and return, but it does not work if you split the team and
build other teams with the members from the first team.
One of the things that I
have learned about successful teams is that they like each other or
at least respect each other very much, so I personally always talk
with all potential members of a team before creating the team, it is
my experience that you cannot have 2 or more in the group who are not
trusting or respecting each other, they might be able to work
together, but you will never get a self organizing team, you will at
most get a highly skilled group, which most managers are happy to
get, but it is most likely never going to be a high performing self
One thing that has proven
very successful in helping teams to become great teams is
appreciations – giving appreciations to each other continuously is
very important in building great relations, it is important that you
don't save the appreciations to a retrospective or temperature
reading (feedback sessions).
Another very important
characteristic with a great team is their ability to listen to each
other, they must be able to listen both to professional and personal
issues and not judge, allow others to make mistakes is important, I
have been working with many teams and I have never seen a great team
who did not get involved somehow outside work, it does not mean that
they have to meet and socialize, but that they can talk about part of
their life is important in building the relationship that is so
Can great self organizing
teams build and maintain without external influence? Yes, I believe
that they can, I think that most of us have seen it happen outside
work, i.e. in groups of friends, specially if people are free to make
the groups and have a common goal – but at work, this can become
slightly tricky and I believe that management can help a lot to
create the framework and to coach the team and they can also destroy
the team if they don't pay attention, when focus is to maximize the
short term profit, rather than building long lasting teams...
ManagementPosted by Rune Hvalsøe Sat, August 03, 2013 22:51:18
once said: “If you don't know your customer – you don't know what quality
agree more – it is so true!
like to say the following:
“If you don’t
know your team and don’t treat them with respect – you will never get a high
performing team”, and I would like to add another quote from Eric:
company's greatest asset is its people, you need to care about them.” and extend
it slightly to include all your in-house consultants, I know that the majority
of managers that I have met, they see consultants as external, but most of the
time we use consultants as an alternative to in-house head counts (HC) due to
the way that our organization works. I have 3 consultants in my section, they
work in my teams as a full team member, they contribute to the teams work like
any other member with the same enthusiasm and they are equally eager to be
treated like a human being as our in-house team members.
nothing like respect and openness to your team and team members, and this goes
for every team member, the only reason why we have consultants rather than
in-house HC is because the way our organization works, i.e. we have a budget
for HC and one for consultants. The only way I treat consultants different is
that I don’t have salary talk, and the company does not (normally) pay the
consultants additional education, but except from this, I believe that I treat
them exactly like any other HC, I have 1-1 with them every 2. week, I set continuously
targets for them, I want them to feel like they are part of the team in any way
that I can.
It is super
important that we empower the team, that we respect them and encourage
collaboration, there is no way that we can get high performing teams if we don’t
believe in them, HC or consultants, they are all human and have exactly the
Why do we
want teams anyway?
I read this the other day http://www.agileconnection.com/article/empowering-agile-teams "....when
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..."
And I would
like to add that the team spirit and energy you get from a high performing team
is so much more than the sum of the individual’s energy, you can sense the
energy floating from a high performing team, it is a truly exiting experience
to be near high performing and self-organizing teams.
only get this kind of teams when you empower them, and that means all members of
the team, it means that you listen to them, it means that you allow them to
make mistakes, it means that they have fun together and that they are equal and
treated equal; the team members is not equal if you treat them different….
ManagementPosted by Rune Hvalsøe Fri, August 02, 2013 22:30:38
finished a crazy Friday – fantastic to be 0x30 and still learn new and great
stuff – learning and getting inspiration in making what you love to do is what
makes life worth living!
started Wednesday late at work, Michael Rozenberg (http://michaelrozenberg.se/) and I was sitting a quiet day at work and he told me that he just
asked Mattias Forsberg from ComHem to meet with him in Stockholm and exchange
ideas of working with Agile in a management team and Agile ideas in general –
Michael had seen http://www.youtube.com/watch?v=RZe6snBN-aI (Swedish - sorry). Michael asked me if I
wanted to join him (distance Lund-Stockholm is about 600 km) in his Crazy
Friday trip – and I was thinking about it for an hour before I gave him a call
and got the details, it was a crazy idea, but also fantastic!
When I came
home, I asked my wife if she wanted to join me on a long weekend in Stockholm,
after all we might just use the opportunity to have a nice weekend in “Gamla
Stan”! We booked a hotel and had the kids to take care of our zoo at home (3
dogs, 4 cats, 3 rats, 2 hamsters) and off we went Thursday after work to a nice
hotel in central Stockholm.
It was perfect
weather Friday morning, so we walked to “Gamla Stan” where I continued to my
meeting with Mattias while my wife was catching up on her 2. Dan (she has black
belt in shopping and is going for 2. Dan) ;-)
know what I had expected from the beginning, but it was highly productive and inspiring
to meet with Mattias and learn about how they use Agile in their organization
and the challenges they have had and how they have been thinking when they
execute it in practice. Mattias took us on a walk around in the building and
showed us how they use “puls-tavla” to get an overview of current projects and
secure the communication in the organization – we discussed how they work with
Agile and teams and how we work with Agile at Sony.
not the first time that Mattias had guests from other organizations, however it
was the first (and definitely not the last) time that I tried this, he use these
kind of meetings to get inspiration from others and to evaluate how he and his
organization is doing.
implemented Agile as top-down, where we are doing a bottom-up, we did Agile
top-down when I worked for Nokia and both have it’s strength and both happen to
struggle with things, some things are the same and some are different.
Most of our
discussions was about how to build Agile into the organization, i.e. how to
secure the communication between the stakeholders, how to create strategies for
the company with buy in from the development teams and what thoughts we have
when we implement ideas and how to use Agile in your management team!
It was an
overall amazing experience to visit another company and have this discussion
and I can only recommend it to other managers – I hope that I will get the
opportunity to do this twice a year, it gives a lot of inspiration, a lot of
energy, build a really good network and help you to analyze how you work in
your own organization!
Agile in practicePosted by Rune Hvalsøe 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!
Agile in practicePosted by Rune Hvalsøe Wed, June 12, 2013 19:51:51
I did a presentation in Malmö at foocafe.org 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...
Agile in practicePosted by Rune Hvalsøe 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:
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... :-(
Agile in practicePosted by Rune Hvalsøe 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.
- 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
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.
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
At the end of the workshop, we go through all the risks and try to "solve" them according the the description below....
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 in practicePosted by Rune Hvalsøe Mon, February 25, 2013 21:07:34
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
does the same work look when it comes to Agile? If we are true to Agile, it
should look something like this:
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 http://agileblog.danskerne.se/#post13
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!