AgileInPractice

AgileInPractice

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

Teams

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 organizing teams?

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 think!

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 organizing teams...

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 organizing team.

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 important.

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...



  • Comments(0)//agileblog.danskerne.se/#post24

Teams and consultants

ManagementPosted by Rune Hvalsøe Sat, August 03, 2013 22:51:18

Eric Ries once said: “If you don't know your customer – you don't know what quality means!”

I cannot agree more – it is so true!

I would 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:

“The 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.

There is 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 same needs.

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.

You can 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….



  • Comments(0)//agileblog.danskerne.se/#post23

Crazy Friday

ManagementPosted by Rune Hvalsøe Fri, August 02, 2013 22:30:38

I just 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!

It all 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) ;-)

I don’t 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.

This was 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.

They have 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!



  • Comments(0)//agileblog.danskerne.se/#post22

Talent!

Agile in practicePosted by Rune Hvalsøe Sat, July 13, 2013 15:01:32

I 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.

It 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 ;-)

I 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.

I 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!

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..." - 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.

I 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".

Now what does this have to do with Agile? Everything!

Agile 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.

I 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!

  • Comments(0)//agileblog.danskerne.se/#post21

Closing the loop

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...

  • Comments(0)//agileblog.danskerne.se/#post20

A challenge when working with Scrum

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:

  • 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... :-(

  • Comments(0)//agileblog.danskerne.se/#post19

4+4 planning

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.

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

Why:

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

What:

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

How:

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.

Agenda:

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

Considerations

Include maintenance allocation in your schedule

Factor in demo, integration meeting etc

Holidays, training events affect velocity etc.

Consider

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

DoD

* 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?

Etc.

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

  • Comments(0)//agileblog.danskerne.se/#post18

Agile and stress

Agile in practicePosted by Rune Hvalsøe Mon, February 25, 2013 21:07:34

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

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

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.

How 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.

When 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 more.

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.

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

  • Comments(0)//agileblog.danskerne.se/#post17
« PreviousNext »