LeadingAnswers: Leadership and Agile Project Management Blog

The APLN Seattle Leadership Summit

The APLN Seattle Leadership Summit is shaping up to be quite the learning event. Here are some of the highlights:

• Collaboration Games by Luke Hohmann and Allan Shalloway
• Kanban by David Anderson and Corey Ladas
• Scrum by Brent Barton and Lance Young
• Getting Started with Agile by Mitch Lacey and Julie Chickering
• Writing Agile Contracts by Bruce Eckfeldt and Jim Benson
• Agile Program Management by Mike Griffiths and Mike Cottmeyer
• Real Option Theory by Chris Matts and Olav Maassen
• Agile User Experience by Arlen Bankston and Jeff Patten

The program also includes two leadership keynotes by:

• Lisa Haneberg, author of seven books including 10 Steps to Be a Successful Manager and Two Weeks to a Breakthrough.

• John Yuzdepski, a partner at Management Concepts LLC specializing in product transitions and commercialization of new technology and a veteran of the mobile communications industry.

While I am involved in facilitating a session on Agile Program Management with Mike Cottmeyer, my real motivation for attending is to hear the other speakers present.

I am a big fan of Luke’s work on Collaboration Games and posted on it previously here. As too with David’s work on Kanban here and Jim’s work on Agile Contracts here. I know Mitch Lacey does a great job of explaining agile and I was introduced to Real Options as a reviewer of Preston Smith’s Flexible Product Development book and want to learn more.

(I’m sure Mike Cottmeyer can handle the session by himself, I think I’ll be sneaking out to attend some the other sessions!)

So, if you can get to Seattle July 17-18 I recommend the event as the best value agile project leadership training you will find this year. $300 for two days of leading edge knowledge and experience is excellent value (plus you could claim 16 self-directed-learning PDUs too, if you need PDUs).

Travel and Training

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.

Top 10 Team Practices

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.

No Glory in “The Middle Way“

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

Agile 2008 Submission Review Marathon

Phew, I am done! We had over 120 submissions for the Agile 2008 “Leadership and Teams” stage which is a great response. However at about 5-10 minutes each to read the bio’s, proposal and submit a review it adds up to a large evaluation effort. Here’s how the stages and numbers broke down:

Collaboration Tools

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

Agile Project Leadership and More on Accreditation

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.

We Don’t Want User Input!

Do you really need those pesky users on your project, forever changing their minds and requesting new functionality just as you are about to be done?

When I was at school, my physic’s teacher was fond of telling us that, "if it were not for the students I would enjoy teaching." The same is true for users, they may cause us issues and headaches, but they are the reason we are there and developing software in the first place.

Why we Need User Input
The truth is that on agile projects we do not want user input we actually need user input in order to be successful. Agile projects are deliberately light on capturing initial requirements because we realize that requirements are likely to change, and evaluation of an emerging system will surface new requirements and improvements to existing requirements that we want to encourage.

Agile 2008 – “Leadership and Teams” Stage

This year’s Agile conference in Toronto this August will be structured slightly differently. Following a music festival structure, the conference will be divided into “stages” to cover different topics. I was able to visit the Agile 2008 conference venue in December when the last Agile Alliance Board meeting was held there and we toured the facility with the Agile 2008 Conference Committee.

Johanna Rothman and I are the “Leadership and Teams” chairs for the conference and we have been allocated a great venue; a large, bright ballroom with high ceilings and lots of natural light. This year the conference has much more space and larger mingling areas both indoors and out which I am sure will help.

On the “Leadership and Teams” stage we are looking for submissions on, you guessed it, leadership and team focused experience reports, research papers, tutorials, and presentations. Now is a great time to submit a proposal, so take a look at the submission system and propose your ideas.

The other element I am excited about is the submission system selection process. I have written previously about encouraging the agile community to prioritize our proposal backlog (list of submissions) and this year it is happening. On the Drupal based submission system anyone can write a review for a session and “up-vote” or “down-vote” a proposal. The cumulative scores for proposals help determine what gets selected.

This will not be a totally crowdsourced selection (like ideagora: Cambrian House), instead panel review will still be involved, but it is great to see the conference users (attendees) involved in prioritizing the features (proposals) for the event.

So, head over to the submission system and up-vote your buddy’s submission, down-vote anything from that guy that won’t return your emails (only kidding) or better yet, submit something valuable on Leadership and Teams for the conference, we would love to see it.

Agile Project Leadership Training Course

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

Personal Agility – Free Webinar

Is agile about new tools and techniques or more a mindset? Philippe Kruchten asserts “agility is not a technology, science, or product but a culture”. This makes sense to me; innovation comes in waves (object oriented programming, business process engineering, lean production, etc); and while they all have their merits, most fail to deliver the full potential of their benefits because people concentrate on the process rather than the mindset. At the heart of agile is a mindset not a toolset.

I was speaking to Christopher Avery today, author of “Teamwork is an Individual Skill” and he shared some thoughts on personal agility and team motivation. Christopher is great for this since he approaches agility and team work from a psychological side whereas my thoughts are usually based on observation and trial and error.

We were discussing motivation and how to motivate peers who you do not necessarily have positional power over. Bosses may try to create motivation via carrot and stick approaches, but these are weak and short lived. People grow tired of such manipulation and find ways to break the system.

Instead, Christopher talked about “Intrinsic Motivation”, a more powerful motivation that comes from within.  People want to be on a winning team, but are not sure how to find or create them. The secret lies in understanding what “winning” means for others and then creating wins around you. In practical terms this means asking people “what is in it for them?” i.e. what is it they would like to learn, do, or gain (beyond a paycheck) from the project and then provide opportunities for these things to happen.

At first this sounded a little odd to me, a bit too touchy-feely. Asking people what they did over the weekend is one thing, but asking them what they want out of a project seems, well, invasive, too personal. However when you think about it, that is backwards, after all the project is something we all have in common. What they did with their spouse over the weekend, now that could be personal!

Telling someone what you really want to get out of a project might seem a little odd too, but fears of doing so indicate a ‘scarcity model’ to information. Why should we worry if people know what we really like to do or gain, chances are they will make opportunities available for us to do them. Helping others get what they want from projects creates an upward spiral of support and co-operation, which when you think about it, is the heart of a winning team.

Chatting to Christopher is always refreshing, he shares so much useful information that I struggle to retain it all. Fortunately for us Chris has recorded a free tele-seminar on Mastering Personal Agility. I heartily recommend it, the people side of projects have the greatest leverage, even small improvements here can yield large benefits; be sure to check it out.

The DOI, Made to Slip?

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.

Calgary APLN Planning Session

Last week we had the planning session for the 2007/2008 Calgary APLN Chapter. The goal was to create a prioritized list of topics to explore this season and demonstrate some of the values and practices of agile project leadership along the way.

We started by using the Speedboat game in small groups to identify impediments and propellers towards our goal of “Connecting, developing, and supporting great project leaders”. Speedboat is a group exercise for “Issue” and “Enabler” brainstorming that can be used with any group. It helps people to clarify goals, air their concerns, and suggest options for avoiding risks and moving forward. My colleague and co-host for the session, Janice Aston, wrote up these useful notes on using Speedboat and the outputs from the group.

Download Speed_Boat_Instructions.doc

Download Session_Results_10-17-07.doc

I previously wrote an account on Speedboat and other Innovation Games in an earlier post.

Following the Speedboat exercise we brainstormed presentation topics for the upcoming year. The thought process was: “Given the issues and enablers you just identified with agile leadership, what are the topics you would most like to see presented and discussed this year?”

Each group wrote ideas on sticky notes and we then posted them on the wall. Went through an affinity grouping exercise that sorted them into themed groups and removed duplicate suggestions. We all then went through a dot voting exercise where we assigned three votes among the topic suggestions. The topics and votes counts (shown in brackets) are shown below:

Agile In Atlanta – PMBOK to LWOK

I have just got back from the 2007 PMI Global Congress conference held in Atlanta, Georgia. It was a good conference and while I may question the applicability of traditional project management approaches for software development projects; for organizing a conference it is hard to question the results. I experienced no line-ups; good speaker support and a well thought out and organized conference.

My presentation on “Developments in Agile Project Management” was over subscribed and I was asked back to do an encore presentation which is a great endorsement for the level of interest in agile project management, especially from within the traditional PM community. When I presented on agile methods at the 2004 PMI Global Congress in Anaheim, I was the only presenter on agile methods there. Since then I have seen an increase year on year. Last year I counted four agile topics and this year six, which is a promising trend.

I met up with Mitch Lacey and Stein Dolan who were also presenting on agile methods at the conference and it was great to chat and discover we had a similar philosophy. This is that agile methods are merely additional tools for the project toolbox that work well given certain circumstances. They do not replace traditional methods, but instead can exist alongside them and can be used very effectively when the circumstances warrant. This is what Jim Collins calls” The Genius of the And” and the “Tyranny of the Or” by using a smart mix of traditional methods And agile we can better respond to project challenges and avoid the limitations of “either / Or” thinking.

It is good that the PMI is incorporating more agile content; lots of of today’s projects really need these techniques to be successful. Yet many agile practitioners are reluctant to take their message to the PMI, and prefer to focus on agile conferences. However as Henry David Thoreau reminds us “For every thousand hacking at the leaves of evil, there is one striking at the root” Not that the PMI is evil, but if we are to change the world of project management, then the PMI is a great place to start.

LWOK
My talk covered what’s new with Agile Project management and I was glad to be able to announce the Agile Project Leadership Network (APLN) LWOK program approved just a few days before.

While the PMI has its Project Management Body Of Knowledge (PMBOK) as its core set of agreed practices, little exists yet for agile project leaders. There are great resources scattered around different web sites, but no place we can point people to and say “go and start here, it will get you on your way”.

Right-Brain Project Management

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

Developing Authentic Leadership

Last night I gave a talk on “Agile Project Leadership” at the Calgary Agile Methods User Group (CAMUG). I like giving these because the questions raised make me re-examine elements of leadership and last night was no exception.

One question raised was basically “We hear about these ideas and they sound good, but in our projects the same old stuff keeps happening. How do we get real results?” I responded with some explanation about encouraging servant leadership, but in retrospect I think the underlying question was more about making the switch to authentic leadership rather than shallow imitations that bring poor results.

 

Some subsequent discussions with a couple of attendees have helped me straighten out my thoughts on the issue further. “Cargo cults” is the term used to explain the phenomenon of blindly replicating outward behaviour with the hope that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the war time aircraft runways, control towers, and radios out of wood in the belief that they would bring back the cargo planes that brought Western goods during the war.

 

The equivalent cargo cult leadership pattern would be to practice techniques like team recognition in the hope that it improves morale and productivity without understanding the work undertaken, or by presenting phony “well done’s” and insincere praise. People have excellent BS radars and phony praise is quickly recognized as attempts at manipulation and has the opposite effect as desired. Likewise mechanical-only attempts at creating a common vision, challenging the process, or creating empowered teams will fall short too. These activities require deep conviction or else they will falter and fade, making genuine attempts harder to introduce later as an “antibody effect” of mistrust develops in the team.

   

Popular Posts as PDFs - One year of LeadingAnswers

I have been blogging on this site for a year now and it has been lots of fun. With 82 articles and 33,000 visitors from 127 countries, I have made plenty of contacts that I would not have made otherwise and learned lots in the process.

A couple of people have commented that it is hard to print articles from this site and so I have created a separate page with some of the more popular posts as PDF documents for download or printing. Just click on the "Articles as PDF documents" link of the top right of this page.

Who knows what year 2 will bring, but I’d like to hear from you so I have added a “Suggest a Topic” email link too.  Drop me a line and if your topic catches my fancy I’ll write about it.

Thanks for reading.
Mike

How many volunteers do you have working on your project?

While your initial reaction may be “none”, I would assert that your whole team are actually volunteers and we can benefit from recognizing this and treating them accordingly. All that paying people does is ensure that they turn up (hopefully) and then once they are at work they must want to contribute or else very little will be achieved despite all the outward appearances of them “working”.

Attending the Agile 2007 conference in Washington and witnessing the passion of people engaged in something they truly care about and volunteering on programs with likeminded people got me thinking again about the productivity of volunteers and paid team members.

Team member contribution varies on a scale ranging from being a net drain on the project, all the way up to passionate innovation.

On the left hand side of this spectrum we have instances of people actually negatively impacting the project. Either intentionally or through misguided objectives and actions, their presence on the team actually has a net drain on project productivity.

The next region “Passive Compliance” people do generally work on to-do items, but without much thought and without any passion for the task or goal. Unfortunately “Passive Compliance” is an all too common category for team members in large organizations who feel like “cogs” in a machine they have very little say in.

New Agile Project Leadership Training Course

In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.

Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here

Developments in Agile Project Management - Part 3

Here’s the last instalment from my Developments in Agile Project Management Paper. Last time I wrote about Accreditation and Generation Y. Today I cover Leadership, Lean and Six Sigma, and Tool support.

    

You can download the full paper with the additional intro to agile and post-agile sections at the end of this post.

Be Enthusiastic – It’s Contagious

A couple of weeks ago I wrote a post called “The True Role of a PM on Agile Projects”. An attribute I did not include was “Be Enthusiastic – it’s Contagious” one reason for this omission is that it is a skill that I struggle with and I did not feel qualified to talk about. My style is more reserved and I have to go outside of my comfort zone to outwardly project my eagerness. However, the fact remains that it is an important role. 

If the leader of the project does not appear to show a passion for the cause then why should the other team members? Also the “- it’s contagious” portion is very important, as a social group team members easily feed off of each other’s energy levels. This is demonstrated by the presence or absence of those rare individuals who have the personality to be able to lift a group. When they are present everyone feels the lift and buzz, when they are absent there is hole, and everyone comes down a notch.

By introducing a positive, enthusiastic approach we nudge the team mood in the right direction. Nobody wants to work in pessimistic drudgery. We are happier, get more done, and overcome obstacles easier when people are enthusiastic. Obviously, it needs to be genuine and in character with your true nature. Some phony “Woo-hoo’s” will fool no one and undermine your credibility, but even if you tend to be quiet, true enthusiasm can be conveyed in the way in which you engage with the team and other stakeholders.

The reason I’m writing about this today is something I picked up last night from the PMISAC awards. Tana Goertz, finalist from “The Apprentice 3” gave a keynote speech that provided the tip “fake-it until you make-it”. Now I know I have just said we should not be fake when showing enthusiasm, but that was not her point. Tana’s message was that if you realize that something is important then you should do it, even if you struggle, until you can do it well. By practicing this awkward, but important skill, it will become easier.

Another take on this is, is “if something is worth doing, it is worth doing badly”, it took me a while to understand this oxymoron. However, it means if something is good and important we should try to do it (even if we are bad at it) because at least a little is better than nothing at all. (Another favourite oxymoron truism is “You lead people by standing behind them”, physically impossible, but correct in principle.)

So, if you are a little like me and struggle to project enthusiasm give it a try, do it anyway. Be sincere and express it in your own way, enthusiasm is contagious and brings the energy to push through setbacks.

Blog Award

To my surprise, this blog won the PMISAC award for Project Management Literature last night at the 2007 Awards Gala Dinner. This is a great endorsement, I work on the blog in my spare time and it provides a large encouragement to continue and do more.

I also think having a blog considered for a literary award demonstrates how progressive the PMISAC is. It was not long ago that blogs were more the domain of developers than project managers. It is very encouraging to see alternative media branches recognized.

Team Solving: The Under Utilized Power

All projects face problems, but fortunately your team members have the best solutions.

Projects rarely go exactly to plan; they have a nasty habit of uncovering gnarly problems that were not anticipated, but need to be solved. This is illustrated nicely by Doug DeCarlo in his book Extreme Project Management.

The top black line depicts the planned approach moving in orderly fashion from start to finish. The lower blue line depicts how projects really progress with side tracks and setbacks as obstacles are encountered and overcome.

Yet, in attempting to solve these problems project managers too often overlook the best source of solutions, the project team. In this post I will outline why the team has the best practical solutions even when they may not be the best theoretical solutions. An example will probably help about now.

While managing a government project during an IT vendor change, we needed to quickly build rapport with the business users of the system and subject matter experts (SME) in order to maintain the development pace from the previous team. The problem faced was how do we get to know the business folks better and connect the team members and SME’s . Rather than contriving some project social event and trying to get buy-in from the business and team I presented the problem to the team in a planning meeting.

After some back and forth a team member suggested, that since quite a few of the business people went 10-pin bowling, then perhaps we should arrange a bowling social event. Others concurred, ideas for mixing the teams up (not us vs. them) were brainstormed and we ran the event. It went really well and led to other activities all of which greatly contributed to a strong relationship and a successful project.

As the PM I could have instead consulted the PMO, HR, or social psychology experts to determine the optimal team building event, but then I would have had to have sold it to the team. Here lies the first power of team solving:

Team Solving Power #1: By asking the team for a solution we inherit consensus for the proposal

The True Role of a PM on Agile Projects

So, what does the PM do on agile projects? If the team self organizes and selects their own work from the prioritized feature list, should the PM just buy pizza and keep out of the way? Well they are short changing the team if that is all they do. Rather than a fear of role erosion, PM’s should be maximizing business value delivery and looking to broaden their skill set with more leadership practices.  This post outlines four core roles and ten core principles managers of agile projects should practise. 

Working in Parallel
Before we start, the transition to agile does not happen overnight. There will be a long and sometimes awkward transition period as all the project stakeholders adopt a more collaborative and empowered approach to work. Some people will be quicker than others to make the transition and the PM often has to continue with traditional PM activities, behind the scenes, to ensure no balls are dropped on the project.

Ideas not new to agile, just a renewed emphasis
The Agile PM traits of a downward serving model and Leadership rather than Management were not invented by Agile guru’s. Instead agile teams found that the management styles that favoured people over process, collaboration over command-and-control worked best on agile projects. Leadership that moves the emphasis from doing-things-right to doing-the-right-things is a better complement to agile methods than the detail oriented task management popularized by modern project management. Interestingly, project management (emphasising achieving things through task control) is a relatively new phenomenon based on Fredrick Taylor’s Transformation View of task decomposition (1900). Whereas Leadership (emphasising achieving things through collaboration and shared vision) is as old as human collaboration itself. "When the best leader's work is done, the people say, We did it ourselves." - Lao-Tzu (604 BC)

Agile PM Role 1: Obstacle Removal

Lighter Grip and More Awareness: Lessons in collaboration from Boeing

Control vs Communication

When you first learn to ride a bike it is normal to grip the handlebars really tightly and look at your hands or feet as you concentrate hard on the new “riding” task and try not to fall off. The problem with looking at your hands or feet while cycling is that you will not see the rock or pothole in the road ahead until it is too late and so, despite your best efforts, you will fall off. It is actually safer to relax, loosen your grip on the handlebars a little, and look further up the road to spot obstacles in plenty of time to avoid them.

The same goes for project management, when we are new to the role it is normal to focus on the project plans, progress against the plan, and budget consumed too closely. We focus so much on these project management tasks that we fail to see the issues and risks (rocks and potholes) the project is headed towards, until it is too late. While plans, progress and budgets are all critical elements, we can bring more value to the project by releasing our obsession on these project metrics slightly and focussing more of our attention down the road to items like sponsor satisfaction and team morale. There is little point having a perfectly executed project plan and a full set of EVA metrics if the project gets cancelled or half the team quits.

Specification vs Collaboration
Closely linked to Control and Communication is Specification and Collaboration. We can try to specify everything down to the nth degree of detail and then hope we got the spec right and whoever is developing the product develops exactly to specification. Or, we can explain our goals at a high level and then work in closer collaboration with the developer to achieve our desired results.  Agile methods recommend the second option, getting the customer working in closer collaboration with the developer to ensure the right product gets built. This works well for many types of software project where it is difficult to fully articulate the complete requirements upfront. However, it is not just the software world that is switching to collaboration over specification.

Today’s aircraft are highly complex networks of sub-systems, parts and software; and Boeing’s new 787 Dreamliner is about as big and complex as commercial aircraft currently get. From its ground breaking remote diagnostics that communicate component usage, wear and failure statistics to the ground in real time via satellite communications; to its novel composite material wings that save weight, the aircraft is new and extremely complex.

When Boeing sent the specifications to the electronics supplier for the 777 (the predecessor to the 787) the document was over 2500 pages. The equivalent specification document for the 787 is a mere 20 pages, how is this possible? Boeing, who are experts in specification and control, learned that to tackle a project of this magnitude they had to form closer relations with their suppliers and learn how to co-create and collaborate like never before. While it would be wrong to say: “Gone are all the detailed specs” the major shift is to increased collaboration with suppliers and less reliance upon specification.

Many industries are tapping into the benefits of increased collaboration over contract negotiation that are also embraced by agile methods. With increased collaboration comes shared decision making as well. In the past, Boeing gave the orders like a drill sergeant, and suppliers complied. Rarely did it matter if the supplier had a better idea – Boeing wanted components built exactly to specification. This time, Boeing has given all of its partners a vote on matters that affect them. Boeing and its partners are reaping the benefits as they work together on solutions and adapt to realize unanticipated benefits.

So, if you get a chance to fly on a new 787 Dreamliner any time soon, consider the new collaboration process that enabled its creation (and let’s hope they did not lose any of those story cards!)

You can read more about emerging trends in collaboration and Boeing’s new work practices in Wikinomics: How Mass Collaboration Changes Everything. By Don Tapscott and Anthony Williams.

Team Decision Making

How quickly we make decisions and the team member’s level of agreement to these decisions impacts project performance and team cohesion. Software development is an exercise in information exchange and decision making. Also, since software projects have no tangible, emerging product moving down a production line, the communication and decision making process becomes more critical to keep everyone informed and engaged.

Agile methods utilize many tools to promote effective communications including: co-location, daily stand-up meetings, planning workshops, retrospectives, etc, but less is written or taught about decision making. However, if team members are not canvassed for their opinions we run the risk of alienating portions of the team leading to reduced levels of commitment and participation, and potentially missing an important new perspective that could help avoid pitfalls further on. This post outlines the importance of team based decision making and outlines a couple of simple tools to get you started.

Agile methods favour more team empowerment and less command-and-control direction. This increases satisfaction and productivity, but raises the need for effective decision making. Without a project dictator, how do teams make decisions and move forward?...