Staying competitive in today’s economy means companies must deliver the right products to market faster and with higher quality than ever before. Adopting agile development methods is a significant way organizations are doing this. Making the switch to test-first programming [...]]]> This is the first of a few Guest posts from Version One.

Staying competitive in today’s economy means companies must deliver the right products to market faster and with higher quality than ever before. Adopting agile development methods is a significant way organizations are doing this. Making the switch to test-first programming and agile testing challenges traditional notions of software engineering best practices.

Myth 1: Everyone on an agile team tests therefore dedicated testing resources aren’t needed.

Fact: Teams interested in delivering a quality product realize that the same product knowledge, preparation, discipline and skills used in traditional QA should be leveraged when transitioning to agile.

Myth 2: Testers are second class citizens on an agile team.

Fact: Testers are valuable members of an agile team and often add a unique perspective in terms of identifying potential roadblocks and dependencies early in the process.

Myth 3: Important testing activities that aren’t product-related won’t get done.

Fact: Additional testing activities, such as performance and regression testing, are addressed through test-oriented stories, which are estimated, planned and tracked just like product-related stories.

Learn more about Test-First programming, and how to transition from traditional testing to agile testing.

1. Supplies

1. Setup

We all have tendency to hang on to things, perhaps it is a way of working, or a behaviour, or a judgement of one of our co-workers… in order to move forward as a team, we may well have to let go [...]]]> {“Nothing can drag you down if you’re not holding onto it. LET GO – Anthony Robbins“}

We all have tendency to hang on to things, perhaps it is a way of working, or a behaviour, or a judgement of one of our co-workers… in order to move forward as a team, we may well have to let go of strongly held belief’s…what can you do as a Scrum Master to show the way, what can you let go of ?

What’s one thing you can support your team in letting go of ?

As scrum masters and project managers, One of our main goals, is to support the team to become the best team possible. Are the team doing the same old thing, day in day out ? Are you running [...]]]>  {“The Hawthorne Effect. Loosely stated, it says that people perform better when they’re trying something new“}

As scrum masters and project managers, One of our main goals, is to support the team to become the best team possible. Are the team doing the same old thing, day in day out ? Are you running your retrospectives in the same fashion at the end of every sprint?

This week’s challenge:

What’s one thing you can support your team in doing differently in the next sprint?

I have been reading a discussion on Jordan Bortz’s site, around the Lack of Scrum Success stories becoming a concern… in principal I agree with the title, there are far to few success stories…but that is not the failing of scrum or agile in my view.

I firmly believe that its [...]]]>

I have been reading a discussion on Jordan Bortz’s site, around the Lack of Scrum Success stories becoming a concern… in principal I agree with the title, there are far to few success stories…but that is not the failing of scrum or agile in my view.

I firmly believe that its always about people never about process…Scrum is a process in that regards, so that leaves people at the crux of the problem Jordan is writing about.

He is , in my view, missing out something, for the sake of this conversation, lets say there are 2 crude stages,

1. The adoption of scrum

2. The ongoing use of scrum

I would challenge him that he is actually referring to the lack of success of scrum adoption.

I have come across and heard many stories of companies wanting to buy scrum, to do scrum without being agile, its like wanting the results of diet, without the work by taking a magic pill…there are no magic pill’s.

You can put all the agile / scrum ceremonies (process) in place and not get the outcomes your after, your culture (people) needs to change also, and this is the challenging part.

Whats your experience ?

What is the goal here ? for me, the goal is not to measure agility, or to become agile, but to become predictable. [...]]]> There is no getting away from it, nor should we want to, organizations want to be able to measure teams, their output, performance, yield, what ever you want to call it…

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 [...]]]> Just back from the UK Agile Cxoaches Gathering 2011, an Open Space conference, in bletchley park, there were around 30 or 40 passionate men and women who had an interest in discussing coaching teams and organizations, who are working in or towards some form of agile methodology.

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!

I recently attended a Limited WIP society meetup at Skills matter, where Karl Scotland and John Stevenson ran the Ball flow game as a way to introduce Kanban to people. The game originated as a way to introduce Scrum and I had the opportunity to [...]]]>

I recently attended a Limited WIP society meetup at Skills matter, where Karl Scotland and John Stevenson ran the Ball flow game as a way to introduce Kanban to people. The game originated as a way to introduce Scrum and I had the opportunity to run such a session this week, however I decided to tweak it a bit to enable various scenarios to be experienced by the participants and to support specific conversations.

Here is the setup:

1.    Initial Presentation

Team makes an initial presentation of the scrum framework to the room. Purpose: to give the facilitator an idea of where they are on their Journey of learning scrum / agile, it also acts an ice breaker. It’s important to stress that it’s really not about getting it right, the value is in the conversations that are generated.

2.    Present the rules of the game

• You are one big team
• Each person must touch each ball
• Each ball must have air-time
• No passing the ball to your direct neighbour
• The Start Person = End Person
• Each Iteration = 2 min
• Each Retrospective  = 1 min*
• Each Sprint Planning  = 1 min*

(* having 1 minute for the retrospective and 1 minute for sprint planning, did not really work, it was difficult to keep the team to that 2 minutes, one variant might be to setup an automatic timer for the whole meeting so the team has to self manage their time)

3.    Present the roles

If you have all the roles in the room , then great, otherwise the facilitator can play the different or absent roles

• Team
• Product Owner
• Scrum Master
• Manager

The purpose of having the roles, is to introduce them, and for the later sprints in which we introduce some typical challenges, if your only going to run sprints 1-5, then you can drop this out from your agenda.

4.    Play the game ( sprints 1-5)

Give the team a count down to their first sprint planning session (1 minute) where they need to come back with their commitment in terms of number of balls delivered.

5.    Play the game – sprint 6

Role: Product Owner
Scenario: Last minute changes
Have a card in an envelope, and give it to the person playing the Product Owner, the card should say something like

“just before the sprint starts, demand only blue balls”

Impact:

The teams tend to do it, but will aim to groom the backlog themselves, rather than pushing back on the Product Owner to groom the backlog, or to let the Product Owner know of the possible impact the late change will have.

6.    Play the game – sprint 7

Role: Product Owner
Scenario: Changes in the sprint
Before the sprint, give envelope #7  to the person playing the Product Owner, the card should say something like

“once the sprint has started, demand a new feature (give orange ball) is delivered”

Impact:

The orange ball tends to go round the system once or twice before someone in the team throws it out, some even question it straight away but still take it into the system. The team’s focus is so much on the end goal that they don’t recognise the threat, there is a great opportunity here to emphasise the importance of the Scrum master in protecting the team from outside disruptions in the sprint.

7.    Play the game – sprint 8

Role: Manager
Scenario: Changes to the team
If you have a large group (more than 10, otherwise I would skip this it) you can try this one, before the sprint, give envelope #8 to the person playing the Manger, the card should say something like

“split the team into 2, as you recognise that some are better than others, so form the Best team and the Other team, try and make the better team and odd number and the other team even”

Impact:

In very large groups over 20, teams find a huge increase in productivity as there is a smaller communication circle and its easier to co-ordinate updates and changes. Discussions here around ideal team size. If one team now has an even number, they tend to try and replicate the previous system and will need an extra pass of the ball at the end to not break the passing to your neighbour rule. This tends to have a large impact on productivity, and good conversations around outside decisions and their impacts.

8.    Play the game – sprint 9

Role:  Product Owner
Scenario: Changes to the type of work
Before the sprint, give envelope #9 to the person playing the Product Owner, the card should say something like

“Introduce 4 others types of balls (the really really heavy ones), demand they get delivered with a normal ball in between”

Impact:

By now the team will be really used to the standard ball , its weight, how to throw it, how to receive it. By Introducing the 4 new types of balls, ideally really heavy or large balls, it will introduce variability to the system.  If the Product Owner plays out the role of unaccommodating Product Owner, “well they are all just balls”, it can lead to useful conversations around a lack of awareness of the other persons domain, IE not all balls are the same.

9.    Play the game – sprint 10

Role:  Facilitator / Product Owner
Scenario: Pushing the team for more , faster.
Before the sprint, give envelope #10 to the person playing the Product Owner, the card should say something like

“you know the team can do more, (if your the facilitator) say that by now, most teams are doing 3 times what their current best is, what can they do about it ? “

Impact:

Some teams down tools, as they feel its a push too far, which can be a great conversation point. Some teams try the, ” lets keep it the same but go really fast” and generally end up dropping more balls and not getting near their previous best.  All great discussions around why, what happened, , what would you do next time ?

On the night, [...]]]> Last Thursday I was speaking at the Agile Evangelist meet up at skills matter. It is a new group of people focused on all things agile in London. I ran a version of the “35 Game”, (see an earlier post for more details on that)

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 [...]]]> I came across the 35 technique for gathering input from a team on Lyssa Adkins blog, and have been wanting to try it for a while, and I ran it yesterday, with some changes, which worked brilliantly.

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.