Mike Bowler

In an effort to simplify how I explain Agile to people, I've tried to place the various practices into a small number of groupings. I've done a number of versions of this diagram over the years that have been posted here and have never been entirely happy with the results. I presented this version to XP Toronto last night to get some feedback from others in the Agile community and we had some good discussion.

The diagram here is the same one I presented last night and doesn't reflect any of the feedback I got.



This started from the idea that successful projects all have certain characteristics. They may not follow the same practices but they have certain things in common. The groupings of communication, motivation, planning and accuracy seem to be things that all successful projects share. Unsuccessful projects are lacking in one of more of these areas.

There's no single way to improve in a given area - many different practices could get you to the same goal and that's reflected in the sample practices in each area.

Note that the practices listed here are not intended to be exhaustive - I'm sure there are many more than should be here.

One comment from last night was that the label "alignment" might be better than "motivation".

Deborah Hartmann just pointed me at this article where I'm quoted on Agile processes and XP. I'd been interviewed for this eons ago and had no idea that it had actually been published.

This article by John Lam talks about how cooking can be made a less intimidating experience for novice cooks by reducing the complexity they have to deal with up front. He also points at this excellent article by Jeff Atwood. Both of them draw parallels to the software world and it's clear that we could learn some good lessons from this.

Mishkin Berteig will be speaking at XP Toronto tomorrow. I've known Mishkin for a while through the local Agile Coaches group and can attest to his knowledge of the subject. This should be an excellent talk - come on out and join us.

Bar Camp Toronto is running this coming Saturday.

At Bar Camp, Deb Hartmann will be organizing an XP Project room similar to the ones run at XP Day. I'll be one of the coaches in the room, showing people how to do Test Driven Development (TDD) and how to use things like junit and fitnesse. If you're curious about unit/acceptance testing in general or want to get a feel for TDD then come out and give it a try.

Dmitri Zimine has just started a blog on agile development. Dmitri is a member of the Toronto Agile Coaches group and has some excellent insights to offer. Welcome aboard!

The Toronto Agile Coaches group met this afternoon in Ajax. In attendance, we had Deb Hartmann, Mishkin Berteig, Dmitri Zimine, Chris Wheeler and myself. [Dmitri hasn't published the url for his blog yet so he doesn't get a link ]

Once again, we had some really fabulous discussions over a really wide range of topics. We really need to start recording some of these sessions and turning them into podcasts. Some of the topics are confidential but a lot of what we talk about would be good material for articles or discussions.

At one point the discussion turned to blogs and it was somewhat scary that two of us knew our exact technorati ranking (yes, I was one of them).

We're considering the idea of grid blogging on a variety of agile topics. If there's a particular topic that you'd like to have a bunch of Agile coaches cover then post it here and we'll consider it for a grid blog.

The topic of prioritizing requirements came up in a recent meeting. Often the customer will say that all the requirements are top priority and are unwilling to place priorities in individual items.

The reason that we care about priorities is that we are going to implement the requirements in priority order. The most important things get built before the less important items. So, how do you handle the case where the customer says everything is top priority?

What I've found is that customers often think of priority and the order things get built as two separate items. If you explain that we can't build everything at once and need to decide which things to build first, the customer is usually more than willing to help with that. They're satisfying our need for priority but aren't thinking of it as setting priorities.

If you are using the XP technique of writing requirements on story cards then one technique for getting them prioritized is to hand the stack to the customer and explain that you will implement them in the exact order in the stack. If they wish to change the order of items then this is their chance to do so. It's helpful if you stress that the current order in the stack is fairly random.

I've found that when I do this, the customer will usually split the stack into two piles. One that really has to be done first because those cards are most important and then a second pile of less important cards that could be done in any order.

Cross-posted to the Agile Advice blog.

It's always interesting trying to explain Agile practices to people who aren't in the IT industry. They're baffled that you would do things any other way. What I describe as the Agile practices seem like such obvious things that people don't understand why I'd even have to say them.

Yet when you describe them to people who have been in IT for a while, these ideas are a significant change from the way that they've been working.

I had this same conversation with a non-IT person this morning. I was explaining about short iterations and how you give the customer working production code every two weeks so that they can use it and get value from it. Then the customer tells us what they want built in the next iteration and we repeat the cycle.

"Well of course you would do it that way" was the response. "How could it possibly be any other way?"

I was asked by a friend about the history of the Agile groups in Toronto. I figured I'd reply here in case anyone else was interested. Warning, this is long.

XP Toronto

The first book on XP came out in 2000. Prior to this, the only source of information was the C2 wiki and the extremeprogramming mailing list on yahoo. While both of these had lots of really good information, neither one did a good job of introducing the material which made the barrier to entry extremely high (no pun intended).

With the publication of XP Explained, there was finally a gentle introduction to the concepts behind XP. I had started getting interested in XP shortly before the book was published and so I really appreciated the book when it arrived.

I'd been thinking about starting a user group to discuss XP but hadn't really done much about it. Then one day, I saw a posting from Ron Jeffries saying that he'd be in Toronto to work with a client and would anyone be interested in joining him for drinks and discussion. This was the impetus that I needed and I quickly created the xptoronto mailing and organized the first meeting of XP Toronto around Ron's visit. We got a really good turnout for this meeting and this convinced me that there was enough interest to continue with regular meetings.

I quickly discovered that having a celebrity show up at your meeting really does make a difference to attendance. The second meeting had only one person other than myself show up and I think the third meeting only had two other people.

Around this time, Bryan Zarnett offered to help run the group and so he and I ran it together for the next three years. By the time we handed it off, we were regularly getting between 30 and 50 people out to the meetings and were the second largest XP user group in the world, second only to XP Denver. [I base this on discussions with leaders of other groups on the XPUserGroups mailing list, a list devoted to the discussion of how to run an XP user group].

When I'd started XP Toronto, the only Agile methodology that I was aware of was XP. This was also prior to the publication of the Agile Manifesto so the term agile was unknown at the time. As we become aware of more Agile methodologies, the focus of XP Toronto changed to include anything Agile. I really should have changed the name of the group to Agile Toronto but I never did get around to that

After three years of running XP Toronto, Bryan and I decided to step down from the leadership and we passed control to Lawrence Ludlow who has been running it ever since.

Scrum Toronto

In the year or so leading up to this change at XP Toronto, Bryan and I had become quite interested in the Scrum methodology. We had both coached XP teams and seen the benefits of that but looking at Scrum, there were a couple of things that just seemed to work a little better for us than the pure XP practices we'd been doing. In particular, the idea of burn down charts really resonated with me - I immediately wanted to start using them with the XP team I was coaching at the time.

Ken Schwaber, the creator of Scrum, decided to offer a certification for Scrum with an associated training course. Deb Hartmann jumped in at this point and managed to make Toronto the location of the second ever Scrum Certification course. I became certified at this point along with Deb and Bryan and quite a few others.

After the course was finished, we decided that we wanted to start another group, independant of XP Toronto that was specifically focused on the Scrum methodology. Certainly, we would offer Scrum related topics at XP Toronto and we expected that everyone who belonged to Scrum Toronto would also belong to XP Toronto but this group would have a more specific focus.

The Scrum Alliance also began at this point, with most of the same people. The focus on this group was completely different however. This was intended from the beginning to be an international group, not a local one.

There were some 'birthing pains' involved with these two groups but things stabilized after a while. Deb and I focused on Scrum Toronto, where we still provide leadership, while Bryan left to focus on the Scrum Alliance.

Today, Scrum Toronto generally meets for dinner right before the XP Toronto meetings so that those of use who are attending both can do so in the same night.

Update: Deb reminds me that a highlight of the Scrum Toronto group was a book study for Fearless Change that we did last year. We met over dinner and covered two or three chapters each time we met. This was extremely successful and exposed everyone to new ideas for our agile work.

Agile Coaching Toronto

XP Toronto and Scrum Toronto are both open to anyone interested in learning about agile concepts and practice. This often means that the discussions are more geared towards people who are first learning the concepts rather than the people who have been doing agile for a while and want to discuss more advanced topics.

It became apparent that there was a group that we weren't satisfying very well. These are the coaches who want to discuss more advanced topics that just aren't being covered in the other two groups.

Deb Hartmann sent out an initial invitation to all the coaches that she knew to meet over dinner. Out of this meeting, we decided to have regular meetings to share what we know and voila, the third group was formed. At the moment, this group is only open to Agile coaches as we want to keep the discussions at an advanced level.

These are the only Toronto area groups that I'm aware of that are purely focused on Agile practices and principles. Lots of other groups have had individual meetings devoted to Agile topics but none are purely focused on Agile.

We had a meeting of Agile coaches on Saturday¹ and one of the many things that we touched on was the issue of conflicting motivation.

If I, as the coach, stress collaborative work within the team but the company compensates everyone based on their own individual performance then we have a conflict in motivation.

I am trying to encourage one behaviour but the company is encouraging another. Which one wins will depend on the relative importance that each person places on the source of the behaviour. Given that the company controls salary and employment, it's most likely that they would be considered more important.

Sometimes professional pride will win out and the individual people will do things that are not encouraged by the company, simply because it's the right thing to do. It's right to help other people, even if I am not rewarded for doing so.

More often, people will optimize their behaviour for the most important metric that is being used to measure them. This results in the company unintentionally causing the wrong outcome.

Lou Gerstner, former CEO of IBM, says "People don't do what you expect; they do what you inspect".

If we want to encourage more of a certain behaviour then we have to look at the underlying metrics being used to see if they are helping or hindering. To get optimal results, we need to align the motivations of the company with the motivations of the team.

¹ Deb Hartmann writes more about the coaches meeting.

Last night was the March meeting of XP Toronto. BC Holmes gave an interesting talk on design as it applies to Agile projects.

She started by explaining the nebulous nature of design. It's practically impossible to quantify a design - you can't measure the result of a design to see if it is good or not. "I'll know good design when I see it".

She talked about cases where she had been able to write automated tests to verify the usage of a design. There was discussion of a variety of tools that can be used to help with the testing of some parts of a design.

It was a very interesting talk that sparked quite a bit of good discussion about the nature of design and the artifacts that revolve around it.

I am in the process of wrapping up a project with one of my clients and am looking around to see what I'll do next. I've never posted my availability on my blog before so this is a bit of an experiment in marketing.

So, what do I do? In a nutshell, I work with companies that are developing software and I help them do that more effectively. I do this through a combination of Agile processes and practices as well as technical mentoring.

I am an Agile coach; experienced with the Scrum and Extreme Programming [XP] methodologies. I have led Agile teams and I have worked with other teams that have already had their own leadership. I help these teams adopt a more agile approach to development such that they maximize the business value they deliver to their customers.

In some cases, I have introduced teams to a specific methodology such as Extreme Programming. In other cases, I've just introduced certain practices or techniques. Every team is different and has its own unique situation.

I am a skilled developer, having been programming professionally for over ten years and programming as a hobby for another ten years before that. I routinely mentor other developers on a variety of technical skills from languages like Java™, XML and Ruby to techniques such as Test Driven Development.

Believing that it's important to keep up with technical skills, I also write a lot of code. Examples are the HtmlUnit unit testing tool written in Java™ and the Literary List site written in Ruby.

I am a speaker at a variety of events from international conferences such as Colorado Software Summit to local user groups such as XP Toronto and the Toronto Java™ Users Group. A list of my most recent public appearances can be found here.

I am an active member of the IT/business community. I have provided leadership to both of the Agile user groups in the Toronto area [XP Toronto and Scrum Toronto]. I am a member of the Durham IT Association and the Whitby Chamber of Commerce.

Why might you want to hire me? You might want to hire me if one or more of the following are true:

• You feel that your development team should be capable of more but you're not sure how to accomplish that
• Your project has a run-away bug count and you want to get that under control
• You are generally not satisfied with the quality or timeliness of the delivered product
• Your development team has been working hard for a long time and has no working production code to show for it
• You would like help implementing Scrum or XP in your organization

I'll be available for new consulting work starting on Monday April 3, 2006. If you'd like to talk more specifically about how I could help your company then send me an email at mbowler@GargoyleSoftware.com or call my cell at (416) 822-0973.

One practice used by most Agile teams is the daily status meeting. This is a short meeting held once a day for the purpose of keeping the team on track.

Meetings should be no longer than one minute per person on the team. So a team of five should take no longer than five minutes per day on these meetings.

Every person in the team will briefly answer three questions.

1. What did you do yesterday?
2. What do you expect to do today?
3. What obstacles are in your way?

The questions are deliberately simple and yet surprisingly effective. Nobody wants to admit that they didn't do anything the day before so the simple act of having to state what you did will motivate the team quite a bit. I've experienced this first hand and have heard from other people who have experienced the same.

It is the responsibility of the lead/coach/scrum-master to capture and deal with any obstacles that the team identifies. These obstacles could be anything from "we don't have enough computers" to "I haven't been able to get ahold of the business people to clarify some of the requirements".

I coached an XP team many years ago where everyone was co-located in the same room and everyone always knew what everyone else was doing. I questioned whether I should force the team to continue the daily meeting since there was really nothing new being brought up there that wasn't already known by the whole team. I brought this up with a number of very experienced coaches and the answer was a fairly consistent "yes". There is value in having each member of the team say aloud what they have been doing. This encourages communication and helps with the confidence of the individual members.

Some teams do this as a "standup" meeting where everyone is forced to remain standing for the entire meeting. This is done to ensure that the meeting moves along smoothly. If everyone sits down and gets comfortable then there's a tendency to move the meeting along a little slower. On the other hand, if everyone is forced to remain standing then everyone will keep it quick so that they can wrap the meeting up quickly.

Today, the daily meeting is one of the first practices that I suggest to a team that's looking to improve. Many projects that I see will have lengthy status meetings once a week or once every other week. Changing the schedule so that you have more frequent, much shorter, meetings will provide a significant benefit.

Waterfall 2006 is an amusing parody of the Agile 2006 conference. Check it out.