Agile Stand-ups & Sit-Downs

I'm a big fan of agile project management methodologies. Working in a digital agency, you are dealing with a rapidly changing landscape and clients with shifting goals. Being Agile allows you to work with that shifting scope and through flexibility deliver what the client needs without the painful Change Board process of Prince 2, or the dangerous scope creep of doing nothing.

Like most Agile PMs, I spend part of my day in stand-ups. Depending upon the number of projects, it can be a fair bit of my day. Stand-Ups are great, they give you that day to day interaction with the team so that you know how things are progressing and the team has the option of flagging up issues in a more informal manner, and getting feedback from the rest of the team. However, and this is especially true when freelancers are also used in delivering a project, stand-ups don't manage progress or quality.

I'm experimenting with "Sit-Downs" once a week; the idea is simple, once a week, normally on a Friday the Technical Lead and PM for a project sit down with the developer(s) and ask to be shown what they've done that week. This can be pure code, looking through the latest development work and the developer outlining what they've achieved, but it can also be reviewing the latest functions that have been built. More commonly it is both.

This show and tell approach has two advantages.

  • Firstly, it allows you to visibly track against your project plan. Rather than the verbal updates of "this is done" you can actually see it.
  • Secondly, it means the Technical Lead is reviewing the approach as it is done and can feed into how it should be done.
  • This is not a replacement for solid Technical Specs, Code Reviews or QA. All of these things are still needed for effective and accurate project delivery, but what they do do, is force a time into everyone's calendar every week to monitor progress. Rather than handing a developer a spec and saying build this, you are able to see how it is progresing along the pipeline. It also gives the developer a chance to show off what they've done, something that is often missing from this profession. Creatives often get the chance to display their work, but the people building it, not so much.

    Keep the sessions short, 15mins to half an hour tops as everyone has real work to be doing, and try and avoid bringing Client Services, becuase this is not a public review of progress and things that look complete may still have a fair amount of back end work to get them ready to show the client.


    Add new comment

    Filtered HTML

    • Web page addresses and e-mail addresses turn into links automatically.
    • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
    • Lines and paragraphs break automatically.

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.