Toronto Project Manager – Paul Henman CSM

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.

It seems that this blog is largely becoming a place where I just re-post Dilbert cartoons, but that’s not my aim … however, Scott Adams is just so spot on sometimes!

I’ve been in the situation (as I’m sure most PMs have) where the team says there’s just not enough time to get everything done, so I try to explain to the Product Owner that we need to cut (i.e. postpone) some functionality or we can’t deliver, only to be told “I need it all or there’s no point in delivering it”. (more…)

As you probably know, I’m looking for a new gig as a Scrum Master (excuse me while I plug my resume) and one of the challenges I’m finding is assessing the “Scruminess” of a company/project.

Fortunately I’ve found two handy tools: “The Scrum But… Test” and “10 Questions for Your Scrum Master Interview“. The first one (which is based on people who say “we do Scrum but…” and a long list of exceptions!) could be used as a self-test, for someone on a project to assess their level of adoption, but I’ve been using it (along with the 10 Questions) as a basis for things I need to learn during interviews.

The good news is that I’ve been interviewing with a company that I think is doing Scrum in a very pragmatic way: not blindly trying to adopt everything but rather picking the parts which make sense and having a roadmap for their next steps. I think the interviews have gone well and hopefully I’ll hear more in the next few days.

Isn’t it ironic how I don’t have time to update this blog when one of the keys to a good Scrum team is achieving a sustainable pace? It’s frustrating because we’re doing some interesting stuff and solving (or working towards solutions for) some issues which I suspect affect other Scrum teams that are trying to be effective in a traditional enterprise environment.

Well, given that I’m here at last, I should post at least one thing of interest. One of the things I think we’ve changed that has helped is the way in which the Project Scrum Master (that’s me for the new release) and the other Scrum Masters provide updates to the management team: it used to be a bi-weekly presentation and Q&A session, but a few months ago we changed this to a weekly stand up meeting around our whiteboard. Not only does it mean the status is more up-to-the-minute (because it only takes a moment for one of the SMs to update the white as opposed to changing the PowerPoint slides) but it’s become a much more interactive discussion and decision making session.

As for our challenges, I think one of the biggest is where we have interfaces to non-Agile teams/organisations, e.g. purchasing an item that has a lead time of 2-3 months is problematic when we’re not looking (in detail) that far ahead. We are trying to forecast our hardware requirements, for example, but it’s not easy when the User Stories in our Product Backlog could change priority (impacting when we need the equipment) or be removed from this release altogether. We’re trying some techniques and all we can do is review and adapt them accordingly … doesn’t that sound like a novel idea?