Yesterday DevAgile.com reported:

The Scrum Alliance announced last year that Scrum creator Ken Schwaber resigned as President and Chair of the Board of Directors. This might be however not the end of the turmoil in the Agile world. Ken Schwaber was replaced October 5 by Mike Cohn, but there are now rumors that he might leave the Scrum Alliance to join the Waterfall Alliance. And this is not the only surprise that might happen soon: other unverified sources mentions that the Waterfall Alliance is also currently negotiating with Jeff Sutherland and Tom Gilb to join its board. [...] Any developer with a little bit of common sense will recognize that it is more sensible to sign contracts for months (years or centuries) of secure work with a traditional waterfall process than to do short weekly iterations where the customer can kill the project at any time. We all know that most of the Agile “adopters” have left Waterfall because Scrum is quicker and trendier to place on PowerPoint slides.

Hopefully people read the whole article and spotted it’s an April Fool – I’ve read the Waterfall Manifesto before and it still amuses me.

Will Mike Cohn leave the Scrum Alliance? is a post from: Toronto Project Manager - Paul Henman CSM

"Will Mike Cohn leave the Scrum Alliance?" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

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.

Mid-sprint review is a post from: Toronto Project Manager - Paul Henman CSM

"Mid-sprint review" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

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.

Enthusiasm is key is a post from: Toronto Project Manager - Paul Henman CSM

"Enthusiasm is key" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

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!

Puzzling is a post from: Toronto Project Manager - Paul Henman CSM

"Puzzling" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

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.)

Resume updated is a post from: Toronto Project Manager - Paul Henman CSM

"Resume updated" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

Indexed often has funny or insightful posts, and I particularly liked today’s:

Listening or waiting to talk? is a post from: Toronto Project Manager - Paul Henman CSM

"Listening or waiting to talk?" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

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 suspect they both worked for some part of the government because I recognised some of the abbreviations they used, but also because they seemed completely unconcerned that their projects were going to take years (and millions of dollars) and then ultimately fail. Not that they’ll be around to experience the consequences – one was talking about their fourth re-organisation of the year, while the other said he was trying to get moved to another department.

Hearing them talk about how if they needed an answer from their customer they had to go via the business analysts, who are now reporting to someone else, and how neither project seemed to have produced anything but specification docs in the past year, just annoyed me. The waste of money. The waste of time. The lack of concern that they’re destined to fail. Aaaargh!

At first I thought about butting into their conversation and asking if they’d ever heard of Agile, but the more I overheard the more it made me determined never to work on that kind of project … or with the kind of people who just don’t care about their project’s success.

I enjoy working with people who understand that customers (like everyone else) change their mind, that a project is measured by its ability to deliver what the customer needs not the volume of its paperwork, that care about the project’s health and want to see it through to its successful completion … and maybe that’s why I see myself as a scrum master, a facilitator, a coach & mentor, and not a traditional project manager?

Biting my tongue is a post from: Toronto Project Manager - Paul Henman CSM

"Biting my tongue" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

Equally pointless is trying to predict what task a particular person will be working on twelve months from now, at precisely 3pm.

Precisely is a post from: Toronto Project Manager - Paul Henman CSM

"Precisely" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

I’m trying out a new theme for this blog – I was using Abstractia but I’ve just installed Portfolio Press, so let me know what you think and especially if you find any problems.

Change of scenery is a post from: Toronto Project Manager - Paul Henman CSM

"Change of scenery" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.

[Part 1 of my recap ("the morning") is in a previous blog entry.]

After lunch I decided to investigate the Open Spaces area, and the title “Painless Agile Adoption” caught my eye. Having told past managers that Agile adoption is necessarily painful and not everyone will make it through the transition, this was going to be an interesting discussion.

It was just Gil Broza and myself initially, but shortly after I started listing off some of the pain points I’d seen in a recent transition we were joined by Gino Marckx. I didn’t take any notes because the discussion was too engrossing, but from what I recall we distilled many of the specific pains down to a few causes (e.g. lack of up-front preparation / education, changing any established pattern causes pain) and then got into a great discussion about whether the pain was avoidable.

For me, one of the revelations was that the team going through the transition needs to have a problem to solve, i.e. a pain that they want to reduce/remove, otherwise why would they want to adopt Agile? “If it ain’t broke, don’t fix it!” We came up with the idea of a pain baseline, i.e. the pre-adoption level. We agreed there’s the “fixed cost” of the growing pain (because any change involves some pain) but that there’s also the “unnecessary” pains, e.g. making a scrum team take a complex route to solving a problem rather than invest (time and/or money) in helping them solve it the most efficient way.

Certainly on my last project the team didn’t have any pain/problem with the status quo, so introducing some elements of Agile must have felt like a lot of unnecessary pain. However if the senior management (who directed the team to adopt Agile) had shared their rationale, and maybe even pushed down some of their pain, then the team may have been more accepting. One motivation was clearly to save money, so how could the team share that pain? Well, at the same time as trying to introduce Agile, the decision was made to stop paying overtime. If that decision had been taken sooner, then the team would have wanted to find ways to be more efficient – most of the team didn’t mind working extra hours when they were being paid for it, but very few were willing to do it for free. That’s a pain that Agile could have helped them address. Instead it appeared to some that the Agile transition was the cause of them losing OT – that was definitely an unnecessary pain which hindered adoption and, I believe, led to some resentment that Agile caused them to lose OT.

We concluded that there is no such thing as “Painless Agile Adoption”, just degrees of pain and hopefully the team see their baseline pain levels reduce as they begin to adopt Agile practices. Gil kept the sheet with our notes on it and he plans to write something on this topic soon, so I’m looking forward to reading that.

I was torn as to which session to attend next: “An introduction to Agile Through the Theory of Constraints” (J. B. Rainsberger) and “An Introduction to Business Value Engineering” (Joseph Little) both looked interesting but I thought “Project Vital Signs” (Stelios Pantazopoulos of ThoughtWorks) would be most useful as metrics is an area where I’ve encountered challenges during a transition from waterfall to more Agile methods.

Stelios started by saying that the “State of the Union” for project management was one of a poor track record with too many failures, and that many status reports simply show whether a project is on track – we need to show how & why a project is on/off track.

He used the analogy of the project as a patient: we need to track its medical history, apply some tests, track its vital signs, and apply our experience in order to reach a diagnosis and then to recommend the appropriate treatment. His definition of the project’s vital signs are the four PMBOK project levers (scope, quality, schedule & budget) plus the team. He proposed that the vital signs be measured and shared in terms of scope burn up, the current state of delivery, budget burn down, delivery quality metrics, and the team dynamics. These can be measured as:

• scope burn up: the number (I would suggest using total story points) of the scope (product backlog), so use a graph showing the total backlog, scope (story points) delivered and a trend line.
• current state of delivery: a snapshot of the story board (product backlog), showing who is working on which story. This seemed to me to be too much detail unless the whole project team is only a few people; I need to think some more about how this could work for a large (50+) person project.
• Budget burn down: similar to a sprint burn down, except it shows the initial budget, current remaining budget and a trend based on the “velocity”.
• Delivery quality: the usual defect tracking stats, i.e. the number of bugs tallied by severity & priority. Stelios also suggested using test coverage stats but I think bug stats are fair more commonly used.
• Team dynamics: this is the team’s assessment of their “maturity” as defined by Tuckman’s Stages (forming, storming, norming, performing). Stelios said he collects this as an anonymous assessment as part of the team’s Retrospective. Looking at his example data, I’m concerned that after just a couple of iterations the team felt they hit the Performing stage – this seems too quick, and so I question the validity / usefulness of this data.

One of Stelios’ slides was a project wall which showed all the vital signs – it was dashboard view of the project’s status. (It was quite similar to things I’ve done in the past, so it’s reassuring to see we’re in sync.)

During the Q&A section, someone asked which (if any) tools were used to maintain the charts; Stelios said it was currently done by manually entering the data into Excel but agreed that it should be possible to pull at least some of the info from other tools such as the build system.

For the last session of the day, I went to Declan Whelan‘s entitled “Building a learning culture on your agile team”. This is an area where I feel my recent projects were quite weak, although part of the reason was management pressure to develop (produce code) rather than develop (grow) as a team. [There were a lot of references in this presentation so my notes are more like pointers for additional research rather than specific things I learned in this session.]

Declan began by mentioning the Satir Change Model and how short-circuiting the learning curve could lead to a lower “new status quo” than could otherwise have been achieved – the summary being “don’t rush it”.

We were given an exercise to do in pairs (or in our case a group of 3): ask your partner their name, how many siblings they have, and their biggest challenge as a kid. However, we were told, if it’s too painful then either pick another challenge or pass – this was important because it gave people an “out” if they needed it. It was an interesting ice-breaker and probably would be a good exercise at the start of a training session or retrospective.

A few people joked how Declan was giving us lots of things to add to our Amazon wishlists:

• “Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators” by Patrick Lencioni
• “The Fifth Discipline: The Art & Practice of The Learning Organization” by Peter M. Senge
• “Pragmatic Thinking and Learning: Refactor Your Wetware” by Andy Hunt
• “Agile Coaching” by Rachel Davies
• “Fearless Change: Patterns for Introducing New Ideas” by Mary Lynn Manns and Linda Rising

I agree with Declan’s assertion that it’s important to focus learning on bottlenecks and challenges – it makes sense to address those areas where the team needs help. He also said that an expert is not necessarily best teacher because they can’t think like novice, and I’ve certainly seen this myself. “In the beginner’s mind there are many possibilities, but in the expert’s there are few.” – Shunryu Suzuki.

As for how people learn, Declan said they pass through three stages of behaviour: Shu Ha Ri, or following, detaching, and fluent. (As per Alistair Cockburn.) He also referred to the Dreyfus model of skill acquisition but didn’t go in to any detail.

He also mentioned that there was some research to support the idea of “promiscuous pairing”, in which pair programmers frequently switch their partner sometimes daily or even more often. I can see the theoretical benefits in this but it requires a very mature team in order for it to work efficiently, I suspect.

We watched a clip from TED called “Tinkering School” which was fun and was one of the few things I tweeted about during the day – it seems like such a great idea. A useful tool that I’ve not encountered before is the “gold card” which is a “fun” story in the product backlog, for example investigating a new technology and reporting back to the team.

The wrap up (“Highlights of the Day”) was done in an interesting way I’d not seen before: the organisers named each session in turn, had the attendees stand up and asked people to give some brief feedback.

I really enjoyed the day and have just two suggestions for next time:

1. declare the tags we should use – I saw people tweeting using any (sometime all!) of #agiletourtoronto, #agiletour and #agiletoronto
2. find a way to encourage attendees to mingle at the end – it was a shame many people left as soon as the last session ended instead of staying for the wrap up and socialising afterwards, but I understand some people had travelled a long way or had other commitments.

I’ll definitely be at the next event; hopefully I’ll even have something I can present!

Recapping Agile Tour Toronto (part 2) is a post from: Toronto Project Manager - Paul Henman CSM

"Recapping Agile Tour Toronto (part 2)" was originally posted by paul on Toronto Project Manager - Paul Henman CSM. All rights are reserved by the author.