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 got a package from IBM a few days ago but forgot to post about it (until now). It’s a shiny metal tin (about 6″ x 6″ x 1.5″) containing a metal puzzle – very neat. But the reason I mention it here: it’s an advert for IBM’s Agility at Scale and Agile Development e-kit.
That reminds me of two other IBM-related things: (1) they’re currently recruiting techies for their Agile team (so hopefully project managers will follow), so I’ll keep an eye on them; (2) there’s a Toronto Agile User Group* meeting on Thursday entitled “Software is About People”, which I’m attending. *The reason that’s IBM-related is Scott Ambler, Chief Methodologist/Agile with IBM Software Group, is one of the founders of the TAUG.
Apologies for the rambling brain dump but it’s been a busy day and it’s not over yet!
I have updated the PDF version of my résumé (there’s a .DOC version too) to include some more technical information, such as programming languages and development environments. I think a rewrite of the overview page is next on my To Do list.
I’m looking to work with a dynamic, exciting software development group in Toronto. (I’m an experienced project manager / Scrum Master and I’ve led projects for military, healthcare, transportation, government and a variety of other markets; both project and product development.)
