Monthly Archives: December 2010

Getting Real Customers to Submit Proposals for Agile 2011

Catherine Louis and Shane Hastie are the stage organizers for the Working with Customers stage at the Agile 2011 conference in August.

It would be fantastic to hear from real customers who work with Agile teams; tell us your stories, what works, what doesn’t, what would you change, how do you get the best results for your customers, what are the challenges you’ve faced and how have you overcome them? Tell us about the good, the bad and the ugly and what lessons other teams and organizations can take from your experiences.

The “Working with Customers” stage explores the interactions between the customer community and Agile development teams, focusing on the non-technology functions as well as the Agile development teams themselves.

We see the “customer” as a many-headed Hydra ranging from executives and managers who sponsor and pay for projects, to internal “users” (horrible term – are they addicted to our software?) to the ultimate customer who purchases or consumes our product.  Even the end consumer comes in varied flavours – eg on a website often the funding comes from advertising revenue but the primary functionality is to provide a service or product to a member of the public who visits the site.

Questions we are exploring include:

  • What does “working with customers” mean when you have an Agile team delivering to multiple customers and multiple end-users? (For example in  Telecomms or Financial Services)
  • Do Agile customer relations incite different sales and marketing techniques?  If so what are they, and what does this look like?
  • How are Agile contracts structured to support collaborative flexibility and progressive elaboration between customers and business?
  • What is the level of interaction between Agile sales and Marketing teams and Agile developments teams, do they work as one team, can they work as one team, should they work as one team?
  • How engaged are the development teams with the end consumers of the services and products we produce? What does this interaction look like and how is this different from traditional “waterfall” development?
  • How is “pull” created with the varied customer communities and how does this change the interaction with the Agile development team?
  • How does the work-life balance change when the Agile teams are working across varied customer communities? Is this more stressful or less?
  • Does an Agile development team working across customer communities promote increased innovation?
  • How do you reconcile conflicting customer goals through collaboration? What are the conversations, tensions between customer communities, customer facing teams, and the Agile team?
  • What happens when you work with customers and deliver in a regular cadence, and what happens when they like what you deliver versus when they do not?
  • How do you ensure that the Agile team gets feedback from the whole spectrum of customers?
  • How closely coupled should the Agile project delivery cadence be with the marketing release cycle?

Presentations which feature feedback from CUSTOMERS of Agile development shops are the oness we truly want to hear in this stage.

Please look at the stage description here.

Please submit your proposals online here – we really want to hear from you!

Important deadlines are:

Earlybird submissions:                10 January 2011

Just-in-time submissions:            14 February 2011

Program Finalized:                     18 April 2011

Posted by Shane Hastie


Posted by on December 22, 2010 in Agile 2011


Daily Standups are for intra-team communications

I’ve been teaching a lot of Agile courses lately, and a very common point of discussion is the way the Daily Standup meeting is often abused and misused. Words like “micromanagement” are often used.

The primary purpose of the daily standup is for the team members to communicate with each other about their progress against the tasks they are working on. A coincidental benefit is that a leader or manager gets to hear about what’s going on. The meeting is for the team NOT for the manager!

The most common structure for the daily standup is the three questions from Scrum:
What have you done since the last meeting?
What will you do before the next meeting?
What is in your way?

Each member of the team should answer the questions in less than one minute. The answer should be against the tasks they have committed to, and the response should be short, sharp and to the point. The whole meeting should take no more than 15 minutes.

For example, lets say you are busy with a two-day task –

If everything’s on track, your response would be something like:
I started on task xyz,
I will continue with task xyz,
Nothing’s in my way

These responses let your team mates know that you are on track and they don’t need to be concerned about your progress.

On the other hand, if you’ve been pulled off the task to work on a production problem then your responses might be:
I started on task xyz and had to leave it to spend half of the day on the production problem, (your team mates now know that they have to adjust their work on any tasks which are dependent on you finishing yours)
I will need to continue working on the production problem – that will take me out all day (now your team mates know that they need to adapt to not just a half-day delay, but a day-and-a-half)
The production problem is in my way (this is something the manager/leader might be able to do something about)

Another common state is when you discover that the task is more complex than you thought:
I started on task xyz,
I will continue with task xyz,
I’m struggling with the task, I thought it would take me 2 days, but now that I’ve started it looks like i will need 4 days. (You might BRIEFLY describe what the issue is)

If someone else on the team could help you with the problem then they may say so, but you mustn’t solve the problem in the standup – talk about it together afterwards.

The key to an effective standup is keeping it short and focused, your team mates don’t want to hear the details of your day(“I spent three hours talking to Mary, wrote 500 lines of C code and spent 30 minutes in the bathroom”) they do need to hear about things that will impact their work and if you need their help.

A note for managers – the daily standup is NOT the dreaded “status meeting” – please don’t turn it into one. They waste the whole team’s time, and don’t add any value to the team’s work. If you really need a status meeting, hold it every month or so, and trust your team to work in the organization’s, the project’s and the team’s best interest in the meantime.

What do you think – how do you make sure the daily standup achieves it’s positive purpose?

Here’s an example of how NOT to run a daily standup:

Posted by Shane Hastie


Posted by on December 1, 2010 in Agile


Tags: ,