The impact of multitasking (and an exercise to prove it)

Have you ever heard this statement “I’m an efficient multi-tasker!” … ummm …. Yeah!   Talk about an oxymoron!   As human beings it is physiologically impossible for us to multitask.  From what I’ve been able to find it appears the term multitasking comes out of the computer industry around 1966, and has be misapplied to humans ever since.  Multitasking is something a computer does where it actually executes more than one activity at the same time.  In fact I’ve been able to find research actually suggesting not only is Multi tasking a myth for humans, but it in fact will degrade our mental capacity and abilities.   One article I found states:

• “The quality of our mind (our thoughts, perceptions, comprehension, apprehension, ideas, imagination, and creativity) degrades as essential capacities such as awareness, discernment, focus, concentration, and contemplation fragment.” -- "Mental Degradation-Multitasking"

To me this makes sense as our mind is like any other part of the human body.   It needs to learn, and develop good habits to be strong and healthy.   My guess is it’s kind of like muscle memory … once you’ve taught the muscle the right thing to do you can stop thinking about it and it just happens.   As a drummer I work on rudimentary exercises which develop the muscle memory for drumming.  In doing this when I perform it means I don’t have to think about the task required to play the rhythms on my drum.

One problem I often find in talking with people about multitasking is proving to them it’s so inefficient and problematic.  Like anything else I can spout off the downfalls of multi-tasking, but its illustrations which prove it to people.  I like this exercise I got from David Vacanti who taught me Kanban (there are others out there … this is just one I happen to like)

	Fibonacci	Multiples of 7	Roman Numerals	Alphabet
1	0	7	I	a
2	7
3
4
5
6
7
8
9
10

To complete the columns you:

Fibonacci: Add rows 1+2, and put the sum in 3.  Add rows 2+3 and put the sum in 4 … and so on

Multiples of 7:  Simply count by 7

Roman Numerals:  Simply count to 10 using Roman Numerals

Alphabet:  Simply list the first 10 characters of the alphabet in order

Instructions:

• Provide each person 2 copies of the worksheet – one for each of the 2 exercises
• The facilitator must time how long it takes from the word “Go” until the first person finishes the exercise, and the last person finishes the exercise
• The facilitator ensures everyone knows how to complete each column (see instructions above)
• Tell participants to raise their hand when they finish
• Don’t tell the participants this – but do not review or mark the results – this exercise isn’t about perfect results
• Do exercise 1 first – in doing this people can work on one task at a time, learn the answers and should make them quicker the second time around (otherwise you get accused of cooking the answer)

Exercise 1

Complete all 4 columns by working down the columns (ie. all Fibonacci, all multiples of 7, etc)

Exercise 2

Complete all 4 columns by working across the rows (ie. one cell in Fibonacci, one cell in Multiples of 7, one cell in Roman Numerals, one cell in alphabetic.   Then keep repeating until all 10 rows are completed)

So what does the exercise show you?   Ask the participants to provide that answer for you.   Ask them for their observations, and what they believe can be learned from this type of exercise.   Now what if we extend this out to complex tasks such as software development, and what do we think the impact of task switching will be on the outcomes of their work.

Through the exercise above you are not actually demonstrating multitasking.   I know I’m being picky but you’re actually demonstrating the impact of task switching.   We could write a computer program to run 4 streams of computations simultaneously to complete the table in parallel.   As Human’s you cannot be programmed to do that.   We’re just not wired that way!   

Research has been conducted as discussed in "Think you're multitasking?  Think again".   Researchers have used an MRI to study the impact of task switching on the human brain, and the results are fascinating … if not scary.   The researchers were actually able to prove that when our mind switches from one task to the other, there’s a pause where the mind is putting aside thoughts about one task to switch to another.   That’s just scary when you apply it to things such as driving and texting!   Despite the fact in Ontario there is a law to deal with text & drivers, people still do it … I see it all the time!  

Think of it this way … you’re in control of 2000lbs of metal, rubber and plastic.   This pile of junk is moving at some high speed such as 100kph … actually make it 130kph … if you’re breaking the law by texting, you’re probably speeding as well!   There’s traffic all around you requiring your constant attention to ensure you see issues before they become your problem.   Now you decide to text so your mind clears out all but the most basic driving thoughts (ie. you stop paying attention to the extras and only focus on keeping the car between the lines).  Suddenly traffic is stopped in front of you!!   

Assuming you even notice it happening, there will be a moment of panic jolting your brain into clearing out the texting thoughts and realigning it to avoid a bad situation!   How long did that reaction take?   2 seconds?   4 seconds?  Add in the time to notice traffic slowing and maybe it becomes 10 seconds!   I’m not sure it matters much!   Assuming conditions are reasonably good it will take roughly 250 meters (800 feet) to stop from the moment you start braking!  Add to that the fact you’re moving at 20 meters/second … you need to add at least another 40-100 meters to stop … OMG!   It’s no wonder there are so many problems with people texting and driving.

So lets bring this back to the IT and business world.   What is the impact of task switching to the work we do?   I would argue the cost is likely staggering and very difficult to measure.   How many of the defects being introduced to our code are the result of task switching?  How many servers crash due to the setup being done in parallel with numerous other support tasks?  How much more value could we be delivering if we would only focus on one activity at a time and minimize the task switching?   It’s mind boggling when you consider these types of influences on our work!   How many millions of dollars does the IT industry waste every year due to task switching!?!

Despite all of the evidence and researching proving the significant impact task-switching has on humans … we still believe it’s the right thing.   I recently saw some job postings stating you must be a good multitasker.   One of the adds even said “Do you enjoy multi-tasking, project ownership?”    To me this is the equivalent of asking “Do you enjoy being an inefficient worker?”

Unfortunately in today’s fast paced business world, we must deal with all kinds of inputs at the same time.   Look to rise above this and increase your mental capacity and work throughput by stopping the insanity!   If you’re looking for something to help you personally manage this type of environment, I would suggest you read up on Kanban.  Kanban is one tool which can help address these types of problems, and helps you develop the habits required to manage the flood of inputs!   There’s even numerous people who have written about Personal Kanban which also addresses these issues at a personal level.

Look around your workplace for evidence of task switching occurring.   I’m willing to bet you can find ways to cut down the task switching, and increase the value being delivered.   Is there a way to reduce the interruptions we all seem to endure?   Is there a way to ensure team members are not hopping between activities on your project?  What if you were to limit meeting time to only a portion of the day and allow people to be totally focused for the remainder of the day?   Turning off those pesky email pop-up notices is another great way to reduce task switching.   I’m sure if you spend a little time looking at how you conduct business, you will find ways to reduce the task switching!

Regardless of how you address and manage task switching … do it!   The benefits of doing so can have a tremendous impact for your career!   

Oh yes … and if you’re one of those people I see texting and driving … especially those who are following me … STOP IT!

Airport Customs & Security using Kanban -- not likely

Recently I traveled to the US for the LSSC conference in Long Beach. To get me in the mood to talk about kanban for the week I'd like to thank both US customs and the airport security for such a good demonstration of a queue. It actually wasn't that bad as it took only about 1.5 hours to get from check-in to the far side if security. Given Bin Laden's recent death and the fact it was Monday morning ... I thought it was going to be far worse.

When you stop think about it the line is a good demonstration of a pull system.   If you try to push more into the queue, you're pretty much guaranteed they're going to push back.You never see customs or airport security with more than one customer at a time, and I'm sure they track stats like no body's business. The policies are certainly explicit and its in your better interest not to break them. Well not if you want to get to  your destination anyways. There's even different classes of service. Those who hold a nexus pass, and the  flight crews have urgent cards. The people who didn't leave sufficient time to get through the airport have due  date cards (not sure if they're all met but I see the airlines trying). Finally theres the rest of us ....first come, first served.

The only thing I was left wondering about is their backlog. Other than when the room is full there doesn't seem  to be any limit to the backlog, and it just keeps going and going. However with the fact they never take on too many tasks at a time the process us through the queue with great efficiency.

What I wondered about is what would happen if they could control the backlog more than they do today.  What would it look like if they could work with the airlines to limit the backlog to one plane load at a time in the room?

I had estimated the lines contained anywhere from 500-600 people. There is no rational priority to the  standard queue, this probably causes some chaos in the customs area as people react to the environment  in a way which is very different from each other. What if we established a lower limit of 100-200 people in the customs line?  What impact would that have on the efficiency of the whole system of moving people through the process?

The airlines would have to manage the input queue to feed the customs backlog based on the priority of the  passengers. Those who arrived with sufficient lead time would receive a standard card based on when the  flight is departing. Those who arrived closer to their departure time receive a due date card to ensure they get  through efficiently.  The rest you can figure out from there.

So why would they want to do this? Simple ... The comfort of people, the experience for the customer and a  reduction in the infrastructure required behind security. The other reason could be money! Airlines make  money when airplanes move people, and if we increase the efficiency at the airport then just perhaps they  could move more airplanes. People could spend more time outside and in security free areas, and then when  their turn comes they will make it through the security quickly and easily.

Sounds good doesn't it? If only it were that simple! There is a lot of variability in the system, ranging from  weather, traffic, mechanical problems with the aircraft, and the biggest one of all ... People! You'd have to  educate the people on the system and prove to them it does actually work. If they would come to believe in  the system, our experience could be significantly better than the crowds we work through today.

If only it were this simple ... Oh well ... I guess i have to just look forward to long lines for my return trip.

Dysfunctional teams

I finally read "The five dysfunctions of a team" by Patrick Lencioni.   I took it to read on the airplane going to and from Vancouver, but it's such an easy reading book I now have to find something to read on the airplane on the way home.  Then again maybe that's a good opportunity to catch up on my sleep.  Linda Rising pointed out at the conference that true greatness requires sleep!  Ha!  If only it were that simple!

In his book Patrick has illustrated a five tier model for the dysfunctions of a team, and once you understand them you have a chance of starting to correct them.

The book is written as an account of how the new CEO of a company worked through the process of making the executive group a team (rather than a group of individuals).   In it's own way the process narrated in the book reminded me of stories I've heard from a friend regarding his experiences in the USAF basic training camp.   In basic training they work to break down the individuals, and they go through a very difficult time of realization.   This removes numerous barriers allowing the USAF to start building a strong team.  Although they do lose some people along the way, the result they are working to achieve is to build a world class team. This isn't too far off the story line for the book.

The model Patrick has built for us makes a lot of sense.   The way to read the triangle is from the bottom up, and here's my summary:

5) Absence of Trust - team work begins with trust, as without trust it is not possible for effective conflict to occur.   In otherwords, we have artificial harmony resulting from a fear of conflict.

4) Fear of Conflict - conflict can be a good thing if it's used as a means for reaching good decisions the whole team can buy into.  Conflict must be constructive, and be used as a tool to reach great decisions.   The root of this dysfunction is ... you do not have good/clear decisions you will have ambiguity leading to a lack of commitment.

3) Lack of Commitment - Commitment is a function of Clarity and buy-in.   You need to ensure everyone on the team is committed to decisions, even if they voted against it.  If you lack commitment from the team it is very difficult for them to call each other on commitments, and so you lack accountability:

2) Avoidance of Accountability - Accountability is the willingness to call a peer on their behaviours which can be damaging to the team. The dysfunction stems from an unwillingness to deal with the personal discomfort associated with having these conversations. In the absence of accountability team members are more likely to turn their focus to their personal needs leading to Inattention of results.

1) Inattention to results - This is where people are more interested in their personal status and ego than they are with the team results.  Truly great teams do not have a group of individuals concerned about their individual status, rather they have a group whose primary focus is on the end result at the team level.

I highly recommend reading this book!

New PMI Agile Certification -- Really?!?

If you haven't noticed yet PMI has released initial information regarding a new certification for the Agile project manager.    When I first saw the information released I was excited as I would likely go after this certification to add to my PMP and PgMP.   However, since that time I've had time to reflect and now I'm not certain. 

I have had my PMP since 2003 and PgMP since 2008.   I am still very happy with those accomplishments and believe it certainly cannot hurt in my professional life to have those designations behind my name.   However, the place I have become disillusioned is as I've watched PMI dilute the PMP designation to the point of it almost being irrelevant.  I have heard many stories (and have a few of my own) of people who are certainly unqualified and earn the PMP, and use it to try and put themselves on par with PMs who hold far more experience.   The PMP is not difficult to earn, and can be accomplished by studying the theory.   In my mind the PMP shows someone has written a test on the theory, but really doesn't mean the person can manage a project.

When the PgMP certification was released I decided to pursue it due to the rigour involved with the process.   It was brutal in comparison to the PMP, and as recently as late 2010 PMI was still auditing 100% of the apps (or at least the symptoms suggest that).   I place more on the PgMP as it will be far more difficult for an inexperienced person to obtain this certification.   However, due to the low exposure of the PgMP I find anytime I talk about it I also have to explain what it is, but don't mind as I worked VERY hard to earn this.

So now PMI releases the agile certifcation for project managers.  The initial announcement was accompanied by a preliminary skills test for those who were interested.   I think a posting on Twitter said it all "... were they drunk?".   The sample questions were so basic and hoky, it left me wondering if those who wrote these samples knew much beyond some simple references to Agile.   It was truly bizarre.  

The sample questions, the low requirements to apply for the certification, the low cost of the certification all leave me wondering what PMI is looking to accomplish with it.   I worry the certification will go the way of the PMP, where so many people have earned it, and it's so easy to earn that it will eventually become irrelevant.  

At this point you might be wondering if I'm going to go after the certification myself.   For those who know me, you know how passionate I am when it comes to the domains of Agile, Lean and Kanban.   The answer is "I don't know yet".   I'm not convinced it is worth the effort, or provides any return for me in my career at this point.   I would much rather invest the time sharing my thoughts, teaching my peers, or furthering my understanding in areas providing greater return.   I'll have to see what the 2012 brings and whether this is truly just a case of PMI jumping on the band wagon, or if they are truly trying to established a measure of the Agile PM (which if you truly understand Agile you'll know how difficult it would be to measure what an Agile PM is).

Please let me know your thoughts!   Do you agree with my point of view?   Do you have plans to write the certification exam?   Maybe you'll help me make up my mind one way or the other!

Agile and personal responsibility

I learned an important lesson long ago from my Cub leader (Scouts Canada):   “To do my best”.    In Scouting all of the promises start with “I promise to do my best…”.   In Cubs we even had an opening/closing ceremony which had us challenging each other to do our best!   It’s a constant theme in the program, and perhaps there are some lessons we can draw from it.

Much as in Scouting, the business world should always be challenging our people to do their personal best.   In the principles of Agile we can find numerous examples of this foundational behaviour.  

• Build Projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done
• Working software is the primary measure of progress
• Continuous attention to technical excellence and good design enhances agility
• The best architectures, requirements and designs emerge from self-organizing teams
• At regular intervals, the reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

Self realization and people always striving for their personal best!   So how can you realize this lofty goal?   As a leader in our teams your job is to help people reach for this goal, and help them through the transformation.   I’ve always been impressed and amazed when I take the time to bring the best out of people how they rise to produce amazing results!

Inspiring people towards always achieving their personal best takes some time and patience to achieve..   You cannot mandate them to be amazing as it simply won’t happen.   It doesn’t work this way!     Dr. Peter Jensen has written about helping people realize their true potential, and talks about the importance of sparking personal greatness in his book “Igniting the third factor”.   As a coach of Olympic coaches (including the 2010 Gold Medal Canadian Women’s Hockey Team!), Dr. Peter Jensen talks about how achieving personal greatness can only be achieved if you have ignited them from the inside.   The book talks about how as leaders we should be using five things as tools for helping people find their inner greatness:

• Manage yourself
• Build Trust
• Encourage and use Imagery
• Uncover and work through blocks
• Embrace Adversity

 Another key tenant to personal greatness is the ability for people to take responsibility for what happens.   Christopher Avery teaches his classes about responsibility.  Not the type imposed by a process or organization, but the internal type which when captured causes people to produce great results!   

Christopher will tell us the basis for taking responsibility lays in the three keys of:

• Intent – awareness is useless, unless you intend to step up and fix it
• Awareness – you need to know what’s happening, and where you’re landing
• Confront – you have to face the reality of your actions

With the three keys to responsibility in place you can start to examine Christopher’s Responsibility Process.   The Responsibility Process is based in human nature, and no one is exempt from going through this process.  

When faced with issues and adversity humans land in one of four spaces:

• Obligation – you believe you are doing something as it is required of you
• Shame – you hang your head low in disgrace for the result you produced
• Justify – you use other factors to explain the result you produced
• Lay Blame – you point to others as the cause of your situation

Everyone goes to one of these spaces as it’s just human nature.   You might think smart people are exempt, but in reality they just have better stories.    The key to responsibility is what you do after you’ve landed in one of these spaces.    Let’s try an example:

A colleague of mine recently explained how unhappy he was in his current job.   He knows he’s doing a poor job, but he’s just so unhappy about his current role he isn’t paying attention to quality like he knows he should.    We discussed the current situation, as I was trying to help him find the root cause of the dissatisfaction.   In the end he just doesn’t like the work he’s doing any more.   So I asked him, why he doesn’t go find another job and get out of this situation.   His response was the money is so good.   At this time I pointed to the responsibility process and asked him where he was in the model.

For this friend he has two choices to make.  Either way he needs to move himself up to taking responsibility for his situation, which means he has to make a choice:

• Find a way to find satisfaction in his current role
• Go find a new role, and if the money isn’t as good accept that it’s easier to take responsibility in a better environment

There is nothing easy about helping people produce great results!   Models such as Christopher Avery's or Peter Jensen's can provide you with tools to help you accomplish such a lofty goal!  

Please let me know if you have other tools & models you work with in the area of personal greatness.   The human factor is a difficult one, and I'm always looking for new tools.  

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