If you’re doing any kind of agile software development, you’re probably having some form of daily stand-up. In my experience most of the daily stand-ups out there are, quite frankly, pretty uninspiring things. A lot of meetings are spent mechanically reporting status to a project manager or discussing details of interest to only a few.

Like all practices, you need to constantly keep in mind the underlying principles and values behind the daily stand-up to keep it from deteriorating. Here are a few things to consider so that you don’t end up with just another meeting that people attend just because they have to.

Keep the Goal in Mind

The purpose of the daily stand-up is to give the team a good sense of how it’s doing on the commitment it made for the current iteration. Is someone stuck somewhere? Are things taking longer than we expected? Do we need to drop things to be able to deliver a coherent product increment?

This implies an obvious prerequisite – you need to have a goal for the iteration and a commitment to reach it. That goal is set at the iteration planning meeting. A commitment to reach it is created by giving the team responsibility to decide how many user stories they can implement, no one else.

It’s for the Team

It’s the team’s job to keep track of how they’re doing on their commitment. A daily stand-up that is run by a few persons where a major part of the team members shows up to passively attend is of limited use. Meetings that consists of one way communication from the project manager to the team, or from the team to the project manager, do not help create an environment where the team actively owns and cares for it’s project.

In a working stand-up, the team members address each other, reminding themselves of what’s currently on the agenda, and everyone is participating to the best of their ability.

If you are in a lead position in the team, either formally or informally, consider taking a step back and see what happens.

Discuss Elsewhere

The daily stand-up is not for solving problems. It’s about sharing information. If someone thinks he or she has input on a problem reported by another team member, the stand-up is the time to make the others aware of that and schedule a discussion afterwards. Anyone who has input may join.

If you allow too much discussion during the stand-up, there’s a risk that these take up most of the meeting. Chances are that some has nothing to add and resort to passively await the end. We don’t want to waste the time of the team members, so keep discussions to a minimum.

One tool that might help you get a more organized stand-up is to use a token. This a small physical item that is passed between the team members during the meeting. The person currently holding the token is the one that’s currently allowed to speak.

Come Prepared

Daily stand-ups are intended to be short and effective. If people don’t come prepared, time will be wasted when members try to remember what happened since last time. Make sure that you think through what you want to bring up on the next meeting. What you have accomplished and how much work is left. Having done that you can focus on what is being said by the other team members and get something out of the stand-up. If you focus on what to say when the token comes your way, you will miss what the others have to say.

Accomplishments, Not Activities

Focus on sharing what you accomplished since the last stand-up rather than reporting what you have been working on. For one thing, talking about accomplishments made provides a more positive attitude than just providing information on what parts of the system was worked on.

When the rest of the team hear about these micro-increments it has a tendency to trigger new activities. “Now that we can do X, I might actually begin doing those performance tests that I have been putting off for far too long.”

Make Commitments

Have team members bring up what they plan to have accomplished at the next stand-up. This way everyone makes a commitment to the rest of the team. The team can then compare the commitments they’ve made since last time to what was actually accomplished. That way they’re at a better position to find if there’s any problems or opportunities that needs to be addressed.

If members mechanically bring up what they worked on since last time instead, the team risks missing if there is anything that could potentially hinder their progress.

Bring up Impediments

In my experience, developers can take a lot without complaining. I’ve seen developers sigh and pull their hair while making changes to 60 files just to add a seemingly trivial thing to the code base. Still, at the next stand-up, they don’t report any problems.

If we don’t bring up problems, we will never be in a position to fix them. Hidden problems will affect quality, velocity, and our chances to reach our commitments in general. So we need to breed a culture where it’s expected of everyone to constructively bring up impediments before they get out of hand.

Conclusion

Daily stand-ups is a great tool for keeping a team in sync. When the stand-up works well everybody leaves it with a good sense of what they’re focus for the day is, what the others are working on, and how that connects to the team’s goal. Everybody should leave that meeting invigorated and ready to get going.

In the complex environment that is software development, you will always need to make adjustments to your plan. The daily stand-up is one of the best tools for this.

So, remember why you are there!

It’s official. I am now part of Blueplane. Blueplane is a consulting firm that specializes in helping organizations become more efficient by applying what we’ve learnt about agile software development over the years. We help teams by coaching them on how to use sound engineering practices, find better ways to run projects, and start communicating more efficiently.

I’m in this together with Andrés Taylor, Chris Hedgate, and Marcus Widerberg. I know I will learn a lot from those guys. They’re very sharp, they have loads of experience, and they’re just plain fun to be around.

If you’re situated in southern Sweden, don’t hesitate to contact us if you think your organization could use a vitamin injection.

Anchoring and adjustment is a psychological heuristic that influences the way people intuitively assess probabilities. According to this heuristic, people start with an implicitly suggested reference point (the “anchor”) and make adjustments to it to reach their estimate.

– Wikipedia

The team managing the project portfolio in a large enterprise need to come up with a rough estimate for when projects can start and what their duration might be. The master plan for all projects in the portfolio may span more than a years worth of work. This is ok. Everybody usually understand that these are extremely rough estimates that are needed to get some understanding of what type of resources are needed when and so on. No harm no foul.

When a team is assembled to work on one of those projects they are usually asked to come up with a new release plan. A new estimate of the duration of the project. However, when doing that the team tend to, unintentionally, steer towards the initial rough estimate in the project portfolio. Even if that estimate, if viewed objectively, is way off. This is anchoring. A seed has been planted in the minds of the team members that can be quite hard to get rid of.

A team is having a sprint/iteration planning meeting where the team looks at the product backlog to determine how many of the most prioritized items they can commit to. The product owner or project manager says in passing: “I think we should be able to get at least these four items into the iteration, but it is you who decide”. This is anchoring. Once the number four is introduced into the meeting that will act as an anchor. It will make it hard for the team to commit to just one item or even twenty items now that the number four is readily in their minds.

It is really important to be aware of when anchoring comes into play. Both when you are anchored by someone else and when you are about to provide the anchor your self.

An excellent example of a practice that addresses anchoring is planning poker. When not using it there will usually be one or two members that are always quick to come up with an estimate for the task at hand. It will be hard for the rest of the team members to come up with something radically different once the initial anchor is set. With planning poker everybody selects a card with an estimate on it and then show it to each other at the same time. This way you can enter the discussion without being anchored. This will hopefully lead to better decision making.

Developers reach deadlines faster if they skip TDD in the same way that skydivers reach the ground faster if they skip parachutes.

This is how we collaborate to create the product backlog in my current project. Having a set of stories that will make up the backbone of the project, the product owner is given 1000 points to distribute between the stories. The most important story gets the highest number of points. The second most important story gets the next highest number, and so on. The total number of points used may vary depending on how many stories there are. The product owner disregards complexity or dependencies to other projects. Only business value is considered.

With this as input we have the beginning of a product backlog, a list of stories for the project sorted according to importance to the product owner.

The next thing we need is estimates for the stories and a check to see if there are any dependencies that may alter the order of the stories in the product backlog. We do this by putting up a big piece of paper on a wall (actually a lot of sheets taped together) and then draw a y-axis and an x-axis. We label the y-axis “complexity” and the x-axis “importance”.

The complexity-axis is then divided into 4 sections marked 13+, 8, 5, and 3-. These sections match the number of story points used for most of the stories on our project. The story points denote the relative complexity of a story compared to the others.

We then take the story with the highest importance ranking, put that on a post-it note, and as a team we estimate the relative complexity of that story. Here planning poker is a good idea to try. The card for the story is then placed to the far right on the planning sheet and placed in the section of the complexity-axis that matches the number of points given to the story. We continue to do so with the second highest importance ranking and so on, moving farther and farther to the left on the diagram. The result looks something like this:

This diagram is a valuable tool in creating a good product backlog.

• It provides a quick way to estimate a large number of stories. Having no more than four levels of complexity is a constant reminder that we don’t need to get into too much details. When the discussion starts to drag on, just ask yourself whether the answer will move the post-it up or down one level on the complexity axis. A lot of the time the answer is no. Time to move on to the next item.
• It visualizes the relative complexity of the stories in a way that is very helpful when discussing how complex a story is compared to others.
• It provides hints on possible changes of the order in which to develop stories – a less important story with lower complexity might be preferable to start with than a story with higher importance and a higher complexity estimate.

I haven’t been as active writing on this forum as I hoped I’d be. A large part of the reason for this is that I have prioritized other things than writing when I have time away from work. But another important part has been the problem to come up with things meaningful enough to write about. I have dismissed a lot of topics that I have thought to be too obvious to write about. The other day I started to think that perhaps I was wrong.

I’ve introduced sprints in my current project. A sprint runs for a fixed amount of time (in our case two weeks). During that time the team delivers an increment of functionality. The sprint starts with a sprint planning meeting. A big part of this meeting is that the team decides for itself how much of the highest priority functionality will be delivered at the end of the sprint. This is natural as it is the team that is supposed to do the job. The members are the ones who know what it takes. They are best suited to make the decisions. Well, at least I thought that was obvious.

One of the managers in the organization took me aside one day and asked me with a concerned look how I would make sure that the team took on enough work. If the leads of the project don’t push the team to take on more things to do, how can we get them to work fast enough?

I firmly believe that all teams will do its very best at all times. With a team of highly skilled, well trained, and motivated people, why would you need someone to push them to take on more work? On the contrary, most teams seem to over commit in the beginning, wanting to take on more work than they are capable of.

We ask a lot of our developers nowadays. They are not only supposed to just make the code work. They’re supposed to write unit tests, write integration tests, refactor the code, communicate with product owners, communicate with testers, communicate with other developers, and make sure that their changes don’t break anyone else’s code.

What do you get when you push those developers to squeeze some more work in so that we can make the project deadline? Most of the stuff above will be skipped and we will be back to trying to just making it work. In the short term it will look like we’re moving faster, but the lack of quality measurements will sooner or later come back to haunt us. Additions and changes will become harder and harder. Adding tests will be harder and harder. Meeting deadlines will be harder and harder. Skipping anything but just writing code will look more and more tempting.

I thought this was obvious. Isn’t it?

I find using points an excellent tool to estimate and track the progress of a project. There are advantages with using points, such as separating the estimation of size from the estimation of time, and that it comes quite naturally to estimate the relative size of one story to another. I find that the process of estimation goes much smoother, once you get the hang of it, than the more traditional approach. You steer clear of questions about padding the estimates. Who is going to implement what? And the general fear developers have of estimates becoming promises.

Visually tracking the progress of the project using a burn chart is a simple way to report how many of the features we can accomplish per week. From this we can extrapolate an estimate of when we’re done. This estimate will become more and more accurate as we complete iterations as we can use the velocity of old iterations to predict the future.

The downside with using the abstract concept of points is that it is often hard to sell the idea to an organization that for very valid reasons wants to deal with time. When I’ve started talking about using an abstract term like points for estimation, I’ve received my fair share of looks that can only be interpreted as “You don’t make any sense at all, man!”

So what do you do when you as a project team want to use story points and burn-charts while other parts of the organization want information to be reported in MS Project or similar?

I think the following more general advice applies:

• Recognize the request as valid and work towards giving project stakeholders what they need in order to make the best decisions possible.
• At the same time, be open about what you as a team need in order to make the best job possible. If the team think using points will improve the way they estimate and track progress, calmly present that to the organization and be prepared to answer the question why you need to work that way, what problem does that solve that other approaches don’t?
• Be prepared to compromise. The goal here is to find a way for the whole organization to work better. Not have the developers work better at the expense of some other part of organization, right?

As an example, here is how we are currently solving that we have different approaches to track progress. At the start of the project we had a release planning session where we divided the project into a handful of internal releases. Within each release, we grouped features that work on similar functionality into themes that were given a name. Each release contained somewhere around five themes. Each of the themes were added as an activity to an MS Project plan and was given an estimate like “this will take 2 developers 1 week”. The team then used points when estimating individual features or stories, which gave us a number of points for each individual theme as well as for the project as we knew it then.

We are currently tracking progress using the number of points we can achieve per week. This gives us a velocity of about 8 points per week. From the velocity we can extrapolate how much time is left of each theme and the project as a whole. This makes it easy enough to translate this into information that can be used to update the MS Project plan.

Our progress can now be viewed as either a burn-up chart or a critical chain fever chart. Having access to both types of information suite the needs of different parts of the organization. Better yet, we now have a concrete example to use as a base for, as objectively as possible, discussing ways to track progress. We can compare the different ways of presenting information and discuss possible deviations in what they report, and together come up with a better approach for next time.

Discusses the need for a clear cut exit criteria for a planned feature and how a test is one way to go.

In the project I am currently involved in, we release software once a month. We have currently released the first increment of work, and one of the activities we start after a release like this is to start some more formal tests of the software, performed by the project’s test lead and test engineers.

These tests discovered defects that really shouldn’t have made it in to the release at all. These defects revealed that we missed to implement some details in the requested functions for the release; things like missing to display a column in a list view etc. These were things that were clearly described in the user stories and in the tests performed by the testers. All the info needed was there. How is it then that we missed to implement them?

We did our best to avoid these misses within the project. All team members; software developers, leads, testers, and documenters sit together all the times. We have also made sure to involve all team members in all aspects of the project from day one so that we all have good knowledge about why we’re doing the project, how we’re designing and developing the software, and when things are ready for release. Besides delivering software once a month we also work in one week iterations, making sure to deliver a new chunk of functionality every week that can be demonstrated to team members and project stakeholders. We practice TDD to get a good adaptable design and to find all glitches before we hand stuff over to test and project stakeholders.

With all this in place the formal testing done by the testers should just be a formality, right? Well, the tests were quite successful. We found very few defects in the software delivered by the project; there were no major crashes or completely misunderstood requirements. We were pretty close to the target altogether. But what made us fail to implement some parts of the requirements?

The problem was that it was up to each pair of developers to decide when they were done with a feature. From time to time a pair would proclaim a feature done in the stand-up meeting one day only to report that they “performed some cleanup” of the same feature at the next meeting. It is so rewarding to be able to go up to the project whiteboard and be able to move a post-it from the “in progress” field to the “done” field. It is quite addictive really. Seeing the burn chart move closer to the finish line gives you a warm sense of accomplishment that sometimes make you miss a “minor detail or two” as you are so eager to step up to the whiteboard and get your reward.

To prevent this, we need a clear cut criterion for considering a feature ready. From this release on, we make sure that the test is available before the feature is implemented, both as a manual and as an automated Fitnesse test. The idea is that implementing a feature with the tests ready before hand should be like taking an exam and have the answers available before you start.

As a developer you have to make sure that the test for the feature in question has passed before you can consider it to be done. This will both give feedback on how well the implementation matches the expected result as well as verify that the tests make sense.

We are now ready to begin writing our first lines of actual production code. To assist us we have our acceptance tests that we need to pass, and the CRC-cards from last time. More importantly perhaps, we have access to those who can tell us what the acceptance tests really mean if we get confused, and we have access to the rest of the team that can help us recall and refine what came out of the CRC-session.

We start by looking at the acceptance test. The first thing that it does is to establish a connection between two subscribers. This looks like a good place to start.

Remembering the quick design session, we begin with the Subscriber class. Our first test ends up looking something like this:

class TestSubscriber < Test::Unit::TestCase
  include FlexMock::TestCase

  def setup
    #...
  end

  def test_start_waiting_for_calls
    factory = flexmock('CallReceiverFactory')
    receiver = flexmock('CallReceiver')
    factory.should_receive(:create_receiver).with(@address, @port).and_return(receiver).once
    receiver.should_receive(:start).with(@subscriber).once

    @subscriber.start_receiving_calls(factory)
  end
end

This test maps roughly to the first steps in the scenario we discussed last time. The Subscriber class is expected to create a CallReceiver and tell it to start listening to calls.

The code above is not by far the first version of this test. We started by just testing that we could tell the Subscriber to start receiving calls. Then we wanted to test that a CallReceiver would be created. That led us to add a CallReceiverFactory, which enabled us to control how CallReceivers are created from outside the Subscriber class. We needed this to be able to make sure that we are able to have the Subscriber class interact with our mocks in a test environment.

We then moved on to test that the CallReceiver was told to start receiving calls by the Subscriber. We actually missed that the CallReceiver will need to know who to notify when a call is received. That we didn’t discover until we started on the CallReceiver class later. We then had to go back and update this test and the corresponding production code.

We also had some notes from the CRC-session that told us that we need some information about IP-addresses and ports. That information eventually ended up in this test as well. We pass that information to the CallReceiver by way of the CallReceiverFactory so that we know from where the CallReceiver should be listening to calls.

We continue with the rest of the classes, focusing on implementing what is needed to get a connection established. If we notice new things that would make sense to add to the code, but isn’t really related to getting a connection up and running, we make a note of that and move on.

When we take a crack at the code for the acceptance tests, we notice that we need to pass an address and a port to the Subscriber’s constructor in order for it to know where it should listen for incoming calls. This forces us to add that data to the acceptance test as well. We do discuss this with the customer first of course.

Acceptance Tests

The acceptance test for the current version creates two Subscriber objects that listen at two different ports on localhost. This feels like a good compromise. We don’t test the application in its entirety right now, but we do use real communication and we have an easy way of asserting that both clients behave properly. This may be revised later though.

The acceptance tests were revised a bit when we started developing. Some information was added that we discovered was needed by the code in order for it to know what to do, and some information was deemed unnecessary. The current version looks like this:

What the Application Does So Far

• A Subscriber can listen for incoming calls.
• A Subscriber can make a call to a predetermined address.
• Subscribers can exchange information about the identity of the calling parties.

We have strived to keep this as simple as possible. For instance, for now all we do is exchange user information by each subscriber sending their name as a string over a TCP socket. This is all we need at the moment. No XML, SOAP, ASN.1, or other is needed yet. We are focusing on getting a connection up and running. We do know that we will (most probably) revise this later so we do our best to not have any duplication in the code. If we want to change from TCP sockets to another scheme, we shouldn’t need to do many changes. If we want to change to a more elaborate identification scheme, we should be able to get away with doing those changes at one place.

Notes

The tests so far make heavy use of mocks. Nearly everything is about testing that class A calls method M on class B with this and that argument. This may be due to the nature of this application – we’re just passing text between two endpoints, but I’m beginning to feel that there must be a different way.

I like the way mocks help me develop from the top down. If a class that I’m working on needs the help of another class, I don’t have to stop and begin implementing that class before continuing with the first. I just create the interface I need, create a mock from that, and continue with the first class. When I later move on to the “discovered” class, I already have a pretty good defined interface to implement.

The fact that this is done in Ruby seems to get me into trouble from time to time. There is no interface where I can put all of my assumptions when I mock a class that I haven’t developed yet. This means that I have to keep notes about what classes needs what methods with what arguments. When I start to implement a class that has only been mocked earlier I quite often notice that I need to make small changes to the interface that I drafted while mocking. With the interface construct, any such changes would be explicit. Tests relying on that interface would automatically start complain if I messed up there assumptions. In Ruby, I don’t get that help from the language and at times things got a little messy.

Using quick design sessions rather than working on design documents requires that there is a short time between the session and implementation. As it has been a while since I last worked on this, just looking at the CRC-cards wasn’t really enough to start implementing. Luckily, I could read the last blog entry and got a pretty good idea of what I was up to last time.

The team has identified the tasks for the first iteration and are about ready to go to work on it. Before we continue, we pause to have a quick design session where the major classes of the application are identified. The design session is done collaboratively with several, if not all, team members present.

For this session we elect to use CRC-cards (Class, Responsibility, and Collaboration). We walk through the scenario that we are about to implement and try to find the major classes involved. Where possible we try to use terminology from the system metaphor that we decided to use for describing the system. We write the name of those classes along with their responsibilities. Finally, we walk through one or two scenarios and try to see how the classes interact and write down the collaborators of the classes on the cards as well.

Looking at the acceptance test for the current story, we end up with the following set of cards:

The team sits around a table with the cards created so far spread out, each time a class is mentioned someone lifts up that card and holds it for everyone to see. If a new class is needed, a new card is created. If a class is no longer needed its card is ripped up and thrown away.

For the scenario of connecting two applications the discussion can go something like this:

• The calling application is started and an instance of Subscriber is created (The subscriber card is lifted up by one of the participants).
• The Subscriber creates an instance of CallReceiver and tells it to start listening for calls (both cards are held up).
• Here someone notices that we need to store information about how to reach a subscriber somewhere. Probably the IP-address and port where this application receives connections. We make a note of this, but we don’t feel we need to decide exactly what class holds that data at this point.
• The called application is started and the same scenario as above is repeated
• The Subscriber in the calling application makes a call to the called application by creating a Conversation class (cards in the air).
• Someone points out that we need the know how to reach the called application as well. This information needs to be stored somewhere. We make a note of that and move on.
• The CallReceiver in the called application detects the incoming request and creates a Conversation class that will match the one on the calling side. The Conversation is passed along to the Subscriber class, which in turn notifies the Console class about the new conversation.
• The Subscriber class in the calling application notifies its Console about the new Conversation
• In both applications the Console class displays a message that indicates that we have a conversation started.

After the team has been through this a few more times, should have enough information to start implementing the design. At any time the design can be revisited if deemed necessary.

Highlights

• Design is a collaborative effort. Everybody on the team is involved in the discussions and walk away with a pretty good understanding of the design.
• This lessens the need for some of the intra-team documentation needed. If every developer designs her part of the application in isolation, there probably will be a greater need for documentation and formal reviews in order to get input and spread knowledge. The argument for dividing the design up usually is that of efficiency. You can cover more ground if you work in parallel. I believe that the raise in cost of communication that follows will hurt you in the end though.
• The level of the design artifact is at a level that all of the team members can understand and comment on. Developers, customers, technical editors, and QA people, etc.
• Using cards, ripping them up, moving them around, and pointing to them during discussions is a more tactile approach than working in a UML-drawing tool or even drawing on a whiteboard. I’d think this is a positive thing for the overall understanding in the team. In design sessions where the whiteboard is used directly without cards, there is not room for more than one or two people up at the board at the time. This can lead to one or two of the stronger wills in the room to high jacking the meeting, not leaving enough room for everyone to air their opinions.
• This does not replace the use of UML diagrams or other forms of formal documentation and reviewing, if those are necessary.
• The session aims to create a design that is suitable for the stories at hand. We will refine that design as new stories are planned. If we don’t have enough buy in from the organization that this is possible. These kind of exercises will most probably fail.

Let’s start implementing…