What is the goal here ? for me, the goal is not to measure agility, or to become agile, but to become predictable. If we become predictable at  delivering quality products, it’s a game changer for the organization.

So for me there are 5 key areas to measure: Predictability:

1. Planned Commitment – is our commitment stable ?, the goal should not be about driving this up, but about stable predictable and sustainable commitment,  there is the law of diminishing returns at play here if we try and bleed it dry.
2. Variability
   1. Delivered Commitment – are we doing what we say were going to do ?
   2. Ability to commit – where is the variability coming from in the system that prevents us from hitting our commitments, sometimes it is internal to the team, a lot of the time its external dependencies
   3. Ability to respond – how good are we at removing variability from the system to reduce variability
3. Quality
1. Defect count – how many defects are we letting through at the sprint & release level, how many do we miss
2. Technical debt – what corners have we cut today that we will pay for later ?
4. Customers
   1. Value Delivered at the Epic level – we should be able to derive a % trend of the value delivered by epic based on the number of stories that are truly delivered (word of caution here, value is very hard to predict, and there is growing part of the market who feel ROI is really ROI = one guess / another guess , and if we agree with that, then we must see that it’s a false metric to use, there is a move to cost of delay based tracking, i.e. what is the cost of me NOT doing this work, and there are 4 risk profiles….
      i.      Expedite – I am incurring a loss right now
      ii.     Deadline – I will incur a cost at a fixed date In the future
      iii.    Normal – I will incur an increasing incremental cost , – this may become an expedite over time
      iv.     Slow Burn – I do not know if  I will or will not incur a cost
   2. Value materialized – did the value we predicted actually materialize when we went to market
5. Employees
1. How happy are our staff ? – Things like Staff turnover have to be part of the full picture of the cost of a project. Its proven that happier staff are more productive. If we deliver one product but it costs us the teams happiness or the very team itself, is that a good price to pay ?

Along with this, there are some key questions we need to ask ourselves:

1. Are we as an organization going to respond to the data and take the required steps to protect the status quo (if need be) or make the required changes ?
2. Are we as an organization setup to be able to answer these questions ?
3. Do we value the exercise of planning that is required to enable our teams to provide these stats ?
4. Do we as an organization promise to not use this data to measure our people, the art of measurement should be a diagnostic tool, otherwise you risk people gaming the data and thus making the data useless for what it was intended and we end up shooting ourselves.

Some of us met up on the Friday evening to agree the agenda, hour long slots across 6 or so rooms. The first session I went to was hosted by Pierluigi Pugliese , on how Virginia Satirs -  Family therapist techniques can be used in agile coaching. The method identifies 4 key roles that people default to when under pressure  / stress (read Management encouragement J ) and can be used by a coach as a signal that something has changed for that member of the team. Thkey message is that when were in these modes (yes us coaches fall into them also) we are reducing our options when were in them. For more information on the roles you can find Pierluigi’s presentation on slideshare .

After this session, I applied the rule of two feet a little more, here are some key take aways…

If you do not have a learning culture, your inviting a blaming culture into your company…how true of all relationships we have, both professional and at home..after all while I work in Technology organisations, I do not consider myself to work in the technology business, I work in the people business…

Stuck on prioritizing over 2 stories, flip a coin and pick one, if your happy stay, if your unhappy pick the other one… a nice simple technique.

Benjamin Mitchell  – Using Kanban to aid the facilitation of a meeting…Initial backlog can be pre populated, but then invite the attendees to order the backlog and agree what amount of time they want to give to each topic, and agree what is “done” for that topic.  Really like the collaborative nature of this approach.

Had to run for the 16:30 train back to London, so I missed the retrospective, so looking forward to the outputs from that, I hear were looking to move to the cadence to every 6 months…bring it on!

On the night, the question that we asked was, what are key factors for companies to consider when adopting agile. There was lots of challenges created in writing the question this way, some intentional, some not.

In game learnings:

One in particular that keeps on recurring, seems to be that people are afraid to ask questions when encourage to proceed, rather than say, hold on, you’re asking me to do something that I don’t understand, people keep their heads down and get on with it,  it takes a few rounds of the game before the confusion reaches a breaking point for someone and they “shout” to get clarity.

At the start of the game, people were asked to write 1 idea per card, however with the plurality of the words “factors” people wrote many. Takeaway here is people pay more attention to what they read then hear.

When asked to “point” up the cards (i.e. distribute 7 points across both cards) some people wrote 7 bullet points for the idea, rather than award the cards a score out of the 7 points available. Takeaway here is that not all words mean the same to different people.

Game Outputs:
34 points – Improve the existing workflow and measure progress
23 points – TDD – improved quality
21 points – Real customer feedback
19 points – Reliability (unit testing, user involvement)
19 points -  support work starting with imperfect information
18 points – flexibility around changes
18 points – reduce the distance to the product owner
17 points – get small – easier to manage, smaller requirements, smaller teams
14 points – greater visibility, with reduced upfront admin
14 points – decision making, understanding the process
12 points – move to a Flow system
12 points – Co location
12 points – early visible value

So what were the key learning’s ?
There really is no wrong way to run this game, there are so many learning points that come up, in fact, the output on the cards are almost secondary to the in game learning’s that take place.

The same talk will take place on the 31st March, why not come and join in ?

Purpose:

Used to quickly gather input or feedback from a team, found it especially useful for team with communication issues

Materials:

Flip Chart(pre-written agenda, and timing) , Markers (ideally the same ones for each person, same color), Cards, Stopwatch

Step 1:

Introduction -

One word, (another one from Lyssa’s book), I asked each person around the table to say one word to reflect how they are feeling, it also breaks the ice, ensures everyone speaks, which aids participation.

Overview, I informed the team that there would be 2 agendas to choose from, and they would get to choose, initially they wanted to stay rooted to their seats, but I find getting people up out of their chairs and active really increases the participation.

Create 2 topics, one with a positive twist, one with a negative twist, this will help you as the facilitator understand the “mood” of the team. I used

1. What will this great team look like in 1 year & What are the steps we can take to get there

2. What are the current issues ? & what steps can we take to fix them

It was a really interesting data point to see the split between each of the options..to protect the innocent, I wont go into details.

Step 2:

Timings -

With the agenda chosen, review the timings for the session. We had 1 hour, 1 agenda, 2 topics, broken down as follows:

Introduction – One word , Agenda Choice – 5 min

Session 1 – Introduction – 5 minutes

Session 1 – 5*2 min + 10min

Session 2 – Introduction – 5 minutes

Session 2 – 5*2 min + 10min

Wrap up – 5 min

Step 3:

Session 1 introduction and execution

A) The name of the game is 35, each person gets a card, and a pen.

B) You have chosen Agenda 2, there will be 2 sessions, following the same format : what are the current issues (session 1) , What steps can we take to fix them (session 2)

C) Write the most important issue for you on your card

D) Check in when they are all finished

E) Turn the cards face down and swap all the cards

F) Take a card, and find a partner (we had uneven numbers to there was one triad)

G) You now have 2 minutes to discuss the 2 cards, and you have to divide up 7 points between the cards (write the points on the back), no half points. (we had to adjust the 3 person group to 11 points)

H) after the 2 minutes, change the person your talking to and repeat 4 more times.

I) Each card has now been scored out of 35 (7 points * 5 times), please total them up, and write on the total on the face of the card.

J) At the end, the facilitator counts down from 35, participants raise their hand when their card matches the number the facilitator is saying.

K) Key learnings and improvments

L) Second session

Observations:

I wanted the team to experience some of their issues, not jsut write about them, so this approach is different from Lyssa’s approach. I did not give the teams the opportunity to explain the cards at step D. This enabled the team to experience a really valuable lesson, that we make so many assumptions on what things mean (get clarity from your product owner before you commit). It was round 3 , before any one stopped to ask a question to clarify what was on the card (its important that everyone stops when a question is asked, so they all learn, but that so that it also causes disruption). You will most like find the first question opens the floodgates. The disruptions also caused a over run in the timing (we missed the sprint goal) ,

There was also a lot of confusion around the change over (step H) , which led to wasted time, people were swaping the cards and also the person they were talking to, a great example of teams filling in for mis-understandings.

At the end of the first session, we had a quick inspect and adapt cycle, where I asked how they could improve on the efficeny of the session. Straight away they agreed to quickly explain each of the cards, and to remove any duplicates. I riased the point that in the explaination, what was a potenial duplicate by the words, may not be by its meaning. They also agreed to move just the person and not swap the cards each time. On this point, after round 3 again, one participant was concerened that he was juding his own card too much so raise the question could we swap, in asking the question, most of the team agreed, and they adjusted the process (mid-sprint). For the second session, I also informed them I would not be making any input apart from time keeping, 1 minute increments. This was a good learning opportunity for self organisation.

I found that with the tweaks, that we gathered some great insights to the teams concerns and ideas for resolution, but also for the team to really experience some of the issues that they were suffering from.

Offsites are dead.

Long live volunteer work.

Yesterday rather than spend the day in a gray hotel room, we spent the day painting, lifting, digging, dragging, and delivering value.

We were working at the Battersea adventure playground, we were there to paint the bouncy castle enclosure, sort out the timber yard, and rip up the flooring on a huge castle play area, that over the years had become unsafe and was preventing it from being used by the kids.

We split up into 3 teams, one for each area, I was working with Team B, in the timber yard.

Why was this the perfect agile project :

1. We were a self organized cross functional team – no manager, some capable of lifting skills, some on raking skills, some on organization, some cutting, some pulling, but together complete.
2. We had great management – they hired us, then got out of our way. They gave us real and genuine appreciative feedback. We were volunteers, and they knew it, and appreciated the time we were giving and energy we put into it. Mary Poppendeick has been speaking about this for a while…its an approach more companies should look at. We were intrinsically motivated, the strongest kind, and the management style supported that. The gave us the constraints of the system (health and safety) and then let us get on with it.
3. A clear vision and a dedicated product owner – each team had a rep from the park to support us. He had a clear objective, clear out the area, clean it up, then put all the stuff back in a more usable setup.
4. We had a deadline and the scope was flexible – The kids start to use the part from 3:30 so we had to have the park safe again by that time, however some of the tasks were more important than others, and it was clear what had to be done over what would have been nice to have done.
5. The stories were INVEST’d -
   • I – Independent – each task was separate from the others, but together delivered value
   • N – Negotiable – the goal was clear, but the how, when, exact solution was decided just in time
   • V – Valuable – everything we did added value to the park, and it was a value that we could all see
   • E – Estimable – well this was one we did not need to do, given the time constraints it was better to just get on with it
   • S – Small – we focused on tasks that took 20-40 minutes each so we got to experience frequent wins.
   • T – Testable – we checked in with the Product owner frequently to check our approach, any changes that were needed, were done on the spot
6. Easy Impediment resolution – we encountered certain impediments during the day, such as lack of trolleys to move the rubbish to the skip, so we compromised and stacked it outside to be taken to the skip later, the decision was fast, and we got on with the rest of the work.
7. A great team – each and everyone of us dug in, and kept at it. The Product owner also dug in when needed, and that really helped with removing the “them and us” barriers, not that there were any.
8. Value delivered – we achieved more than was expected, and beyond that, we became a team, a real team. We got to work on something together and support each other.

All in ,  the pain I am feeling today is well worth it.

My key takeaways were,

• Kanban can fix problems, but not straight away
• The board will show you what your problems are, you can introduce changes and see if it improves.
• Do what helps, not hinders.

I wanted to capture the steps that John went through in the class, so this is my take in what John covered and his facilitation approach.

Facilitation & Preparation

There was really good preparation, there was a visual representation of a dummy company to stimulate conversation, there was a retrospective board, and a meeting kanban board to visualise the agenda.

Here is a sample dummy company diagram , similar to the one that was used.

A.c.m.e company

This is a designed to represent a complex scenario, (feel free to drop me some comments to update it).

Lets create your board

If your going to do this exercise with a team, here are some suggested steps to take:

1. Identify the business goals – Key for the product manager or owner to get his/her vision across.
2. Create a shared product mission- to get the team on board, a useful tool is to create a product box. For the supplies,  you can pick them up at staples along with some pens and stickers. Get the team to break up into groups of four to six (this works best with cross-functional participation). The team creates their vision of what the product will look like, with the box, decorating the front and the back, a product name, a logo, a strap line,  some key bullet points to sell it, perhaps a user guide or user reviews on the back.
3. Define the resources – How many people are available in each stage of the system ?
4. Make the board -  you will need, pens (big ones are better, people write less and bigger ), tape and a big wall. Its important to note, there is no wrong board , there is no right number of stages. You can always add more or remove a stage if they are not working for you. Some guidance would be: to add some stages if your not seeing progress on a frequent basis, and if your updating the board to much, it might be time to simplify the board. The great thing about kanban, is that the trigger points , frequency and the time spent updating, are unique to you and your team, you get to define them.
   You can add swim lanes to signify groups, features or perhaps releases.
5. Next value stream mapping – we did not get the opportunity to go into to much detail, but the quick version is identify how long an item of work takes, and how long that item of work stays in a stage. for more information check out the limited WIP Society.
6. Review the flow -  Getting flow establish is a key point. You ideally want a nice balanced flow, aligned to your WIP limits. This is not a one time activity, you will need to set your WIP, and review to see if there is flow, or any slack or bottlenecks, it may take some tweaking and time to get there. One of the benefits of flow is that if you can manage to get the requirements to be similarly sized within reason, you no longer need estimation workshops, as your predictability will come from the throughput….we do X number of items per time slice. It is an advanced technique and will require a good sell to the business, depending on your agile attitude within the company.
7. Identify the bottlenecks – Now that we have the system in front of you, have a go at identifying the bottlenecks. Does the work look evenly balanced between each stage given the numbers of resources available in each stage ?
8. Get feedback, fast- Kaizen, continuous improvements. Have some brainstorming sessions to identify possible solutions. A good technique is the “yes,and” technique, that comes from improvisation. The premise is that if we say yes,and that ideas will flow more freely. You might find it useful to ask one person to scribe the session, and then let the rest do the talking.

Some discussion points during the session:

Estimation
For me it depends what you want your developers to spend time on. If we can get the requirements or stories into the same sized groups, ie small medium and large, then we can track the throughput, for example, 5 smalls a week, or 3 mediums. This is not to say you cant use story points, and if your teams are comfortable doing that type of estimation, then there are probably bigger issues to solve.

Standups
Based in the conversations during the session, people found that standups got shorter, and in some cases stopped, and in most cases only really focused on discussing blocking issues. This is due to the board being updated JIT, so if you want to know the current state of things, look at the board. This is dependent on the team being more disciplined then in scrum.

Team reps
One of the other points made was about managing dependencies with other teams, eg what happens if you need team 2 to finish a story or fix an issues to enable you to proceed. In this case the team might nominate a representative to attend other team stand ups on behalf of the team and then report back to the team.

Bugs and defects
I like the strategy John came up with. If it’s a quick thing to fix, call it a bug. If it’s a big lump of time, call it a defect. Bugs should be fixed asap, the QA should have a chat with the dev and the dev should ideally fix it there and then. Given the limited wip, the dev will still have context. If its a defect, stick it on the backlog with the other work.

All in all, it was a great session, I look forward to more of his talks.

that is all.

and

then on the front

step 1

step 2

step 3

then on the back

thats it.

as the meerkat says…simples.