Symmetrical organization structure

As I'm studying Agile in greater detail what becomes increasingly obvious is how important the team is to achieving truly great results.  In the past year I've changed my view on how a project team should be organized.

In the past my project teams were organized as a hierarchy.  I now like to think of this as the 'pyramid of power' that had me at the top of the IT part of the team, reporting directly to the project sponsor. It was great in my mind as it made me a very important and in demand.

The problem with this org structure is how disconnected some of the people at the bottom of the chart become with significant portions of the team.    I've been on many teams where only the core part of the project team meet on a regular basis, and would devise what needs to be done.  The definition of work to be performed is then passed along to the others in the hierarchy. 

In the past year my view of team structure has changed considerably.  The change I've made in the past year is really quite simple.   The primary change is to bring everyone up to the same level on the org chart:

There are many advantage to this type of organization some of which are:

1. Reduces hand-offs - did you ever play telephone as a kid?   You know the game where you pass a message from one person to another?   How much did the message change by the time it made it around the circle?  Now imagine if the message was just given directly to the whole circle?  Everyone would hear the correct message directly from the source.   The same idea applies to our teams, and we should be looking to reduce the number of hand-offs for information whenever possible.
2. Team can self organize - the Agile Principles tell us the best architectures, requirements and designs emerge from self-organizing teams.  The symmetrical team structure can certainly help enable a self organizing team as it creates an environment where everyone is working and collaborating together.   For me the organization structure is one of the keys to the team being able to self organize.
3. Find defects early - in a recent project my team found a significant defect early while still in development.  The best part was the fact the team found the defect while we were still in development, which meant it was very easy to correct.   This happened simply because the developer was talking to customer directly, which goes back to #1 above -- reduce the hand-offs!
4. Creates an environment of trust - the best way to earn trust is to extend trust.   Trust your team to do the job they're good at without you hanging over them at every step and you would be amazed what they can do!  
5. Reduces the need for extensive documentation - documents are necessary, but when teams don't collaborate effectively it means we have to create very thick documents to try and capture the complete set of information.   However, it is never possible to capture all information in a manner that it is accurately interpreted.   The best way to convey information is face to face, and that's exactly what a symmetrical team structure encourages.

It's amazing what will happen when you trust your team, and create an environment for them flourish.  It's not that difficult to make happen, so give it a try!

In my next blog I will talk about The Five Dysfunctions of a Team.   If you haven't read the book I highly suggest it.

Until then ... Be Agile!

Mike

Project Management on Agile Projects (part 3 of 3)

In my last two blog entries I shared the first four primary points I made during presentations in the past month.  This has been a great experience, and I've certainly enjoyed talking with so many people.   The effort has been worth while as it's opened up so many great opportunities to learn and expand on my view of software development in general.

In the first two blog entries I shared tips 1-4 for being an effective agile PM:

Tip #1 - Figure out what is truly valuable to your customer
Tip #2 - Stop imagining you can predict the future
Tip #3 - Stop thinking your customer can accurately tell you in detail what they want at the start of the project
Tip #4 - Don't just communicate ... collaborate!

Here's the last two from my presentation:

Tip #5 - Be lean!  (aka eliminate waste)

Last year I had the opportunity to attend a Mary Poppendieck workshop on Lean Software Development.   Lean is a concept coming out of the manufacturing sector, but applies to what we do in software development as well!   Mary defines waste in software development as:

Extra Features

• Unnecessary Documentation - Your customer cannot run their business with project documentation.   Documentation is a necessary tool for effectively managing projects, but unfortunately too many organizations have taken it too far.   Rather than creating more detailed documentation, look to replace it with collaboration.   Also examine the timing of documentation.   It's always cheaper to document something which exists, rather than documenting something which doesn't yet exist
• Extra Steps - look at your software development processes.   Are there extra steps inserted for the sake of process?   Break those down and create the most efficient process possible, with the fewest steps required to assure good quality products.
• Finding information - it is wasteful anytime someone needs to search for information.   If you find members of your core project team in particular are searching for information through the documentation, you should examine how effectively you're collaborating (or not).  
• Defects not caught in testing - any defect creates waste regardless of how soon you catch it.  The most effective way to deal with defects is to create an environment which doesn't allow them to be introduced in the first place.  For many of us this is a goal somewhere in our future, and until then we need to continue finding them less effectively.   However, do strive to eliminate them before they cross from one domain to another.  Is there a way your team can collaborate with the developer to find more defects in unit testing?
• Waiting - every day your customer waits for a new feature is wasteful.   So rather than forcing them to wait months for a complete set of new features, strive to deliver it incrementally throughout that period of time.   Your customer will be able to start using the new features incrementally and starting building value immediately.   The other significant benefit of this incremental approach is your customer will learn what they really need as a result of using the features. 
• Handoffs - this one is so obvious I wasn't paying attention!   Any time your team has to pass work from one person to another (especially when it's being passed outside the team), you create waste as the new person needs to come up to speed.    Work to bring as much of the knowledge required to build the product right into your team.   This can be difficult in many enterprise environments, but reduce the handoffs as much as possible.   In situations where your team must do a hand-off, don't let the team lose sight of the fact they still own the project work so they need to take the initative to stay in touch with the person it was handed off to.

I could write a lot on this topic.   However, I'd highly recommend you pickup Mary's books and go through them. 



Tip #6 - Learn & Improve!

For me this is one of the most important concepts of being an effective Agile Leader.   You need to help your team learn continuously and apply those learnings in their work immediately as they move forward with their work.  An effective means to do this is to host regular retrospectives.  My preference is to host them at the end of each week, before they have a mental break (ie. the week-end) and they forget everything they learned.

One technique for doing this is the perfection game.   I’ve adapted this from a vendor I work with, but ultimately it came from Jim McCarthy.   The concept is very simple.   On the whiteboard draw three columns with the labels “What worked great this week”, “Score”, and “What would have made this week perfect”.  Each and every team member is required to attend and participate in this activity.   I usually start as often people have a fear of being first (over time you may find your team changes this).   In the first column I write 2-3 things which I thought were great in the past week.   Keep it brief and clear, and avoid the temptation to tell big stories.   In the second column write a score from 1-10 (whole numbers only) where 10 is perfect, and 1 is at the level you couldn’t imagine it being worse.   This is a very subjective measure of mood so do not try to over analyze it.   Finally in the third column – if you did not score a 10, then you MUST provide suggestions for what would have made the week a 10 (ie. perfect).  

If you use the perfection game effectively a team of 8-10 people can get through this process in 15-20 mins.   Some tips to help with your success are:

• Do not allow debate to start – clarifying questions are acceptable, but that is all
• Do not track long-term trends on the scores – last week to this week is all that is relevant
• Do this as a stand-up meeting – it will keep the meeting moving and focused rather than letting people sit down

That concludes Mike’s top 6 tips for being an agile PM.   Unfortunately there are no silver bullets, only experience and great ideas to build on.   If you stop to view the work you do as a journey (not a destination) you will have a better chance of success!

In my next blog entry I will talk about my view of Symetrical teams!

Until then … be Agile!

Mike

Project Management on Agile projects (part 2 of 3)

In my last post I started to summarize my presentations over the past month.   Now that I'm a week later, I continue to be very happy about the results of my presentations.   I'm starting to hear feedback from the presentations and it appears at least some of the people in the rooms received value for the time spent.

In my last post I shared 2 of the 6 tips I provided to help PMs understand how they might be Agile.  They were:

#1 - figure out what is truly valuable to your customer
#2 - Stop imagining you can predict the future

In this posting I would like to share the next two points:

TIP #3 - Stop thinking your customer can accurately tell you in detail what they want at the start of the project

Have you ever found yourself in the position of having a 'solid' scope statement at the start of a project?   You've put a considerable effort into ensuring you clearly understand exactly what the customer wants, detailed in a document that has been signed off by the sponsor.   You've detailed scope in terms of what is in scope, out of scope and possibly what is unresolved at the time of writing.   Then as your project progresses you find yourself writing many change requests to alter the details of the scope.    Was your project a success?   I used to think so!   On very large programs I would have lots of change requests, and I prided myself that the customer wasn't suprised by the results.   However, I now wonder how much value we left on the floor as a result of having to cut scope so significantly in some cases.

Since I've adjusted towards to be more Agile my project experience is foreverr different! At the start of this year I led an Agile project in which my scope statement was very simple.   The scope statement merely said to add a business feature and supporting functionality.   It was a very vague statement, but turned out to be the best one I ever wrote.   We delivered what the business required and exceeded their expectations!

What you need to find is a way to manage the scope of your project.   I used a technique taken from a webinar put on by Allan Shalloway from Net Objectives:  Webinar.   Within the webinar you will find Allan talking about a technique for managing the scope using front burner, back burner, fridge and freezer.   We adapted it, but basically used this technique to put scope control into the hands of the customer.   The experience was great!

(note:  since my presentation I've had conversation with Allan Shalloway who says this is an old technique he no longer subscribes to as he's transitioned to the use of Lean-Kanban techniques.   That's OK though, as we're just starting our Agile journey so old techniques were probably an easier step for us.   Besides ... results speak for themselves!   I am now studying the Lean-Kanban thought process and am sure I will write about it at some time in the future)

TIP #4 - Don't just communicate ... collaborate!

Anyone can communicate!  All you have to do is send an email or document out to someone.  Collaborating is tough stuff as now you have to get people sharing information and ideas effectively.   This doesn't seem to be natural and takes a lot effort on the part of the leader and team to make it happen.

Think about how you organize your team.   The most effective organizational structure is a circle where everyone is on an equal level with clearly defined roles.   No intemediaries as that is wasteful and leaves things open to interpretation.  I will be writing a future post in the coming month with more on the topic of a symetrical team structure, but for now the important concept is everyone has the opportunity to collaborate with everyone else directly.
Host 15 min stand-up meetings each morning.   Please note 2 key things in the previous statement:  '15 min' and 'stand-up'.   This has turned out to be a very effective tool for keeping the team in sync each day.   During this quick meeting each member of the core team must share three things:   what they accomplished since the last meeting, what they plan to accomplish today and what barriers are in front of them.    Keep it on track and moving and you will find people dont' have a problem coming to the meeting each day.   If you'd like to read more about stand up meetings check out Martin Fowlers blog entry:  Its not just standing up

This is a big topic, but hopefully I've summarized a couple key points for you on tools for collaborating more effectively.   Don't just be a manager or boss!  Be their leader and inspire them to do the best job possible!   Make them believe they're the most important thing happening and watch how they'll rise to the challenge

Next week I will post the last two suggestions I have for being an effective agile PM. 

Until then ... be Agile!

Mike

Project Management on Agile Projects (part 1 of 3)

 Over the past three weeks I’ve been fortunate to be selected to speak at three different conferences.    Toronto Agile Tour 2010, PMI-CTT Symposium in Waterloo and this past week at the Agile Vancouver Conference.  My topic was basically the same at all three, but turned to suit   my audience.   The two Agile conferences heard the message of what benefit project management brings to Agile projects.    The PMI group heard me talk about extending their PM career by learning what it means to be agile, and then apply it to the ways in which they behave and conduct their business.

Rather than doing this as one big blog entry, I’m going to split this topic over three weeks.  It’s easier for me as I can spread the work out, but more important it’s easier for you to read something short in your busy life.

The following are Mike’s six tips to being an Agile Project Manager.   If you’re interested in the other message (what benefits project management brings to agile projects) please contact me and I will be happy to pass it along.

Tip #1 – Figure out what is truly valuable to your customer

A company once set out to build their customer a drill.   They started working on it, and before long they were having lively discussions with regards to the design of the drill.   They would debate colour, materials, chuck type, power source and many other details at great length.   It took months to deliver the new drill, and the team was very proud of their accomplishments!  So did this company deliver value?   Not really as all the customer really wanted was a hole!

What needs to be done first is to figure out what is valuable to your customer.   I’ve come across many IT people who believed their customer actually wanted to work with them.   This is a dangerous attitude, as it leads in the wrong direction.   The business comes to work each day wanting to make their business activities successful and they need tools to do this, which is where IT comes in.   IT makes a business out of enabling our customer's success.    With this notion in mind you need to seriously examine everything you do, and question the value it brings to your team’s ability to deliver value.    No one ever ran their business with your project schedule, requirements document, or project plan.

These artifacts do deliver the ability to enable effective delivery of value for your customer, which is why we continue to build and deliver them.   They’re important, but don’t lose sight of the fact they are not what the customer sees as providing long term value.

Tip #2 – Stop imaging you can predict the future

In the past I’ve prided myself in creating detailed schedules.   I took a year and focused on improving this skill, and I can now work MS Project in all kinds of ways (yes including leveling successfully).   About 5 years ago I had a work assignment in downtown Toronto.   I would ride the VIA train there 2-3 days per week, and during that time I primarily worked on my schedule.   It was a great schedule, with hundreds of the tasks clearly laid out and connected together in the perfect network structure.   With this schedule I thought I had perfect control of my project … WRONG!  I only had the illusion of having control, and the evidence of this is how much effort went into adjusting the schedule as it simply didn't reflect reality. 

Instead of creating detailed schedules, give your team some ownership on this front.   Find a better balance by providing them a framework from within which they can self organize and figure the details out themselves.

On a recent project I created a schedule out of flipchart paper, and post-it notes.   I created a giant grid with the far right of the grid representing our time box which we could not exceed.   We established further constraints inside the schedule, which could not be broken (e.g. No single person’s activity could go more than 2 weeks duration).   Every morning we would conduct a 15 minute stand-up meeting, and would use the schedule on the wall as our focal point.   At the start of the project I was secretly concerned about how on earth I was going to effectively control my project if I didn’t have a detailed schedule.   However, I have never felt so in control of my project as I did that time.

I’ll draw on the Agile Manifesto principles to explain why I believe this happened:

“Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.”  

Try it … it works!  

Next week:

Tip #3 - Stop thinking your customer can accurately tell you what they want in detail at the start of the project
Tip #4 - Don't just communicate ... collaborate!

Until then ... be agile!

Mike

People ... People ... People! Does anything else matter?

In the past two weeks I attended the 'Agile Tour Toronto 2010' conference, and the PMI-CTT symposium (local PMI chapter).   I have been a member of the PMI group for approximately 8 years, and the symposium appears to still offer good value to the local members.    This is the first year I've attended the Toronto Agile Tour, and it's value far exceeded my expectations.   Both of these conferences also provided me the opportunity to present my thoughts on the value of project management on Agile projects (more on that topic in my next blog entry).

It's interesting despite the fact the two conferences have different primary focuses, the messages I heard at both were very similar.    The one similarity which really struck me is the people aspect of our profession, as it is a key ingredient to successful software development.  Of course that shouldn't be a surprise to anyone in software development as our domain is knowledge work.  Needless to say it would be difficult to do knowledge work without great people!  I've seen and heard of too many companies that view software development as an industrial process.   Many project managers (including my former self) have made the mistake of applying PMI processes as an industrial process, which is where the origins of PMI is rooted ... oops!

I attended a session at the Agile Tour Toronto conference, facilitated by Derek Wade who stated the position "Agile isn't what you do (it's how you think)".   I thought Derek did a great job of getting his audience to reflect on what they believed Agile represented to them.   The most obvious was a question Derek asked in which he asked for our input on how we characterized Agile.   There were around 10 answers provided, and it struck me that all of them revolved around the people aspect of software development.   Derek didn't guide this result, it just happened.

The focus of the PMI symposium was on the future of project management.   The three keynote speakers of the day focused on where they believed the future of project management lay.   All three focused on the people aspects of the profession, rather than the process.   Again no big surprise as I think as a profession we're learning the greatest value provided comes from our leadership and not the process.

Mary Poppendieck will tell her students "the results are not the point".   I've come to internalize this statement and know the future of software is very dependent on great people!  (actually it always was but I think some lost sight of that)

Make your team the greatest thing going, and they will produce great results!   Find out what makes them tick, and what will inspires them to do their best!    Then help them rise up and be great!    It's amazing what this will do for your software products and the value it delivers.

So back to my title "People ... people ... people!  Does anything else matter?" ... of course there are lots of important things we need to pay attention to.  Just don't miss this important one (because too many people do miss it!)
Next week my blog will touch on the content of the presentation I've been using the past few weeks.   Project management has been my chosen path for 10 years, and now Agile is the perfect compliment which increases the value and I believe is the future!   Project managers have a very important and strategic role in delivering value, but only if it is executed in an agile fashion itself.

Until then ... be Agile!

Mike

The Agile Citizen -- a new blog!

I’ve been very fortunately in my career lately as I have had many opportunities which are allowing me to grow personally.  The most recent opportunities are related to Agile and Lean, and it’s certainly become my new passion and focus!  This doesn’t mean I’m giving up anything I already believe in (including project management), but now I’ve found a way to enhance everything I’ve stood for.  I have been in IT for nearly 25 years now, and still enjoy this career path I am on.   If I didn’t then it would be time for a career change, which just isn’t in the cards.  

I’ve been toying with the idea of a blog for some time now, and have finally decided it’s time to make the leap!   I guess my resistance has always been a fear of failure.   Writing a blog certainly makes you vulnerable, by putting your thoughts out on the internet for all to read and comment on!  However, I believe there’s a lot of to be learned even if what you give me is criticism. 

I have titled my blog the Agile Citizen for a couple reasons:

1. it’s available!  (what can I say … it’s true that this helped to narrow my choice)
2. I believe in an effective Agile environment I am but a citizen of a larger community.   Agile is not about any one of person and the job we do in the act of delivering value.  Rather it’s about the citizen’s of a community and we’re all important to ensuring the greatest degree of value is provided.   While it is true the developer delivers the most direct value, others are required to provide support and so are equally important.    My community is multi-layered, starting with the teams I work with in my job, and extends out to the local Agile community and around this world we share.

My plans at this time is to write a new entry every 2-3 weeks at worst.  However, that will vary based on the activities in my life.   I will use Twitter to notify of new blogs for anyone who cares to follow (Tweet ID: @mikeeedwards)

Next week I plan to start a series of blog entries to summarize a presentation I’m using at several conferences right now.  My presentation’s topic focuses on how to apply project management effectively using the agile principles, allowing for the delivery of maximum value to your customer.   I am receiving good feedback from those who have attended my presentation, so I would like to share more broadly.

Until then … be Agile!

Mike