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

PO presenting stories

Poker planningPosted by Rune Hvalsøe Thu, January 31, 2013 11:08:14

A common challenge when the PO present stories to the team…

Sometimes you happen to join a meeting with a PO who present “stories” to the team, the PO have not created Story DoD for all (or any) stories and do not know details about them.

The PO then asks the team, “How long time do you think it will take to implement this”?

The team will then try to get a better understanding of the story, what I often see is that the PO does not know enough “details” about the story – there are in principle 2 cases:

1. We have a real customer – who request things, the customer decide and can be consulted

2. PO is creating something new and will deliver this to potential customers – i.e. the case when we create features for mobile phones or SW for sale

We cannot expect the PO to know everything, but the PO is representing the customer, so the PO is responsible for driving the story DoD, there is a couple of ways to mitigate the challenges

1. The PO meet with the customer, bring along an architect (or senior team member) and discuss the details with the customer, the PO and architect have probably had a meeting before to discuss what they need request from the customer – after this, they can come to the team and ask them to estimate…

2. The PO meet with an interaction designer and architect (or senior team member) and identify what is unclear – together they can come a long way in describing the story DoD and be well prepared before they take time from the team…

There is a 3. Scenario – when you have a PO with high technical skills, they are sometimes able to collect and describe most of the story DoD themselves, without support from architects, interaction designers etc. – and they can often make decisions on the spot without consulting anyone.

It is a good idea to have a large post-it (I use super sticky from 3M, 200mmx149mm) with each story before you as a PO meet with either the team, the Architect or others – and then update the post-it with all the discussions you have, i.e. layout, screen size, how to verify etc. – any picture is a great help for the team, it makes things much easier to understand….

The most important thing is that the PO understands, that the PO is responsibile of driving the story DoD, it may not be the PO who write the DoD, but the PO is the voice of the customer, so the PO must secure that the story is created according to the customers’ expectations.

Experienced PO are usually better prepared, they know what the team want to know and prepare most of it up-front, to keep the meeting with the team at a minimum.

And when it comes to Story DoD – I sometimes get the response from the PO : “But creating story DoD takes way too much time” – I can only say that if the PO do not believe that writing a story DoD (max. ½ hour, often less for experienced PO) is worth the time, but the PO expect the team to use 10-20 hours to implement it – then there is probably something wrong in the way that the company prioritize the PO’s time.

And as always – just in time – i.e. the PO should secure that there is enough info for each story when the team need to estimate it (i.e. poker planning), it is usually not a good idea to use time to create stories with detailed DoD for coming 6 month – a backlog should contain the stories for the coming sprints (we use 16 weeks, 8 with story DoD and remaining 8 with fairly detailed stories) and epics (high level stories) for requirements after this.

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

Shifting to Agile – Shifting organization

Scaling AgilePosted by Rune Hvalsøe Sun, January 20, 2013 20:37:10

When you start to use Agile in an organization, you often forget to transform the organization, this is causing some practical problems afterwards.

I will here try to give my view on how an organization could transform from a traditional organization into an Agile organization, I believe that the principles I show are working, but there can be room for discussing how to implement it in practice.

Inspiration come from daily work in organizations trying to work Agile and from Steve Denning's books and his presentation "Making The Entire Organization Agile".

The traditional organization is top-down, with control functions, and a lot of roles who are expected to make decisions to generate more profit for the company and the share holders. Most of the organizations that I have seen is silo based, so a simplified chart like below is something that I have seen several times, it can be different depending on the company, but I guess you get the overall picture.

If we try to step back and look at what we have and what we want to achieve, and then try to build the organization with the "delight the customer" in focus.

Let us start with a really simple example.

Let us assume that the customer is a company who hire a group of freelancer

The Customer have requirements which the PO filter and prioritize to the team, the team implement the requirements and ask the customer to test it when a resonable amout of requirements have been implemented.

This example does not require any support organization to help the Team (including the PO).

If we keep the customer in focus and have the "delight the customer" as the vision for the company, but make it a company rather than a group of freelancer, we will still have the Team (including the PO) as the most important in the organization, it is the team who can deliver what makes the customer delighted.

The team could need help from

* Q&V with various things, among others to secure that the team have the right tools to test, release, communicate, developer tools etc.

* HR to secure that everyone get salary, get the oppotunity to develop through education, have coaches to secure the communication between all stakeholders, finance to handle the economical part of the company (sell, buy, tax etc).

* Marketing to secure that the products gets exposed if we have a company without direct contact to the customer like mobile companies (Sony, Samsung, Apple etc), help to communicate with customers, help to analyze and create customer requirements (customers does not always know what they want before they see it).

This will require a huge mindset change, both with the team and with the rest of the organization, i.e. the team(s) must learn to use the new support organizations and stay down to earth, the organizations must learn that they do not exist to maximize their own or the companies profit, but to help the team to delight the customer!

How will this work if we scale it to the size of companies with 5000++ employees?

Let's look at mobile companies like Nokia, Apple, Sony, Samsung etc – this is an area where I have a lot of knowledge, but I am sure that the exact same principle can be used in other industries.

Mobile companies produce phones (we focus on this, they have other "products"), each phone they produce has the purpose of delighting a group of customers, so they will have a number of teams who are responsible for the product, they will have multiple products, but we will only look at one, the others are individual-copies and will use the same support functions more or less.

When we have several teams, it is very important that each team know what the teams does, it is also important that there is a good description of the product vision and the customer profile.

The teams will need coaches to secure the communication and help them to become better at what they do and how they work.

The teams will work in a environment where they have several servers to keep control of the SW, HW developers need to have equipment etc, this means that the teams need someone to support their environment – this could be handled by Q&V.

You may ask yourself, what happend to all the managers in this organization? They have become enablers or coaches – there is still a need for someone to set the salary for the employees, we are probably not ready to follow the example from Semco where the employees are setting their own salary, so some system is needed to help in this area.

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

Coaching

LinksPosted by Rune Hvalsøe Sat, December 29, 2012 21:08:49

I have just read the articles at http://www.tuffledarskapstraning.se/bibliotek/ - all in Swedish - really good inspiration.

Makes me think of "When the best leader's work is done, the people say, 'We did it ourselves.'"

From http://blogs.hbr.org/goldsmith/2009/11/leadership_isnt_about_you.html I get the quote "Your team is more critical to the success of your project than you are." - which leads me back to Agile - "To succeed with Agile, Management's need for results must be greater than their need for control" quote from Israel Gat, formerly of BMC Software

And about engagement: http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=player_detailpage

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

Change Management - improving output with 70%

Agile in practicePosted by Rune Hvalsøe 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

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

Change Management

Agile in practicePosted by Rune Hvalsøe Fri, December 28, 2012 07:25:43

One important learning from my work with Agile is this :

"To succeed with Agile, Management's need for results must be greater than their need for control"

To me, Agile is all about improving the way we work.

In Europe we need to improve the way we work, we will never be able to continue the same way and compete with developing countries.

We need to combine existing ideas to improve how we work and we need to create new ideas.

I have been using several ideas over the last couple of years, i.e.

VSM (Value Stream Mapping) - to identify bottleneck and waste in our way of working.

5 Dysfunctions of a team – to improve team work, in Management teams, Scrum teams and any other team.

The 7 Habits of Highly Effective People – Focus your energy in “Important – Not Urgent” to improve your situation!

Pomodoro – focus your work and get things done!

Kanban – great for maintenance and other work that keep coming and which you cannot estimate

CoP (Community of Practice) - you must learn from your mistakes, but to become an expert you must learn from others.

It is important to adjust any ideas to the environment that you have without losing the idea and value… ;-)

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

Portfolio planning

Scaling AgilePosted by Rune Hvalsøe Wed, December 19, 2012 20:31:34

When I worked at Nokia, high level management decided to work according to Agile, a cross functional group was created to ensure that the changes needed for the organization was implemented. An external Agile coach was hired to help the change management process - Dean Leffingwell, this was probably one of the most important reasons why we managed to change the organization successfully (at least according to my understanding); Dean brought experience from other organizations and was a valuable coach to discuss the changes we did – however it was also important that we did it our way, and not only according to how it was done in other companies.

When you talk about working with Agile and Scrum, people think about the teams working in Sprint, but often forget that the entire organization need to change to get everything to work. There are many things involved in changing a big organization into Agile way of working, I will focus on Portfolio planning in this description.

When Nokia did portfolio planning, the steering committee looked at the visions and high level stories (epic’s) and prioritize it according to each other on the portfolio planning backlog. I will here try to describe the lifetime of an Epic and give my comments on what was good and where we could improve – now that I can be wise afterwards, please notice that I do not know details at portfolio planning level, but I have a fairly good understanding of what happens after portfolio planning, so I believe that my picture is fairly correct, at least good enough for an illustration…

When a new Epic was created, s short high-level description would be created together with a profile where cost, time and competence was estimated (very high level), this was very rough, but gave an idea of what it would require to implement the Epic.

The steering committee would receive a presentation of the Epic and decide if they believe that the company should invest in this or not – if the Epic is important enough, it will enter the backlog of the portfolio planning.

Now the really tricky part comes – priority – it is so simple when you say it, but I have never seen anyone who did not struggle with this, it is so easy to say yes and extremely difficult to say no – but we always have a limited number of resources and need to priority what we want to accomplish. The backlog with Epic’s have to be prioritized, normally a new Epic only have to be compared to the others to be prioritized, but at the end, it could mean that some of the old Epic’s on the backlog would not be implemented. The steering committee will not know details about resources available and cost of Epic’s, but they would have a rough overview, this overview was updated by the portfolio planner contact person, we can call him mister X, mister X was the interface to the different organizations that was implementing the Epic’s on the portfolio backlog. Figure 1 illustrate the flow:

Mr X and a planner from each organization was having regular meetings (I think that each organization was 100-250 people), the planner in each organization knew exactly how many resources they had, who was working on what (maintenance, Epic x etc.); when a new Epic arrived, the resources (based on the profile) was allocated (PO and teams), they would then make a better estimate and feedback to the steering committee – if there was not enough resources available, they would go through the Epic’s from the top and secure that the Epic’s with highest priority was the once that they were working on and inform the steering committee about the results, update Epic-profiles etc.

The important thing in this flow is that the resources follow the Epic!

The PO and the team execute the Epic, the PO is responsible for writing a DoD for the Epic and together with the team to create a release plan for the Epic, this will be communicated to the stakeholders – including the steering committee.

  • Comments(1)//agileblog.danskerne.se/#post11

Meet Kealey

LinksPosted by Rune Hvalsøe Sat, December 08, 2012 09:37:05

I was in a workshop with Tom Kealey yesterday - he is really fantastic at describing complicated things in a simple way!

His website have a lot of links (in the blog area) to his public presentations http://zerodegrees.nu/

  • Comments(1)//agileblog.danskerne.se/#post10

PO description by Kniberg

LinksPosted by Rune Hvalsøe Sat, December 08, 2012 09:09:10

I saw this link the other day: http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell

Another of Knibergs cool descriptions of the PO role and things that happens arround the PO.

A practical problem not described here, is that in some projects the customer and their wish is not know. If you have a customer who hired your company to do a specific thing, then the requirements will flow into the PO's backlog, but if you create something that you want to sell, i.e. a new program for some computer system (PC, mobile etc.) and you want to make this a fantastic product without telling the user about it first, then the requirements will not flow into the PO's backlog in the same way.

The PO need to have the vision about the product, but getting the flow and functionality right is difficult; there are probably several ways to get this right, but one logical way (when working with Agile) is the iterative way, discuss with the team and interaction designers and then do a test with potential customers to find out what works and what problems they see and repeat until you have something that you can launch.

What I often see is PO's who just hand out high level stories (sometimes called Epic stories) without driving the story description (including DoD) to a level where the team have enough information and do not secure that the customers are happy about the outcome.

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