In April I will be leaving Quadrus Development to go independent again. I have found an interesting contract at local company, Husky Energy, where they have an agile project to manage and some other interesting initiatives underway and I am looking forward to my new role.

End With the Beginning in Mind
I have been at Quadrus for over six years and I enjoyed my role there tremendously. Someone very wise (Christopher Avery) once told me that when a relationship comes to an end that you should always End With the Beginning in Mind i.e. remember the reasons why the relationship started in the first place and focus on these points when wrapping up. Not only is end-with-the-beginning-in-mind, a great twist on Stephen Covey’s "begin-with-the-end-in-mind", it is also very wise advice I wish I had appreciated when I was much younger.

In his book “Teamwork is an Individual Skill”, Chris says the following about ending partnerships:

“…people so seldom end relationships well. Maybe because we all want so much to win - and endings are associated with losing. Maybe it’s because we are embarrassed that we don’t know how to derive any more benefits from a partnership. Maybe we are embarrassed because of un-kept promises, real or imagined…endings are as inevitable as beginnings and we can improve the quality of endings by avoiding three things:

1) Burning bridges
2) Harming reputations
3) Being inhumane to oneself or others”

Chris then goes on to recommend some positive steps that include:

"1) End the collaboration by bringing to mind the positive intentions and positive results that the partnership produced.
2) Thank your partners for the opportunities, results, and trust they provided you.
3) …"

I think this is great advice, and personally think back with fond memories of when I started at Quadrus. Having enjoyed several years holidays snowboarding and hiking in the Canadian Rocky Mountains, my wife and I decided to emigrate to Canada. It seems foolhardy now, but we both quit our jobs, sold our house in England and moved to Calgary without new jobs to go to. I was fortunate to interview with Quadrus my second week in Canada and was offered a position the same day.

Quadrus took a chance hiring me and I am very grateful for that, I arrived here with my PRINCE2 project management certification that no one had heard of and quickly sat my PMP exam to at least gain some traditional project management accreditation. Fortunately my methodology experience was more transferable, with RUP, Scrum, and XP being well understood in Canada.

I had some cultural challenges as Canada and England are two nations separated by a common language. I learned how to “get my ducks in a row”, “ramp” on new technologies and avoid “kack” while explaining how long a “fortnight” is and what “knackered” means.

Quadrus encouraged me to develop training courses, speak at conferences and publish articles. Without these opportunities I would have missed meeting so many smart people and becoming enthralled by research and lifelong learning. Quadrus has a great set of dedicated IT professionals and I will miss their skills and community.

Other Items, Business as Usual
While I am changing my 9-5 job, my other activities will continue. Quadrus has agreed to continue hosting the Calgary APLN Drupal web site and I look forward to seeing Quadrus folks at future APLN meetings. I will still be writing articles for the Agile Journal and Gantthead and continue to be actively involved with the Agile Alliance, the APLN, CAMUG, and Cambrian House. I will still be presenting on Agile Project Management at Agile 2007 in August and the PMI Global Congress in Atlanta this October. Not least of course, I will continue blogging here, so there will be no end to totally biased leadership and project management ideas.

I will be having some leaving drinks in Ceili’s (803 8th Avenue) on Friday 30th at 4:30pm, anyone who knows me is welcome to drop by for a beer if you are in the neighbourhood.

In this post I outline some really useful techniques for planning releases and iterations. They are adapted from a great book called “Innovation Games: Creating Breakthrough Products through Collaborative Play" by Luke Hohmann

Some thoughts on the term “Games”
I have never been a fan of suggesting the use of “games” in the enterprise workplace, as in XP’s “Planning Game”. The term does not sit well with some traditional-type folks; to them it sounds unprofessional and not serious enough for important work. Yet the Innovation Games described by Hohmann are high performance facilitated workshop exercises that produce great results. If the project is serious enough to engage busy stakeholders then I think we owe it to the business to use the most effective tools at our disposal. If calling them “facilitated workshop exercises” eases their acceptance then I’m all for it, because it is the results I’m really interested in, not so much what we call them.

The Games
In Luke’s book, he outlines a number of games (exercises) that can be used in a variety of settings. Some like “Design the Product Box” and “Buy a Feature” are probably familiar to many people working on agile projects, others will likely be new. To keep this post a reasonable length I will focus on adapting three exercises for use in release and iteration planning.

The three we will look at are “Remember the Future”, “Prune the Product Tree”, and “Speedboat”.  I use slight variations on the last two, I call them “Shape the Product Tree” and “Sailboat” and I will explain the differences when we get to them...

The next Calgary APLN Chapter meeting is on April 10^th and will feature Ross Martin and Lynn Harrison from Black Tusk Leadership speaking on: "Team Motivation: Working Inside the Egg". See www.CalgaryAPLN.org for a full description and registration details. This promises to be an interactive and entertaining talk that emphasises the importance of listening and motivation within teams.

I first met Ross when I attended a "Leadership Challenge" workshop last year. Ross was an invited panel presenter and he impressed me with his knowledge and humble demeanour. I met up with Ross for lunch shortly afterwards to ask him some leadership questions and we got talking about his job as an executive coach and leadership consultant.

Ross explained that he spends a good portion of his time coaching company executives in leadership techniques and providing feedback. As we talked I could not help thinking that this sounded like nice work if you could get it, but a little soft, "foo-foo" and fuzzy, so I asked some more questions. Ross said that the best way to understand what coaching involved was to experience it and offered to give me a 10 minute session there in the restaurant. So that's what we did, and boy, it explained it well.

Ross asked me what my biggest work concerns were and I explained rather than any particular project, I was thinking hardest about what I would like to do with my career. Ross then asked, for this biggest concern, what had I done to try and solve it, and how much of my working week was I dedicating to it. I was embarrassed to admit that while I claimed it was the most important thing, I was doing a pretty lousy job of addressing it. We reviewed each of my options and work done investigating them so far and, in a very nice way, Ross was able to get me to realize that there was a lot more I could do and helped outline a roadmap.

From this and other discussions, I went from being an entertained sceptic to an enthralled convert faster than I can remember. The cynic in me may have thought that this must have been a one-off trick or "Vulcan-mind-meld", but I really think that a leadership coach who knows their stuff can be of tremendous help.

So, get along to APLN the talk if you can, Ross and Lynn have great insights to share and their topic: "team motivation" is an important subject area for all of us.

(Achieving successful change)

In Part 1 we looked at the W5 (Why, Who, What, When, Where) of introducing agile methods into an organization.
Part 2 dealt with why change is difficult, resistance to change, and when people do accept changes.

Today in Part 3, I will introduce a change framework to effectively implement agile methods (or other organizational changes) with less opposition.

Let’s recap the circumstances where people will accept changes:

• When the change is seen as a personal gain: in security, money, authority, status or prestige, responsibility, working conditions, achievement

• Provides a new challenge and reduces boredom – when we create more interesting work

• Opportunities to influence the change initiative – when we involve people in the changes

• Timing: the time is right for organizational change

• Source of the change initiative is liked and respected

• The approach of the change and how it is implemented appeals to us – when they buy into the approach being taken

These are the conditions we need to establish in order to stand a chance of having our change accepted. It is interesting to note that they are all personal, human-centered circumstances. There are no “When the change is awesome”, “When the change will reduce production costs by 60%” type conditions. Yet these are the types of drivers people try to use to introduce agile methods and then fail.

Mistake #13: Missing the personal side of the change initiative.

As a logical, rational person it pains me to acknowledge it, but as with making purchasing decisions, we make up our minds in our hearts first, and then rationalize it with our brains. The same goes for accepting changes, we must first go for the hearts by crafting a caring, inclusive, compassionate change environment and then follow it up with some sensible changes.

"...we must first create a caring, inclusive, compassionate change environment and then follow it up with some sensible changes"

(Weird cults and religions learned this years ago, if you are nice to people and actually pay them attention (love-bombing), they will be grateful and a certain percentage will even give you all their money. However with cults, most people later realize they have been “had”.)

I am not suggesting we use love-bombing or subliminal messages to introduce agile methods. We do however need to understand that a key component for change acceptance is the human side of introducing the change. The best changes in the world will meet resistance and take longer to accomplish if they are implemented without regard to the human side of change.

A Roadmap for Effective Organizational Change
So, we need to consider both strategic and human related steps and follow a proven route to effective change.

(Understanding Resistance to Change)

In Part 1 we looked at the W5 (Why, Who, What, When, Where) of introducing agile. Today in Part 2 we will look at Challenges and Resistance.

In Part 3 I will introduce a change framework to effectively implement agile methods (or other organizational changes). However, before I get to that we need to look at why change is difficult and why people resist change.

Change Challenges
As a believer in agile methods and someone who had witnessed the benefits they can bring and the great buzz of an effective agile team, I used to think rolling out the methods would be a no-brainer.

Mistake # 8: Underestimating the resistance to change.

Wrong, achieving successful lasting change is difficult. Changing processes is even harder because a process is a system designed to resist change. Think about it, if every new type of requirement or defect that came along required a change to our development process we would be in trouble. So processes are these abstract funnelling techniques that were deliberately designed to resist change, which makes throwing them out or morphing them, more difficult than changing, say our time recording system.

“…a process is a system designed to resist change”

In fact there are a number of challenges:

Achieving lasting changes is difficult

• While people may be willing to try something new, it is a whole other story to get them to switch to it completely. Many a promising start has reverted back to the old way of doing things.

People are unlikely to blindly accept new approaches

• People need to be convinced of the benefits of a new idea before they are willing to invest the effort of having to learn it. Many adults do very little learning, they just want to understand the easiest happy-path through their regular work day and stick to that. For some people, asking them to think, learn and adapt to new methods in addition to doing their job is like increasing their work load while keeping their pay the same – not that appealing.

Resistance to change is normal and healthy

• We are bombarded by so many new ideas, goods and services it would be anarchy if we just adopted every new thing that came along. We need stability, standardization and norms to function properly. This also acts as a filtering mechanism that saves people from having to think about every new thing. They believe that the good stuff will stick and the poor ideas will fade away. Unfortunately some organizations are good at marketing crap, and some great ideas miss their mark, but on the whole we get by.

So we need to plan for resistance and have strategies in place to ensure worthwhile changes occur. Just explaining how agile methods are better is not going to ensure the whole scale rollout and adoption by an organization.

Mistake # 9: Think people will want to adopt agile methods because they are better.

(Understanding change)

I was contacted by a reader recently who was enquiring about practical ways to introduce agile methods into their organization. I suggested the book "Fearless Change: Patterns for Introducing New Ideas" by Mary Lynn Manns and Linda Rising as a good reference for successful change introductions, but drew a blank with blogs on the subject. So I thought I would write up my experiences and suggestions in a short series of posts.

Having being involved in the creation and roll-out of DSDM in 1994 and engaged on agile projects ever since, I have been exposed to a wide variety of process change initiatives, many of which had some pain-points. It is probably fair to say that if there are process introduction mistakes to make, I have made them, but I am (slowly) getting better and think I can guide people around a lot of the common pitfalls now. So, if you are currently introducing agile methods to an organization save yourself some grief and at least learn to avoid the problems I encountered.

Part 1 will introduce the W5 (Why, Who, What, When, Where) of introducing agile.
Part 2 will outline change challenges and explain why people resist change.
Part 3 will explain a cohesive strategic and human oriented change process and provide introduction tips.

Why Change?
First of all, with any change initiative we should clearly understand why change is necessary. If an organization is having success with their existing process (be it formal or chaotic) I would question the need to introduce a new methodology. Instead perhaps our efforts could be best used addressing incremental improvement. I’m not an agile zealot who will not rest until the world adopts agile everywhere. I think it is a much better way of working for most organizations and projects, but no panacea or silver bullet. Switching to agile because your CIO read a magazine article on Scrum, or because it is cool, is not a good reason and a weak driver to push beyond the inevitable obstacles of a successful, complete implementation.   

So, Mistake # 1 is: Introducing Agile without a clearly understood, agreed to, and articulated need. 

Last week I attended a great presentation by Don Tapscott author of “Wikinomics: How Mass Collaboration Changes Everything”. It was organized by Cambrian House (full disclosure: a company I have an investment and advisory role at) and spoke to the rise of peer collaboration over command-and-control management shown by the explosion of user-generated content sites and new work models. For me it generated some “ah-ha” moments and connected several ideas related to agile methods and new organizational structures.

Don Tapscott writes ahead of his time (either that or I’m just slow on the uptake), in his previous book “Growing Up Digital: the rise of the Net Generation”, he explained how modern generations are growing up comfortable with new communication methods. Instead of gamers and internet junkies having poor communication skills and few friends, most youngsters who use the internet have stronger social networks, large groups of friends (Facebook, MySpace) and can readily connect with others of similar interests. As I wrote in my post on Verifying Motivators the Gen. Y and Millennial generations value “feeling in on things” and “social values” more than say, “job security” and “good working conditions”.

People (especially younger workers) want to work on agile projects because techniques like empowered teams, increased communication, and shared leadership better match their internal values of inclusion, openness, and equality. When we align working practices with individual values we getter better involvement and commitment. Try to engage team members with a misaligned model and you will see poor commitment, detachment, and resistance. This is not just naive idealism either, youngsters have a healthy scepticism and a good radar for BS, spotting phoney claims and representations that often fool the majority of older workers.

Another of Don’s books “The Naked Corporation: How the Age of Transparency Will Revolutionize Business” addresses how tools like the internet make it almost impossible for organizations to hide dodgy dealings and bad behaviour. People communicate and share information more than ever and organizations will need to be more open and transparent in their practices in order to prosper in the future. Innovative companies like Semco described in "The Seven Day Weekend", use worker empowerment, collaboration and total transparency to attract the best talent and successfully blaze trails into new markets.

Agile projects practice "naked metrics" and process transparency. No longer is project status hidden behind process phase names like “in analysis” or “75% through coding” that mean little to most project stakeholders. Instead business features are delivered and demonstrated at the end of every iteration. The customer and business are included within the team and development process. To some this can seem good and bad; good when things are going well as the business can sing the praises of the project, but bad when things go wrong or progress is slow. However, we all know that sharing bad news, while hard, is best done early too. When project velocities indicate that the project will not be done on time, or unanticipated feature complexity is causing rewrites and problems, often the business folks on the inside have power and credibility with the project sponsors that is hard to achieve. Once they see that the team in not jerking around, but working hard and some stuff takes a long time, they can be great allies in scope and budget discussions.