Archive for the ‘Agile’ Category.

The Presentation Game

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!

Agile 2010 Session on Learning

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:

Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers) by Andy Hunt

Moq Sequences

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!

Building a Learning Culture on Agile Teams

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:

Building a Learning Culture Mindmap

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.

Source: http://www.stevenmsmith.com/my-articles/article/the-satir-change-model.html

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.





Learning map

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!

What I Learned Programming With the Stars

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:

  1. @Test
  2. public void handleZero() {
  3.     assertEquals(0, Closest.closestToZero(new int[] {0,2,4}));
  4. }

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

  1. @Test
  2. public void zero_should_be_closer_to_zero_than_any_other_integer() {
  3.     assertEquals(0, Closest.closestToZero(new int[] {0,2,4}));
  4. }

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 implementation could look like. And, as if often the case, the refactored code looked obvious in hindsight. We decided that given the time restrictions we would write our initial code towards the refactored code as it reflected an intentional programming approach. Bad idea, we were deducted points for thinking too far ahead and then not having any significant refactoring.

So, if you are in this position, write some really, really simple code and allow time for simple refactoring … and let intentional programming code emerge from the refactoring.

Don’t go first

Just sayin’ …

Hanging out with agile journeymen is mental adrenalin

Having an opportunity to talk code with people like Liz Keough, Jim Newkirk, Brian Marick and some top-notch agile coders was a real buzz. Hanging out with Patrick Wilson-Welsh and the cool Pillar dudes was also a blast. If you get a chance sign-up for this at Agile 2010!

Many thanks to Joshua Kerievsky, Jeff Nielsen and Industrial Logic for sponsoring this event.

Parallel Tracks for Agile and User Experience

Earlier this year I participated on a panel hosted by the IxDA Toronto Group. There were some great insights into getting Agile and User Experience (UX) practices working together. In this post I just want to mention one of them.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2006, ACM.

Parallel Tracks

Consider having a parallel track for UX work such as prototyping that gathers information for upcoming iterations. You can also use this track to evaluate the output from the previous development sprint.

Desirée Sy from Autodesk (formerly Alias) describes this eloquently in an article she wrote for the Journal of Usability Studies, “Adapting Usability Investigations for Agile User-centered Design”. This paper is intended for a User Experience professional looking to adopt Agile practices. The above image is from Desirée’s paper (see notes below).

Lynn Miller, also from Autodesk, pointed to paper she wrote for  the Agile 2005 conference, “Case Study of Customer Input For a Successful Product”. This paper is intended for Agile teams looking to benefit from User Centered Design practices. It also discusses the parallel track concept.


Image above is from The Journal of Usability Studies, Vol. 2, Issue 3, May 2007, pp. 118 and reuse is subject to the following:

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2006, ACM.

Berteig Consulting Agile Clinic

Berteig Consulting has recently launched the Agile Clinic (TM) for companies to diagnose their Agile implementation and provide customized remedies. The goals of the one day clinic are to help organizations:

  • fine tune its agile practices and become effective and more efficient
  • become hyper-effective by overcoming some of your hardest challenges
  • determine which agile practices will help you the most
  • find existing barriers in the current situation, offer solutions for your specific needs
  • examine your teams, your processes and your organization to find opportunities for improvement

This is an interesting approach as it leverages the expertise of external independent agile gurus without the expense of an agile coaching engagement. Companies could schedule periodic clinics and would provide regular “agile checkups” in a cost-effective way.

Of course, the challenge here will be for the clinic coaches to garner sufficient context prior to the clinics to make sure that their diagnoses and remedies are tuned to the situation at hand. The model includes some case analysis prior to the clinic so the success will in part depend on how well the situation is communicated and appreciated by the coaches prior to the clinic.

I am very interested to see if this model works both from a client perspective and from a coaches perspective.

Adopting or Adapting Agility

I often come across people who wonder how they can adopt agile practices. This is a fair question and I often spend some time explaining that agility is not really an important goal. Agility is just a means to an end and that end is to deliver better business value. I like this goal because it is can never be fully realized – there are always ways to get better.

I recently listened to a webinar by ThoughtWorks on agile readiness assessment and I am reading Agile Adoption Patterns: A Roadmxap to Organizational Success, by Amr Elssamadisy, © 2009 Pearson Education Inc.. Both of these are excellent resources and I decided to write a white paper that combines agile assessment with adoption and adaption. I included adaption because some agile teams reach a plateau and need an approach that pushes them through to the next level.

Adopting or adapting agile practices requires a strategy that aligns your team’s agile goals with your overall business goals.

Please feel free to download the white paper and let me know what you think!

Agile Product Design and Development Workshop with Jeff Patton

I am really looking forward to helping Jeff deliver his workshop on Agile Product Design and Development on September 10th in Kitchener.

Jeff brings a fresh perspective on agile development focusing more on product definition and user experience; areas that are not usually well covered in agile books and training materials. He advocates passionately for end users and weaves insightful user experience practices with agile practices to arrive at a solid approach to agile product design and development.

If you would like to find out more about the workshop or register for it please check out the event website at: http://agileproductdesign.eventbrite.com.

If you can’t make the workshop but would like to hear Jeff, he will also be providing a 90 talk entitled Embrace Uncertainty:Strategies for an on-time delivery in an uncertain world which you can register for at the Communitech Events web site.

Truthfulness on Software Teams

A short while back I invited Mishkin Berteig to come to Waterloo to talk about agility. I was looking for something that would have a broad appeal to developers, testers and so on but would also have depth. Mishkin drew a full house and gave a great presentation on delivering successful agile projects. He covered the agile bases with a good overview of agile values and practices. Things got deeper and more interesting when he talked about truth. I know he is sincere about this because of the Scrum Master training I received from him. Mishkin’s email signature is:

“Truthfulness is the foundation of all human virtues” – Baha’u’llah

Mishkin pointed out that agile methods rely on people speaking the truth and acting with integrity. I thought this was very insightful since most agilists focus on either technical aspects of agility such as TDD, refactoring or they focus on team and leadership issues. But what Mishkin is talking about is a deep personal honesty to see things how they really are and to act accordingly.

You see, I have from time to time in my career told little white lies to my peers and managers. And I almost always got away with it. For example, once when I was developing a financial application I made what I thought was a good design decision but really struggled to get it to work. I did not want to appear as if I had made a mistake. I basically lead everyone to believe all was well and meanwhile I worked insane hours to get it all working. I was letting pride get in my way and was lying to cover up a bad technical decision. And this lack of truthfulness prevented me from seeking help. I resented the long hours I had to put in and I was unhappy. It was unfair of me to hide the reality from my peers and managers. I suspect I am not alone.

Now, I think it should be obvious that on an agile team you simply could not get away with such behavior for any length of time. There is collective code ownership, daily stand-ups, task and story tracking, sustainable pace; all of which make the whole process much more transparent. So, on the one hand I agree with Mishkin that agile methods rely on people speaking and acting truthfully. But in practice agile methods make it hard to say anything but the truth!

But we are devious creatures and so I would like to leave you with some questions to ponder:

Developer with halo

  • Are you honestly expressing your doubts and concerns in retrospectives?
  • If something is bothering you with another member of the team do you act in a direct but respectful way to resolve it?
  • Are you able to freely admit when someone has a better idea or design than yours?
  • Are you willing to admit when you make a mistake?
  • Do you say the same things about someone when you are face-to-face with them to do you say something different behind their back?

If you can’t honestly answer yes to the above questions then maybe you’re not as honest as you should be. Start by being honest with yourself. Pick one apsect of your behavior that that is not as truthful as you would like and strive to be more truthful.

Truthfulness really is the foundation of all human virtues … and agile teams.