Solving problems with innovative solutions is fun, exciting and rewarding. Yet, being told what to do is generally boring and not very motivating, but why is this? Why exactly do some ways of working seem enjoyable and satisfying while others the total opposite? Well, the explanation involves chemistry and electricity.

I had coffee today with Dr Michael Aucoin, author of Right Brain Project Management, that I have discussed previously. He has been in Banff working on his new book and we chatted about empowered teams and productivity.

He explained that simply presenting work as questions rather than statements can engage mental models that make work more engaging, rewarding and in turn productive. More and more research on the brain is showing that we are hard-wired to reward ourselves for solving problems. Thinking about this, it makes sense, evolution rewards problem solvers and so an appropriate response is to make it feel good so that we continue doing it.

When we solve a problem and get that “ah-ha” moment, pleasure circuits in the brain light-up and endorphins are released that give us the buzz of solving the problem.  We also generate ownership for the solution and motivation to make it work, even if we encounter obstacles during the implementation. Contrast this level of enthusiasm with the prospect of having to do mandatory administration tasks or form filling. It is no surprise people enjoy working on empowered teams more than being directed exactly what to do, and some teams are orders of magnitude more productive than others.

So, as a project manager looking to increase productivity and motivation, is it simply a case of posing all work as questions and problems to be solved?  Obviously not, asking “Can anyone get our time recording entered?”, “Or, how can we write up these meeting minutes?” is likely to elicit the deserved response of “Yes, you need to stop wasting our time with dumb questions and do it!”

However, most projects could greatly benefit from engaging people’s problem solving skills and the motivation from solution-finding. Rather than over analyse difficult problems and prematurely decompose complexity into simple tasks, instead invite the team to find solutions. Make use of people’s problem solving skills and increased motivation it brings to create a more rewarding environment.

Is this manipulation, a mind trick to get people to work harder? I don’t  think so, instead a more insightful and respectful way of engaging a team. After all “We manage property and lead people. If we try to manage people they will feel like property”. Research on the brain is helping us understand what we instinctively feel. I am looking forward to Mike’s next book and learning more about working smarter.

Zombies and Project Managers; to many people the images are synonymous, fools blindly shuffling from one goal to the next. Not too smart, but a major annoyance if you are trying to get somewhere, or get something done.

Yet, as a project manager I have a weakness for zombie films, they appeal to my inner urge to cut down those who impede progress or just don’t get it. I know you can not really do that, and these feelings are more likely a reflection on my inability to communicate effectively, but none the less, a socially acceptable demographic for outpourings of frustration seems to have wide appeal, and box office success.

So, other than some people thinking project managers are lumbering dullards, and this one occasionally thinking of chainsaws, what does the film Zombieland and project management have in common?

• The Insecurity Complex
• The Goal Obsession

In the film comedy Zombieland two mismatched characters team up to survive zombie attacks, find love and pursue a goal. Our hero is Columbus, a socially awkward young man who’s obsessions and aversions in normal life had made him a lonely misfit, now keep him alive in a time when most people have succumbed to zombies. His partner is Tallahassee a hard hitting, shoot first ask questions later, type guy who is driven by an overwhelming desire to find the world’s remaining supply of “Twinkie” cakes.

The Insecurity Complex

An Insecurity Complex is a common feeling for new project managers. Linda Hill describes it well in her book “On Becoming a Manager”. She explains how people who did well in technical and sales roles often struggle and experience “Self-Doubt” when first in a management position.

The conference was very good, and had the general theme of “Agile Grown Up”, focussing on the organizational impacts of using agile. This may not have been as much interest to technical people, but was right up my street. On Tuesday there was a great session about agile at Nokia where 1800 software developers are using agile to develop the Symbian mobile phone platform. They are using a version of Dean Leffingwell’s “Agile Train” approach for scaling agile to such a large team and most agile practices, but not pair-programming or emerging architecture. However, the main emphasis was beyond the technical process scaling and more on the ongoing coaching, mentoring and training that is required for such a large undertaking. In a discussion with the presenter Simon Buck after the talk I learned that they aim for one full time coach/trainer for each set of 5 Scrum Teams (each about 7 people). Quite the undertaking.

IQ (Intelligence Quotient) and IQ tests that attempt to measure intelligence are well known. However, IQ is not a good predictor of how successful you will be in life, or how effective and valued you will be at work.

Emotional Intelligence (EI), often measured as an Emotional Intelligence Quotient (EQ), is a different measure that describes the ability to identify, assess, and manage the emotions of one's self, of others, and of groups.

“Research shows convincingly that EQ is more important than IQ in almost every role and many times more important in leadership roles. This finding is accentuated as we move from the control philosophy of the industrial age to an empowering release philosophy of the knowledge worker age.” - Stephen Covey

So since software is a knowledge worker activity, and agile methods promote an empowering release philosophy, for leaders of agile projects EQ is of special importance. How can we measure our EQ? Well Martyn Newman’s Emotional Capital Inventory (ECI) is a great place to start. This online assessment scores participants against the 10 EQ dimensions of:

1. Self-Awareness
2. Self-Confidence
3. Self-Reliance
4. Self-Actualization
5. Assertiveness
6. Relationships Skills
7. Empathy
8. Self-Control
9. Flexibility
10. Optimism

LeadingAnswers.com readers are invited to take the short version of the assessment for free, just follow this link. Free Emotional Capital Inventory Test.

I recently read an early release copy of Martyn Newman’s “Emotional Capitalists: The New Leaders” book and was impressed. Several years ago I finally realized that successful projects are more about people and less about processes and tools. A Computer Science degree and 20 years of technical experience had not equipped me for the role of managing teams. Since then my studies have been focussed on the higher leverage area of people and team dynamics more than project management mechanics. You definitely need the mechanics to run projects, but usually the final outcome comes down to people.

Reuven Bar-On was amongst the pioneers to write about Emotional Intelligence and Daniel Goleman helped bring the subject to the business world with his Emotional Intelligence best seller. I liked these books and agreed with all the points raised, but often finished a book without a clear action plan for what I should start doing differently tomorrow.

What I like best about Emotional Capitalists is the practical nature of the advice given. Not only are the concepts explained clearly with entertaining stories, but each chapter is followed with a one page action plan summary, the advice is very accessible whereas some other books on EQ are more theoretical.

Bad News and Good News
The bad news is your IQ peaks in your teens and from there on declines. The good news is that IQ is not a great predictor of happiness or success anyway, EQ is a better predictor of these, and EQ peaks in your late forties and early fifties so we have more time to practice and improve.

(As an aside, I think it is interesting how in our optimism we gravitate towards metrics that suit our circumstances. We are getting older and not any smarter, but hey, that’s OK, here’s a different score that we look better against! Maybe this is being wiser rather than smarter. Since turning forty my chances of running a sub 3hr marathon or sub 36 minute 10K again have approached zero, however I now use Age Weighted Scores and, problem solved, I’m not getting slower (well I am) but I can now compare my times against others my own age and use that as a metric for performance.) 

Anyway, have a look at the assessment, if nothing else it will familiarize you with some aspects of Emotional Intelligence that are critical to being successful today. Thanks again to Martyn Newman for giving a free trial of the tool for readers of this blog. The book covers many great topics that I plan to write on in the future, but for now I will end with some of my favourite quotes:

"You can’t lead a cavalry charge if you think you look funny on a horse" - John Peters

“Before you are a leader, success is all about growing yourself. When you become a leader, success is all about growing others" - Jack Welch

“Nothing splendid has ever been achieved except by those who dared believe that something inside them was superior to circumstance” - Bruce Barton

"If leadership is ultimately the art of accomplishing extraordinary things with ordinary people then building emotional capital is how you achieve it" – Martyn Newman

On May 15 I presented on “Decomposing large programs into agile projects” and “Mapping the PMI Processes to Agile Best Practices” at the Calgary APLN meeting. I have uploaded the slides in PDF format and also a zip file containing the hyperlinked Process Groups / Knowledge Areas mapping to Agile practices. (You will need to unzip the PowerPoint slide and Word files into the same directory for the hyperlinks to work correctly.)

Calgary APLN May 15 Slides.pdf

PMI Agile Mappings.ZIP

The timing of the presentation was very close to Michele Sliger and  Stacia Broderick’s release of their new book “The Software Project Manager's Bridge to Agility”. I was hoping we could give a copy of their book away as a door prize, but the book was available about a week too late. However, I received a copy this weekend (thanks Michele, Stacia) it looks good and I look forward to reading it. We also have some copies on order as door prizes for future meetings.

I have been traveling and training lots recently and not had much time to post new entries here.

However, the travel time has allowed me to read more and two books I am current enjoying are Leadership Agility by Joiner, Josephs and A Leader Becomes a Leader by J. Sheehan.

Neither is specifically about Agile methods, but both highlight great ideas that are universally applicable. I will post complete reviews when I have finished them.

My traveling and training courses continue next week when I will be teaching a public 2 day Agile Project Management course in Scottsdale for the PMI. I will be repeating it in Seattle May 20-21 and Washington D.C. August 11, 12.

Other public courses coming up include a 1 day in Sacramento June 20 and a two day in Anchorage September 11-12. These courses are proving popular (Scottsdale and Seattle are sold-out) but I also offer private courses that can be tailored to company requirements. Please see here for a full list.

Once the Scottsdale course is over I will resume regular postings here.

There are some great books on agile team dynamics nowadays. My personal favorites include:

• Collaboration Explained by Jean Tabaka
• Agile Retrospectives by Esther Derby, Diana Larsen, Ken Schwaber
• Right-Brain Project Management by Michael Aucoin
• Great Boss Dead Boss by Ray Immelman
• The Blind Men and the Elephant by David Schmaltz

The problem is that most people do not get the time they want or need to read about these topics. So, I have created the following: Top 10 Team Practices list and one-page printer friendly version to remind us of some of the basic points.

If you lead a team then print the sheet and post it somewhere visible and do a mental inventory of the practices from time to time. If you are a member of a team that could do with a boost, print a copy and post it on your manager’s wall, I am sure they will thank you for it! (actual results may vary.)

1) Empower them – By giving control for local decision making and work sequencing to the team we gain the advantages of additional insights, better motivated teams, and more practical plans with less waiting. 

2) Listen to them – The team is closer to the technical details of the project and also best placed to determine the most successful solutions to project challenges and problems. Encouraging the team to solve the project problems has two main benefits. It demonstrates they are valued for their insight as well as their output, which makes people feel more involved and appreciated. Also, solutions suggested by the team are more likely to be embraced and executed with enthusiasm. It is better to have a 70% optimal solution executed with 80% enthusiasm than a 100% optimal solution executed with 40% enthusiasm.

(The “Balanced Blend” Manifesto takes Shape)

Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.

Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.

We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur.  Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.

In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.

Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.

The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.

Last week’s Calgary APLN meeting was on Team Collaboration and afterwards an attendee volunteered a really neat and useful team assessment questionnaire. Gerard Meszaros (author of XUnit Test Patterns) who also has strong project management and team collaboration knowledge, presented on “Using Collaboration to Build Team Commitment”. It was a great presentation and referenced some of the Jean Tabaka’s work from the book “Collaboration Explained”.

I have known Jean since her facilitation work with DSDM in the mid 90’s and she really knows about teams, motivation and working effectively with people. Chapter 4 of her book talks about characteristics of high performance teams. After the presentation, Edgardo Gonzalez sent me a spreadsheet based on these criteria that allows quick and easy team assessments.

As seen from the screenshot above, the tool is a one page Excel sheet that assesses the team’s abilities in:
• Self Organizing
• Empowered to Make Decisions
• Belief in Vision and Success
• Committed Team
• Trust Each Other
• Participatory Decision Making
• Consensus-Driven
• Constructive Disagreement

In our example of a fictitious project, four people completed the questionnaire. The collective team score is shown on the left hand radar chart (indicating a weakness in the “Consensus Driven” field) and the individual scores are shown on the right hand radar diagram. Colour coding flags areas as “Red” for concern, “Yellow” for warning (“Trust…” in the example), and “Green” for good.

Not only is the spreadsheet an effective team diagnostic, but a good lesson in Excel spreadsheet formatting and validation. Thanks Edgardo for agreeing to make this available to everyone and to Gerard and Jean for their work in this important field.

You can download the spreadsheet for your own use below:

Collaborative Team Assessment.xls

Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.

It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.

Nearly three years on, why is the Declaration Of Interdependence (DOI) still not widely known or referenced?

The chances are that most readers will not be familiar with the DOI, yet it is a great piece of work. The DOI lists principles that, like the Agile Manifesto principles, help point the way for teams working on agile projects. It was created by the founders of the Agile Project Leadership Network (APLN) to guide agile project management and rally support for an uprising of new project management thinking.

Other than believing some of the wording was a little too clever for its own good and general consumption. I did not fully understand why it had been avoided. Then I read “Made to Stick” by Chip and Dan Heath and I realized that it has the stickiness and appeal of a greased electric eel.

Last week I attended an excellent presentation on “Right-Brain Project Management” by Dr Michael Aucoin. I attend lots of presentations during the course of a year, mainly at North America events but a sprinkling of international conferences too, and few presentations stand out as being excellent. This one was exceptional from the content (that connected some loose ends in my Agile-Leadership-Project Management mental model) to the materials and delivery.

So, what was so good about it and what does it have to do with Agile Leadership? Well it outlined a parallel view of project management that supports and reinforces agile leadership and fills in some gaps along the way.

Michael started off by talking about today’s Stretch projects. He defined a Stretch project as a project that causes traditional project management challenges. They are characterized by:

• Schedule challenges and resource challenges
• Ambiguous specifications
• Dealing with new technology, new groups, new people
• Dispersed teams
• Many mid-project scope changes
• Challenging people issues

In these circumstances the old project management approaches that are good for predictable projects break down. Michael did not use the words Traditional and Agile, but he might as well have been giving an agile presentation because through his research he had arrived at the same conclusions, but interestingly, offered additional insights.

Why Does Project Management Fail?
Many people are frustrated by the mismatch between project management theory and its application on real-life projects. This is due largely to trying to employ approaches designed for predictable projects on today’s Stretch projects and seeing them come up short.

Yet, in many walks of life outside of project management, people succeed in unpredictable environments everyday. Doctors, farmers, and teachers all work in difficult to predict environments yet, on the whole, are successful. So why do project manager’s struggle with stretch projects? There are three main reasons.

1. Mismatched project model and environment
2. Projects lack emotional involvement
3. Personal challenges created by stretch projects

Let's look at each in turn...

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.

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.

The next CAMUG meeting looks very interesting. Jonathan Kohl will be presenting "Don't Drink the Kool-Aid! Avoiding Process Pitfalls". Here is an excerpt from his presentation outline:

“… merely applying an Agile (or any other) process is not a guarantee of success. As with anything else in life, there are trade-offs, and unintended consequences when applying a tool or process. This talk will explore some common Agile process practices that may work well in some contexts, and have unintended consequences in others.

The intention of this talk is to encourage us all to keep striving to build the best software we can. It's tempting to think we have the formula for success, but in a rapidly changing industry, we must adapt and change accordingly. “

Amen to that, there is no standard recipe for successful projects, instead, as the DOI advises, solutions need to be “context specific”, or as Alistair Cockburn reminds us, a new methodology per project.

This is not to say we should discourage passionate implementation of agile methods. Following my Agile Project Management Assessment Quiz post I was contacted by Simon Baker of Think Box who scored an impressive “Uber Agile” score. You can read an account of his project team practices and successes following the quiz and I commend him and his team on their work.

Rather, the point I want to make, is that our intent should focus on successful stakeholder engagement and better software. If this is achieved via agile methods then great, or if, say, via better communications, then so be it. We run the risk of ignoring the “Individuals and Interactions over processes and tools” value if we focus only on process.

For the last couple of months I have been reviewing draft chapters from Preston Smith’s new book “Flexible Product Development” due to be published later this year. I met Preston through the APLN board and I have learned a lot from reading the draft chapters. A portion that really hit home for me was his description of people over process...

Jim Highsmith recently posted a reference to a CIO Magazine article entitled “30 Books That Can Make You a Better Leader”.

Jim was floating the idea of an APLN recommended reading list which I think would be a great resource and discussion point for the group. I hope it happens and have volunteered to help get it started.

In the mean time, it got me thinking about what books I would recommend. The CIO Magazine’s recommended list was...