Spotted on The Daily WTF:
The three teams I’m working with are on 2-week sprints; today and tomorrow marks halfway through their first sprints, so I did a brief mid-sprint review with two of the teams (the third team are doing theirs tomorrow). I introduced each team to the objective, which is for the team to look at the remaining work and any impediments then discuss any concerns they have about completing their committed stories in time for the Review, then opened it up for discussion.
Both teams (and I’m sure the third team) are concerned that the lack of a dedicated test environment is becoming critical. This impediment has been escalated and the teams have done what they can to work around it, but it’s fast approaching the point at which there won’t be time for the teams to complete all their testing. The IT department are working on rebuilding the server, and obviously they have other teams placing demands on them too, but it’s important that the people who set their priorities understand the implications – we don’t necessarily know the urgency of other work, so we can say we should be #1 but we can make sure we make our case as best we can.
Other concerns included getting clarification from experts outside the team (again, they have other demands of their time), the scope of testing for small, isolated code changes (can’t we limit the scope of testing more?), and a low priority support issue which they had committed to resolve in this sprint even though it’s not required until the end of the next sprint. Team members took responsibility to follow up on these items, and I suspect they’re already resolved.
One item which we’ll discuss in the teams’ Retrospectives, I’m sure, is the introduction of additional stories after the sprint started. It’s possible that both teams will struggle to complete all their stories, so the Product Owner (who was part of the mid-sprint review) is forewarned, and we took this opportunity to ensure the priorities are clear to everyone.
Even though they may not complete all the work on their task board, I still think the teams are doing really well – I was pleased to see people volunteer to get issues resolved, as well as the open discussion about the teams’ progress and performance. Obviously it’s important that the teams deliver completed stories but it’s also important that they grow as a team and improve the way they work, and I’m very optimistic in this regard.
I started a new (short-term) contract on Thursday and I’m very pleasantly surprised to see how keen people are! The company took the decision to “go Agile” only a couple of weeks ago and they’ve jumped in with both feet. They’re committing a lot of time and money to this transition, but even more important than that is the enthusiasm I’ve seen in the three teams I’m working with – people are eager to learn and experiment, which means the transition is a lot more likely to succeed.
I’m going to try to blog about how things go – the exercises and games we run, tools we use, etc. and how well they work. Obviously what works for one company (or even one team) may not work for another, but I think it’ll be interesting to see how things evolve with these three teams. (The company is forming more Scrum teams but I’m focused on the first three teams right now.)
When I joined, the teams were on day 4 of a 2 week sprint. They already had a (partial) product backlog, with the top priority stories estimated; the teams each had committed to some stories and broken them down in to tasks; they had started doing daily stand up meetings (a.k.a. scrums) with each team member addressing the three key questions. The teams also have support responsibilities, which they are managing using Kanban boards. Most surprisingly everyone seems to understand how this all works and (on the whole) are on top of updating both the support and story tasks.
As the new boy on the team(s), I spent some time sitting in each team room and just observing how the teams performed. I also ran an exercise loosely based on the Billboard Game – I say loosely because I’ve not run it before so I followed the spirit if not the letter of the game. It was a great way to get to know the team members, and even they knew each other fairly well before most people said they learned something new about their colleagues.
I’m really looking forward to next week – we’re going to do a mid-sprint review with each team to see if they feel they’re on track to complete all their committed stories by the end of this sprint. I’m also going to meet regularly with the Scrum Masters so we can share thoughts and learnings regarding Agile; as an example, the teams are approaching a particular problem (tracking the progress of dev tasks through code review, test, etc.) in different ways (separate tasks vs columns on the task board), so it’ll be interesting to see which works best for the teams – it may be they all chose to use the same method in the next sprint or maybe they’ll continue to test different approaches.
I was on the subway last night, sitting next to a couple of project managers. I could tell they were PMs because I overheard part of their conversation, including how one proudly announced he’d successfully got a Software Requirements Specification signed off after only three months, and the other bemoaned how she had to keep a tight rein on her customer because he kept changing his mind.
I organised a few photo walks recently; word of their success spread west and so a Calgary Photo Walks group was born! The organisers have some great plans for its future and I couldn’t be left behind, so now I’ve created a Facebook group (called Toronto Photo Walks) as a place where we can schedule our next events.
Most people are Flickr users and so we now also have a Flickr group, also imaginatively entitled Toronto Photo Walks.
So if you’re in the Toronto area, have a camera (any camera!) and fancy exploring the city, join our group and come along!
Simple plan: meet outside Riverdale Farm, opposite the Necropolis, at the end of Winchester St, at 1pm on Saturday, November 14th.
(This is the first photo walk I’ve organised in a few months, although a few of us got together to shoot at Guild Inn recently.)
How do you identify a high priority task? I like this answer, found on Merlin Mann’s website:
In Scrum we tend to see tasks (the work breakdown that a team deemed necessary in order to deliver a Story or feature) as equal priority because they all need to be completed in order to say we’re Done.
However Scrum also has the concept of a Product Backlog, which is a prioritised list of Stories (or features) which the Product Owner manages; planning for each Sprint (iteration) begins with the Product Owner describing the top priority Stories.
So maybe this card should say “How do you identify a high priority Story? It’s Done.”