Declan Whelan

Beyond basic calendar operations I want to be able to:

• synchronize an online calendar with my PC and iPhone (iPad and Mac Air to follow)
• manage difficult to coordinate meetings with multiple people
• allow others to easily schedule time with me

As a consultant, I want to avoid access to any shared calendars the client may have, because of the hassle setting it up and that pain the Exchange Server has caused me doing this in the past.

I have solved this by centralizing my schedule in Google calendar with the following:

• Google Calendar Sync (to sync Outlook with Google Calendar – not shown below)
• Google Sync (to sync my iPhone with Google calendar)
• Tungle.me enabling others to schedule time with me
• Doodle to setup up difficult to coordinate meetings with others

I have recently started paired agile coaching with Jason Cheong-Key-You. Jason suggested this ‘game’ for an Agile Acceptance Testing Workshop I was leading. He first experienced as an introduction to agile session with James Shore and Diana Larsen.

I have dubbed it ‘The Presentation Game’. It takes a minimum of 90 minutes – here’s how it works:

The presentation game

Set-Up
I did this myself and it would have worked better with two facilitators. If you have two, I suggest that you each support one team during estimating and planning and so on.

[10 minutes] Introduction
I suggest a quick ice-breaker followed by a description of the how the workshop will proceed. You will need to establish two teams. With a group that already knows each other you could skip the ice-breaker and use additional time for debrief. Have each team select someone to ‘pitch’ their session. Identifying this person early will allow them to construct a mental model of their pitch in advance.

[8] Create
Each team will create stories where each story is a topic to be covered. Instruct people to write one topic per index card. if you are doing this by yourself rotate around and answer any questions they may have about the session. If the opportunity arises, try to get participants to break-down big presentation topics into smaller ones.

I was doing this session focusing on acceptance testing so I asked the group to define their acceptance criteria on the back of the cards. This proved to
be a little problematic as I could not easily see them. If you decide to include acceptance criteria I suggest you get participants to write them on separate cards.

[8] Estimate
Before starting, I suggest handing out three index cards with large H, M, L on them and instruct attendees to do T-shirt sizing based on the *value* of the topic. This helps because we can be sure to estimate the higher priority topics first – in case time gets tight. Go to each group for four minutes and estimates their stories via points. Write the points on the card – I used a red marker so the estimate stood out. I also used a scale of 1 point per minute of presentation time. Be sure to act like a development team estimating: ask questions, clarify, negotiate, challenge, try to split the story etc.

[8] Select
Based on the estimates and your target velocity each team should select the stories that they want you to present.

[5] Pitch and Vote
Each team should then pitch their presentation to the entire group – timebox this to 2 minutes each. Then take a vote from all attendees as to which presentation they would prefer to hear. Be ready for a tie-breaker if you have an even number of attendees – e.g. flip a coin.

[5] Preparation
Review the cards and arrange them in a logical presentation order. If you have a co-facilitator I suggest creating a quick task board with “not started”, “in progress” and “done” columns. Tape each topic card and its acceptance criteria to the task board.

[30] Deliver
Move each topic card as you go. For people new to agile this will help reinforce the use of a story, acceptance criteria, “done” and so on. Remember to ask after each topic is presented if the acceptance criteria has been met. Have someone, either a co-facilitator, or a volunteer run a timer for you and let you know at regular intervals how much time is left.

[15] Debrief
I debriefed using a simple fishbowl and this has mixed results. This format works great if you have people that are comfortable enough to share openly.

My Take-Aways from This Format

• arrange for two facilitators – this was hard to facilitate alone
• excellent demo of courage – look to underscore this in debrief it it comes up
• excellent focus on delivering value – I kept stressing that I would would estimate any topic they came up but theior presentation would be more likely to succeed if it was aligned with what was most valuable to *everyone* there.
• I found it hard to present concisely on some topics. For instance, one topic I spoke on was “What is Agile?”. It made me realize that we should have short mini-presentations available to answer such questions. Perhaps lightning talks would be a good way to sharpen the saw on this!

At Agile 2010 I will be leading a session on building an learning culture on your agile team (Wednesday at 3:30 in Asia 3). I have done this session before but have reworked it significantly to add more interactive activities. I think it will be a lot of fun and … hopefully you will learn something!

I will also be giving away two book that have shaped my thinking on learning in an agile context:

I have recently started to use Moq for mocking and I really like it. The fluent interface and Lambda support makes it very easy and natural to use.

However, I quickly ran into a situation where I wanted to ensure that methods on a mock object were called in a particular order. I have provided a simpler example below where I want to check that BlogPresenter.Show() shows blogs in reverse chronological order:

public class Post
{
    public DateTime DateTime { get; set; }
}

public class BlogPresenter
{
    private readonly BlogView view;

    public BlogPresenter(BlogView view)
    {
        this.view = view;
    }

    public void Show(IEnumerable posts)
    {
        foreach (var post in posts.OrderByDescending(post => post.DateTime))
            view.ShowPost(post);
    }
}

public interface BlogView
{
    void ShowPost(Post post);
}

To check this I used a callback to increment a counter like this:

[Test]
public void Should_show_each_post_once_with_most_recent_first()
{
    var olderPost = new Post { DateTime = new DateTime(2010, 1, 1) };
    var newerPost = new Post { DateTime = new DateTime(2010, 1, 2) };
    var posts = new List { newerPost, olderPost };

    var mockView = new Mock();

    var viewOrder = 0;

    mockView.Setup(v => v.ShowPost(newerPost)).Callback(() => Assert.That(viewOrder++, Is.EqualTo(0)));
    mockView.Setup(v => v.ShowPost(olderPost)).Callback(() => Assert.That(viewOrder++, Is.EqualTo(1)));

    new BlogPresenter(mockView.Object).Show(posts);

    mockView.Verify(v => v.ShowPost(newerPost), Times.Once());
    mockView.Verify(v => v.ShowPost(olderPost), Times.Once());
}

This works code but is not very intentional. I wanted to express the intent the there is a required ordering of method calls. After searching around I found a nice code snippet from Max Guernsey, III that was promising. I thought I would push a little further to see if I could get something like this:

[Test]
public void Should_show_each_post_with_most_recent_first_using_sequences()
{
    var olderPost = new Post { DateTime = new DateTime(2010, 1, 1) };
    var newerPost = new Post { DateTime = new DateTime(2010, 1, 2) };
    var posts = new List { newerPost, olderPost };

    var mockView = new Mock();

    using (Sequence.Create())
    {
        mockView.Setup(v => v.ShowPost(newerPost)).InSequence();
        mockView.Setup(v => v.ShowPost(olderPost)).InSequence();

        new BlogPresenter(mockView.Object).Show(posts);
    }
}

So, I created Moq.Sequences and you download Moq.Sequences.dll from github. Simply, add Moq.Sequences.dll as a reference in your .Net project and add a using Moq.Sequences; in your test class. Moq.Sequences supports the following:

• checks order of method calls, property gets and property sets
• allows you to specify the number of times a call is made before the next one is expected
• allows intermixing of sequenced and non-sequenced expectations
• thread safe – each thread can have its own sequence

Sequences

Sequences are added using the Sequence static class and extension methods. You create a sequence by calling:

using (Sequence.Create())
{
    ...
}

Sequences that do not fully complete are detected when the sequence is disposed. So, all the setups and mock calls should be done within the lifetime of the sequence.

Steps

Within a sequence you set the expectations for ordering via an extension method InSequence<(). I call these steps. For example,

using (Sequence.Create())
{
    mock.Setup(_ => _.Method1()).InSequence();
    mock.Setup(_ => _.Method2()).InSequence();
    ...
}

This sets an expectation that Method1() will be called once followed by a single call to Method2. You can set more sophisticated expectations by using a Times parameter:

using (Sequence.Create())
{
    mock.Setup(_ => _.Method1()).InSequence(Times.AtMostOnce());
    mock.Setup(_ => _.Method2()).InSequence(Times.Between(1, 10, Range.Inclusive));
    ...
}

Steps can be created for method calls, property gets and property sets:

using (Sequence.Create())
{
    mock.Setup(_ => _.Method1()).InSequence(); // method call
    mock.SetupGet(_ => _.Property1).InSequence().Returns(0);  // property get
    mock.SetupSet(_ => _.Property2 = 0).InSequence(); // property set
    ...
}

Also, sequenced steps can be intermingled with non-sequenced expectations.

Loops

Loops are used when you want to check that as group of method calls are called in order several times. An example of this could be some resources which you expect to be opened, operated on and then closed, one after the other.

Loops are created via Sequence.Loop():

using (Sequence.Create())
{
    mock.Setup(_ => _.Method1()).InSequence();

    using (Sequence.Loop())
    {
        mock.Setup(_ => _.Method2()).InSequence();
        mock.Setup(_ => _.Method3()).InSequence();
    }
    ...
}

The above checks that Method1 is called by any number of calls to Method2 followed immediately by a call to Method3. You can constrain the number of times the loop can be executed by adding a Times parameter such as the following example where the combination of Method2 and Method3 should be called exactly twice:

using (Sequence.Create())
{
    mock.Setup(_ => _.Method1()).InSequence();

    using (Sequence.Loop(Times.Exactly(2)))
    {
        mock.Setup(_ => _.Method2()).InSequence();
        mock.Setup(_ => _.Method3()).InSequence();
    }
    ...
}

Wrap-Up

Moq.Sequences provides a simple, intentional way of checking that things are are done in a specific order. Feel free to check it out at github. I welcome any feedback!

Agile Coach Camp Canada

The first ever Agile Coach Camp in Canada is being held at the University of Waterloo on June 11-12, 2010.

Don’t miss your chance to join other Agile enthusiasts to share your experiences and learn in an open and relaxed setting.

Check us out online at www.agilecoachcampcanada.com, eh!

The ball point game by Boris Gloger is a great game for introducing Scrum to new agile teams. I have played and facilitated this game a few times and would like to share my notes. Many thanks to Boris for creating this game. Special thanks to Henrik Kniberg and Robyn Dymond for facilitating and sharing their ideas on the game at AYE 2009.

Rules

The point of this game is to pass as many balls as possible through every team member in 2 minutes. The team gets a point for each ball passed through every member of the team provided that the first person to touch that ball is also the last. There are 5 iterations. Before each iteration the team estimates how many they think they will pass. At the end of each iteration the actual number passed is recorded.

The rules are explained and the following should be written on a flip-chart:

• You are one big team
• Ball must have air-time
• No ball to your direct neighbour
• Start Point = End Point
• Iteration = 2 min
• In between = 1 min
• We play 5 iterations

Preparation

Create a flip chart with the “playbook” for the game:

• 2 min introduction
• 2 min for rules
• 2 min preparation time for first sprint
• Run 5 iterations:
  - Get an estimate from the team
  - 2 min iteration
  - 1 min team to plan improvements
• 10 minute debrief

Write the rules on a flip chart or white board.

Bring a box of balls – Boris recommends tennis balls. I bought 50 practice golf balls and use them.

Prepare a flip chart sheet or whiteboard to record the team results on each iteration:

Make sure there is an open space sufficient for the team to arrange themselves in a circle.

Make sure you have an open flip chart or whiteboard with markers to record the score and for debrief.

Facilitation

The Process

You will be asked things like can we “do such and such?”. When such questions arise, respond by pointing to the rules and saying “It’s your process”.

Notes

Ask the team and record the key changes the team made on each iteration in the ‘Notes’ column of the playbook. This will help in the debrief as the team is able to look back and see the changes they tried and the results they achieved.

Timing

Often their will be balls over the place. I have found it better to only start the 1 minute retrospective timing after all the balls have been picked up so that the team can fully focus on improvements for the next round.

Variations

Add a Manager

I learned this variation from Robyn Dymond. After introducing the game and rules, state that you will be the manager and will feed the balls to the team. The intent is to add a process step that is unnecessary and wasteful. If they ask you to stop doing this simply agree. In fact, do anything, beyond passing balls, to help them if they ask. Do this before the first iteration if you are going to do this. Some teams will never question your ‘help’ and then when debriefing you can ask how they felt about having work pushed at them. You can then ask why they did not challenge your help and they will often say that you are an authority figure. This may open the door to discussing challenging authority and asking managers for help.

Set a Constraint

Jeff Patton told me how we sometimes uses painters tape to tape the hands of one of the participants. And often this constraint, can lead to an aha moment where the team realizes that if they cup their hands they can pass more balls. This could lead to a discussion of how constraints can sometimes breed innovation.

Set a Stretch Goal

Usually after 3 iterations you should see some significant improvement and they may feel that they have reached an optimum level. At this time say something like “I performed this exercise with another team that achieved 200 points”. Most often, the team will have a significant improvement and you can debrief on how the team can achieve significant improvements when they set aside what they feel is their limit.

Set an Impossible Goal in a Bonus Round

Tom Reynolds in his notes on the game describes a variation suggested to him by Angela Druckman. At the end a bonus round is introduced with an impossible target – significantly larger than the team’s best iteration. You may want to say something like “The world record for this is 350. Let’s see if you can beat this record – I think you can!”. I suggest not doing this with the Stretch Goal as it may result in confusion.

Card Throwing

Henrik Kniberg suggested that when the game is over he sometimes asks someone to throw a business card as far as they can. He suggests having doing it a few times and putting pressure on them by saying things like “Come on, I know you can do better than that!”. The perhaps not so obvious step is to scrunch the card up and throw it. However, I did have someone how was very adept at flicking cards and was able to flick a card more than 15 metres! The point is that even just after the learning from the ball point game we may still have trouble stepping back and looking at the process and seeing improvements. Most people, will initially just try to throw the card harder! Becoming a learning team takes time and practice!

Debrief Points

What Happened?

Ask with an open question and allow people to share their experiences. I then guide the remainder of the debrief around the remaining points depending on what I noticed, team interest, and time.

What Iteration Felt the Best?

Ask what made that one feel best? Why?

Natural Velocity

Look for an iteration where there was a dramatic improvement due to a reorganization. Ask whether this improvement was due to working faster or harder. Point out that every system has a natural velocity and that to significantly improve the system requires changing the process.

Deming – Scrum ‘Inspect and Adapt’

Draw parallels between the game, Deming and SCRUM:

You may also want to show that this parallels the Scientific Method.

Theory of Constraints

Ask if there is a bottleneck in the system and if so where it was. Ask how they identified and whether they attempted to address it. Ask if it would be helpful to improve efficiency at a point other than the bottleneck.

Experiments Sometimes Fail

Often a team will try something that will not result in an improvement and performance may actually drop. Point out that this is ok and expected. Sometimes we try a good idea and it does not work out. We don’t have to get it right every time and we learn more from our failures.

Waste

If you acted as the manager and this was not challenged then ask why they did not challenge this. Point out that is was not a rule and that we must be careful to challenge constraints and identify waste if we are to achieve maximum performance. Negotiate with your management and customers – we all win!

Pull Systems

Most teams will put in place a system where the balls are not passed until the downstream person is ready – i.e. a pull system. When balls are pushed it usually results in dropped balls and lack of flow. Point out how a pull system maximizes flow and increases performance.

Rhythm and Flow

Do you experience a rhythm? Point out that flow will happen if:

• the challenge is doable
• people are not disturbed during the iteration
• the work has meaning

You may want to point out that agile development has multiple levels of rhythm: daily standups, sprints, releases.

The Power of the Retrospective

Ask them if they had 6 minutes (total planning time) to plan for a single 2 minute run do they think they would have achieved the same results?

The Power of Face to Face Communications

Could the same improvements have been achieved via phone or email? Would it have helped to document the process?

Heroes

Would it have helped if someone on the team was much better at this game than the rest of the team?

Whole Team and Leadership

You may notice some good suggestions were made but not followed. Ask the person how that felt. Is there a natural leadership model on the team? Is there a “right” leadership model? A post on Babble burble banter balderdash suggests asking the following questions:

1. Who had all the ideas?
2. What roles did you all take?
3. When something went wrong what did you do?

Stretch Goal

If you introduce a stretch goal after the third iteration ask how that felt and the impact it had. Often, teams will perform better knowing that improvements are possible. And improvements are always possible!

Impossible Goal

According to Kane Mar setting an impossible goal often results in decreased performance.

How Does this Apply to Us?

Close the game by ask the team if there is anything they can take back into their development team. Record on a flipchart.

I was thrilled to present at Agile 2009 on building a learning culture on agile teams. This post is a short summary of the presentation. You can view the presentation on slideshare. The image below is a mindmap of the presentation:

The main point is that in order to embrace change:

We should strive not only to deliver value today but simultaneously increase our capacity to deliver value tomorrow.

There are so many dimensions we can learn: our products, our customers, our domain, new technologies and so on in order to embrace change and deliver value. Now, embracing change is supported by learning and so we can consider change models for insights.  Even though the change model from Virginia Satir is modeled on dysfunctional families I believe the applicability to agile teams is sound. I often find the limiting factors in building high performance agile teams are the team members mental models and the team’s ability to work together effectively.


To build our capacity to embrace change and achieve ever higher levels of performance we need to build learning teams. This is one of the five disciplines that Peter Senge discusses in his classic text The Fifth Discipline. I find two main challenges that the five disciplines present to agile teams. First, much of the book applies to larger organizations than agile teams and second the book is short on practical tools to help learning teams. The supporting text,  The Fifth Discipline Fieldbook and other tools primarily from Agile Retrospectives and Fearless Change provide activities and simulations that you can use with agile teams.

Now, I want to bridge the game from the principles of team learning to the practices by way of an agile learning map. I built a learning map based on on the Chinese symbol for learning. It provides four key areas that are necessary for building a safe learning culture:

1. Intentional - Proactively plan and retrospect on learning activities
2. Incremental - Focus on small incremental. progressive learning
3. Infrastructure - Build a workspace structure that supports effective learning
4. Individual Safety – Make sure people feel safe to learn

The presentation provides a more detailed map of activities and patterns you can use in each of the above areas.

Building the teams learning muscle is key to long-term agile success!

I had a great experience pairing with Patrick Wilson-Welsh at Programming with the Stars at Agile 2009 in Chicago. We were ousted in the first round but we had a blast. And I learned a few things along the way:

You should make your tests expressive

We were deducted points for not including the word “should” in our tests. I do strive for this but find that this “rule”, as with any rule, can be too restrictive. Liz Keough suggests that the word “should” should be the first word in your test method name. Getting tired of the word “should” yet?

I strive for expressive test method names that clearly state a design criteria for the class under test. So my preference is to make the test method name a full sentence. And of course I try to include the word “should” in it. Using this approach I find it hard to craft a test name beginning with the word “should” that reads like an assertion rather than a question. So, I rarely start my tests with the word “should”. Also, I break from production code styling and use underscores so that test method names are as readable as possible:

As Brian Marick would say, “an example would be good right about now”. So, if we have a test like this:

Then a refactoring like shown below provides a more expressive test:

Don’t write new conditional production logic without a new failing test

Jim Newkirk deducted a point because we added an ‘if’ statement without a new failing test. This was new to me although it makes perfect sense and I appreciate the insight from Jim.

So, if you are about to write new conditional production code without a new failing test … stop! If you are currently trying to make an existing test pass then try to get it to pass without a conditional statement. Otherwise, update the test so that the new conditional logic is not required. Once you get green with this you should then write the failing test that will require the conditional logic you were about to add. Now, you can add the conditional logic sufficient to get the test green.

You can’t write much code in 3.5 minutes

Patrick and I were test-driving a method that would return the integer that was closest to zero in an input array. We knew from writing the initial code and refactoring it what a clean code impleme