Agile Forest

Daily retrospectives

Renee Troughton

November 15, 2011

Inspect what is inside

Daily retrospectives are is not a new idea, but it is important to recognise and re-iterate that there are other things than just running a retrospective at the end of each iteration.

Consider the heart of Agile for a moment – it is a reflective improvement framework aimed at dealing with the complexities of imperfect human beings and software development. If the heart if Agile is reflecting to improve why are we only doing it once an iteration? Should we not be ideally aiming to do it more often, or most importantly, when it is most needed?

So to re-iterate, here are the steps to enabling daily retrospectives:

Whomever owns the daily standup meeting invitation updates it to tack on an extra ten minutes. This doesn’t necessarily mean you will use this extra ten minutes each standup but it is there if you need it. Regardless having an extra ten minutes booked into everyone’s calendar is always a good plan in order to deal with off-lined conversations or road blocks that were bogging the standup down.
Put up a board near your story wall that has the questions that you want to be addressed as part of your retrospective – for example ‘what’s working well’, ‘lessons learnt’, ‘what still puzzles me’, ‘what to do differently’.
Throughout the day if you have something that you would normally put up against your retrospective questions then jot it down on a post it note, with your initials circled next to it.
The next time you pass the wall check to see if that item is already on the wall or not. If it isn’t put it up, if it is, add your initials next to it. This is a great opportunity for you to check other notes that are up on the wall and if you agree with the item add your initials.
Every now and then as you pass the retrospective wall if you see something new then read it. If you agree add your initials, this is like social networking ‘+1 like’.
Agree to a ‘like limit’. For intensive purposes this behaves like a work in progress limit.
Once you have reached the like limit at the end of the next stand-up you will invoke the extra ten minutes and ‘pull’ that liked retrospective note into play. Discuss the item as per a normal retrospective but don’t cover off any of the other notes. If required delve into the root cause and ensure that you have clear SMART actions. Any actions should end up being a card that is prioritised by the team and added at the appropriate place into the backlog.
If necessary discuss how often the wall should be purged of singular notes. This may mean that the practice evolves to include adding a date for when it is initially raised.

The advantages of such an approach:

No long meeting to discuss the iteration at length, but the time might end up being the same in the long term if you are pulling a daily retrospective often enough.
Focussing on problems sooner rather than later (assuming it gets liked quickly enough)
Focusses on items of greater importance but still gives great broad visibility

A six year old’s one hour sprint

Renee Troughton

5 comments

November 12, 2011

I was recently inspired by a tweet where a Grade 4 class was asked what they would like to learn.

On my weekends the inevitable question arose from my six year old daughter “Mummy, what can we do?”. For the first time in a while I had a well planned answer for her. She had asked recently twice what it is that I did as a job and I very loosely explained it but decided that this was the prime opportunity to kill three birds with one stone – give her a good understand of some of what I do, fill up an hour of her time and find out what she would like to learn.

As an early concluding statement I was very happy with the results.

For those interested here are the steps that I took:

Gave her five minutes to brainstorm things that she wanted to learn. I framed this as either physical, practical or research (ie find out more about).
Because I wanted her to work on her writing I asked her to write them up one per post it note. I also added one card to cover what I do for a living, but the exercise itself covers off some of this.
Then I asked her to prioritise them (shot A)
After that they were sized in minutes (shot B of the outcomes). I found this incredibly funny and really hard to restrain my opinion on how long they would take – I wanted to timebox myself to her times and not mine. I found it interesting where the item I added was in her priority.
Then we agreed that we would stick to one hour. We put the headers up for backl
og, in progress and done. Then we began our hour.
Before we started each card (ie before the timer started on it) we defined exactly what we wanted covered in it through a conversation.
Once this was clear we moved the card into in progress which was a signal to start the timer.
If we reached the end of the card’s estimated time I would ask the question if we were done against our criteria or if she wanted to spend more time on it. Only on one occassion did we reach the end of the timebox and she wanted to extend it. I then asked her what she wanted to de-scope and she chose what to remove from the backlog in order to extend that card’s time. In three instances we were shorter than the cards estimate, we probably could have pulled back in the one we cancelled because of this but her attention span was starting to wane at the 55 minute mark and I cut the one hour timebox off early.
When the card was finished it was moved into done and any deviations to the actuals written down.

So take a look at some of the other shots of work in progress and some of the outcomes. Lastly there is a mid sprint opinion on how the exercise was going.

Ken Schwaber’s Tweet – Hoax? Error? Hack? or Truth?

Renee Troughton

5 comments

October 27, 2011

Ken Schwaber doesn’t tweet very regularly. It is usually only a few tweets a month. But yesterday some of the Agile community went a little in a flurry over a tweet that he sent out:

If you clicked through to the link you went to a website called controlchaos.com. For reference, here is a screen shot of it as it stands now:

It all looks semi real. There is a message from Ken and as you read it you think ‘Okay…. so why have the tweet about Kanban when there is no content relating to it?’

This is when it gets a quite interesting. Twitter’s @Rodrigoy(aka Rodrigo Yoshima from Aspercom) posted that the site was changed only a few moments later removing this:

For those who cannot see because my wordpress likes to make everything look small:

People love Kanban because it feels familiar. Everything is orderly and known, roles are laid out, project manager is in the saddle, metrics are in place.

BUT…

Kanban’s father, waterfall, failed. As waterfall’s progeny, Kanban also will fail for software development. Kanban is for complicated work, where there is more regularity than irregularity. Such as service calls. Scrum is for complex work like software development. The right process produces the right results.

Yes, apparently it says Kanban will fail for software development and was related to waterfall and not Lean or the Theory of Constraints. The Kanban and twitter community ignited for a while amazed at the faux pa’s.

So you are now left with the conclusion that either Ken went on a small rant and then realised it was maybe not a good thing consequently editing the page or something else happened. Why he didn’t delete the tweet as well is a good question.

There might be the possibility of both Ken’s twitter and the contolchaos website being hacked at the same time. Despite a lack of deep site content he is affiliated to it through an old but still existing common link to Advanced Development Method’s CTO Dick Faris and VP Bob Schatz through Primavera. It is also interesting that he hasn’t made a comment on the web content change.

What do you think – Hoax? Error? Hack? or Truth?

Distributed teams – what can we learn from online multiplayer gamers?

Renee Troughton

1 comment

October 18, 2011

In a previous post I shared my wonderment of how teams work hard to reach peak performance when they cannot see each other in the gaming world.

I see great synergies here with Agile – how different is it when software development is done in a distributed or offshore manner? Let’s take a look at the techniques gaming guilds use to reach peak performance.

ALWAYS use voice communications

Lucky you didn't see my avatar handle!

I know of no guilds that have any degree of moderate success without using either Teamspeak or Ventrilo. For those of you unfamiliar with these programs they are like Skype, but allow whole teams to be together in the same chat channel (or in various channels on the same server) without the video input/output but with amazing audio input/output. The reliability and quality of people’s voices is incredibly high. I would recommend that everyone in the team stays in the channel together as they work throughout the day. If you need to ask someone a question they are only a single button (microphone on) away. Setup your channels something like the following:

Team (the default channel which everyone should be in)
Private meeting 1 (only if the meeting really has to be private – what is wrong with having the discussion whilst in the default channel?)
Private meeting 2 (see above, contingency channel)
Quiet Time (for when you really have to concentrate and not be interrupted by someone’s voice)
AFK (on lunch or bio break)

Basically you use these tools as an open-ended, incredibly cheap (both on bandwidth and cost of an instance), high quality conference call. What’s to lose?

Now I know with a 100% certainty that verbal imaging would make this even better, but the above solution has no end timeframe on the communication and is not heavy on a computer’s bandwidth. I have found Skype to be unreliable and questionable on quality and so for the moment prefer the audio.

Be present in time together

This is going to be the hardest thing for offshore teams. I am going to put this out there: If you are doing offshoring to save money (which is a fallacy, but that is a different debate) then your partner must come to the table and provide optimal customer service. To do this they must work the same hours as the onshore team. This should not be a choice – this should be your requirement.

To put this into context – if someone from Australia wants to raid with an American guild they need to change their sleeping patterns and inconvenience themselves for the benefits that they perceive they will get out of it.

Fail often, reflect and adapt often

Who would have thought that gamers did this better than Agilists? In the gaming world, working together the feedback loop is incredibly tight. From failure to reflection of what went wrong is minutes, if that. Teams question what went wrong, search out the root cause and devise a plan to solve or mitigate the problem. The time from failure to another attempt is usually only another few minutes. The cycle continues with more information until the objective is met.

Use visual cues

Agilists do this somewhat better but probably more due to opportunity of the environment then anything else. In the gaming world special icons or symbols are used to indicate assignments, zones to move to, or behaviours to be aware of. This maps to some degree to story walls where tokens and avatars are used to denote particular significance – ie blocked cards, allocations, risks, expedites, etc. Unfortunately for distributed teams a number of tools out there don’t support tokens very well, but avatars are generally a standard feature.

Keep informed on best practice and alternative approaches

Gamers definitely do this considerably better. Because everyone is not together and because their objectives are difficult it is not uncommon for gamers to be given assignments to watch videos of similar people tackling the same issues, to seek out alternative approaches to reach objectives and to orient yourself to what can be expected. I liken this to regular upkeep of best practice of skills and new and innovate ways to approach the problems on your project. Ask your team – how many hours do you spend continuously improving yourself and the way in which you work in your private time – this is a great indication of how attuned the team is to their cause.

The Distributed Marshmallow Challenge

Renee Troughton

2 comments

October 6, 2011

Most people in the Agile community are now familiar with the Marshmallow Challenge where the primary purpose is a lesson in collaboration and communication (according to the website), but for me the key takeaway is the need to prototype and fail early.

In one of the post events in Agile Australia 2011 Thoughtworks took a different slant on the game and applied a twist of seeing what happened if you distributed it. Rixt Wiersma was the co-creator of the game and I was lucky enough to have a talk to her before and after the challenge.

Taking what was used in that event and then adapting it even further creatively I have an advanced version of this game whose sole purpose is to teach to distributed teams the impact on communication rules and outcome. The result of this is below.

~~~

Time required: 20 minutes actual game play, 10 mins setup/explanation time, 5-10 minutes debrief.

Participants: Six teams of preferably four, but can be scaled up. If you have less than 24 then reduce team B and then D.

Materials: In addition to the standard Marshmallow materials, a notepad with removable paper and a pen is required. Team E will require two working mobile phones.

Rules:

Read the standard Marshmallow rules. Additionally;
Inform the teams that the point is not to learn about prototyping early, it’s about learning the impacts of distribution. As such they need to feel comfortable to use the Marshmallow early in the challenge.
Teams A-E are split in half, the first half is called ‘Alpha’ and second half ‘Beta’. Change the names to cities if you want.
Setup varying distribution limitations on communications:

Team A: No collaboration even at minute 0. Beta is removed from the room immediately. No crossover time allowed, no communication allowed on switch overs.
Team B: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, no communication allowed on switch overs.
Team C: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, communication on switch overs is allowed but only via notes.
Team D: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. The teams are allowed to talk for 30 seconds at the beginning of switch overs.
Team E: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta asked to leave the room or move to the other side of the room. Alpha and Beta are allowed to observe the other team via other communication methods – this can be done either via a video/tv hookup or simply by letting them stand at a distance and listening in over a phone.
Team F: Alpha and Beta are never split.

Timings: Switch overs between Alpha and Beta happen at minutes 7, 12, and 17. At minute 17 the team being swapped out can observe the outcome of the last 3 minutes (in silence).

The crux: Introduce a requirement at minute 10 to not just have one point with the marshmallow on top but to have a second point at a similar height (ie two towers as part of a single structure). You might need to up the spaghetti sticks to allow this to happen from the norm.

The “I love Agile but I don’t have the time” Customer

Renee Troughton

8 comments

October 4, 2011

Phil Kan (philxan on twitter) recently sent in a problem to the The Agile Revolution problem bag:

We have a Product Manager who’s supportive of Agile in theory, but won’t do the work we need him to do. How do we manage that?

A few tweets later we learnt a little more…

They aren’t available for the discussion of stories (often away) & the highest priority work is the customer who screams the loudest. Rather than product progression, we do a lot of tweaks and minor bug fixes. We do showcases after each 2 week sprint (a release is usually 3 sprints). Are we just expecting too much from our customer?

Because we were running incredibly over time there was a little skimming of the issue and I wanted to take some additional time to cover off a few points that we might not have been awfully clear or comprehensive on.

The stance –

Craig: Do you have the right person?
Is this really the right person as your Product Owner? Is someone more suitable that can give you the time that you need?
Tony: Stop working on the product.
If they can’t give the time then they are obviously not committed to the product. By stopping work on it (tools down) you are testing their commitment. If they are upset that you are no longer working on their product then as calmly as you can explain that they need to provide more time in order for you to reach your goals. Ask them the question “If you wanted a renovation on your home, would you just hire a builder and say ‘Do what you want, I’m sure you’ll get it right.'” My concern is that sometimes commercially this is not a viable option.

I’ve added more behind Tony’s thoughts but it was also my instinctual response. In retrospect, can more be suggested? Yes!

Consider moving to a Kanban method rather than using Iterations (which was my second thought five seconds after tools down). I hear a lot of complaints (and more of them from product owners) that say Agile has too many meetings. Kanban has a more natural flow. You can still release every six weeks if you want. Or just release whenever now. Yes the product owner will still need to groom the backlog and provide details for you to build off but this is now on a more pull basis then scheduled.
Replace your product owner with your true end customers. This is really an extension on the above thought. If you move to Kanban you can setup a regular cadence with all of your customers at once and groom/define stories in the backlog. David J Anderson talks about this process a bit in his Kanban book.
Consider shifting to three week iterations. If the complaint is that there are too many meetings then three weeks will reduce the number of meetings over time, but in reality this is more of a perception. Don’t get me wrong, perception trumps and if they think it is better, even though it is the same then it is win-win.
Conduct a root cause analysis. Gosh we are so bad at this. Look at how we all initially reacted. Solution, solution, solution! Now in fairness, if you give a problem in a single tweet you are only ever going to be able to go straight into solution mode, but spend some time being frank with your customer. Call the spade as it is. Explain that it is an issue for the team, but that you want to work with them (the product owner) to find a resolution for all. Get to the depths of why they cannot provide the time. Get to the depths of why you need the time. If an understanding can’t be made then maybe look at the solutions above.

Do we indoctrinate into Agile?

Renee Troughton

5 comments

September 21, 2011

Indoctrination is the process of inculcating ideas, attitudes, cognitive strategies or a professional methodology (see doctrine). It is often distinguished from education by the fact that the indoctrinated person is expected not to question or critically examine the doctrine they have learned.

Wikipedia

Do we teach through repeated instructions? Yes, I see this often. Inculcating check.

Do we present a vision of a practice or approach being positive or negative? Agile manifesto – yes, Waterfall negatively viewed. Attitudes check.

Metacognition is defined as “cognition about cognition”, or “knowing about knowing.” It can take many forms; it includes knowledge about when and how to use particular strategies for learning or for problem solving.

Do we use cognitive strategies? Yes. Are we cognizant of them? Yes.

Do we often treat ourselves as a professional methodology? Yes.

The term indoctrination came to have awkward connotations during the 20th century, but it is necessary to retain it, in order to distinguish it from education. In education one is asked to stand as much as possible outside the body of accumulated knowledge and analyze it oneself. In indoctrination on the other hand, one stands within the body of knowledge and absorbs its teachings without critical thought.

Are we educating or teaching and allowing critical thought? This is the big question and the key differentiator.

Firstly it depends on the trainer and the coach. I would say most professional Agile training I have seen (and yes I would include CSM in this) don’t allow critical thought. The exception to this rule is what I have heard of Alistair Cockburn’s advanced training which begins with a critical look of Agile and positive look on Waterfall.

So what about the coaches? Most coaches I know would respond positively to critical thought. But do we actively enable it? I am not so sure we do a good job of this.

Which practices have empirical proof that they are beneficial? Ten years and how much data do we have about whether pair programming is really better? Yes I know the point is always made ‘but no one will pay for the same software to be created twice’ – but have we tried to get a real answer on this? Scientists study all sorts of things – why is it that Agile practices and techniques have such little data behind them? No one is willing to pay for it (except maybe Scott Ambler). Maybe as a community we should start working together and get some real information behind us so that we can respond strongly against critical thought.

Epics, Themes, Stories, Features, MMFs – What the?

Renee Troughton

4 comments

September 14, 2011

Do you know what the difference is between an epic, a theme, a user story, a feature and a MMF is?

I am willing to stand up and say that I have no idea anymore. I have just spent over an hour looking over books, presentations and blogs to try and find the answer and the result – there is no consistent answer!

Is it any wonder that myself and my peers regularly disagree on the decomposition of these when the community itself at large seems to contradict itself so much?

Lets start with the most academic stance. Mike Cohn, writer of the book User Stories Applied and Agile Estimating and Planning. If a clear stance is to be found it would be here.

Mike writes (slide 19) that the decomposition is Epic -> Theme -> User Story. It’s a pyramid. It’s pretty damn clear.

Then you can go to any dozen blogs that argue that it is Theme -> Epic -> User Story.

The mystery deepens when you add in Features and Minimal Marketable Features. Then it grows even further with the advent of Lean using Minimum Viable Product (MVP), Minimum Viable Feature (MVF) or Minimum Marketable Release (MMR) instead of MMF.

There are tonnes of blogs, most saying that MMFs are actually an alternate to Epics; others say that it goes MMF -> Epic and then the third variant is Epic -> MMF. If you add Themes back into the equation it just becomes a big pile of… umm… confusing stuff. Then there is the ‘Are all features MMF’s?’ debate. Is one a subset or a grouping of the other.

Oh and on top of that we see the Kanban community using ‘goal’ and ‘objective’ and starting saying things like
Goal -> Objective -> Epic -> MMF -> Story -> Task.

Then we have some calling them Story and others User Story.

IS IT ANY WONDER WE ARE CONFUSED?

Just as the ideal size of a User Story has changed over the years it seems that the way in which we decompose a Story has also changed (probably as a result of the ideal story size change and consequently having to split them down).

Have you ever tried to speak to a Product Owner and try to explain these weird terms to them. They look at you as if you are from Mars; and I feel rightly so.

Instead of confusing them with terms like ‘Epic’, ‘MMF’ and ‘Story’ this is the parable I tell them:

We are going to look at your problem that you approached us with. We are then going to spend some time understanding all of the related problems and find the root cause. Then we are going to discuss your high level needs and break then down, bit by bit until they reach a size that we feel we could build to in around three days (and link them back to the root causes).

We don’t have to build the whole high level need at once. We can do it bit by bit ensuring that the stuff (technical term) that we build is worth the most value. When you think you have enough stuff to push out to the end user then we will release it even if the complete high level need has not yet been fully realised.

If this all doesn’t make sense then think of it in terms of a library.

I then tailor the library description to the depth of the project they are working on – ie it might be a program or a project with many phases, it really doesn’t matter, what matters is that the size is ever decreasing:

Library -> [Categories] -> [Series] -> Book -> [Part] -> Chapter -> Paragraph -> Sentence -> Word

A release is a book because more commonly than not you cannot sell a chapter or a paragraph, but you can sell a book or a series.

An organisation’s portfolio would normally be the library.

The story for me is the sentence. You can test a sentence, test that grammatically it fits together, but additionally you can test the components within it (words) for errors (spelling mistakes).

I realise that I am probably going to make the confusion even worse by putting this out there, but until there is a bit more clarification from the heresiarchs then I am sticking with this.

UPDATE: Subsequent to when this post was written Mike Cohn and Kent Back came out and clarified their personal stance of Feature -> Epic -> Story from a decompositional perspective. I would say as a community we should try to follow this lead and see if it over time solves some of the confusion.

Attention Sheepwalkers

Renee Troughton

1 comment

September 11, 2011

It was with some trepidation that I took at look at Seth Godin’s Tribes book. This was primarily due to mixed reports from friends whom had read it. It was so mixed that it was pretty evenly split down the middle 50% loved it, 50% hated it. Those that didn’t rate it felt that it was overly repetitive.

My immediate thoughts – I LOVED IT! This is probably saying something seeming how cynical or pessimistic I can be about books, blogs, presentations, etc. Without a doubt I would recommend this to others for a read; it is nice and short, about 150 pages and half the size of a normal book. I wouldn’t say it’s insights are anything new for me, but there was a lot of strong re-affirmations to how I feel on a number of subjects. The biggest thing for me about this book was that I felt motivated as a result of it, although my passions are already quite strong, after this book they felt on fire.

Here is my key summary of the book:

Heretics, innovators, revolutionists. Whatever you want to call them it is about not settling for mediocrity and instead striving forward towards an area that you are passionate about.
Those that inspire others with their passion become leaders.
Do something! Take control of your life and join or lead a tribe now.
Sheepwalking is a beautiful term for those who are just following the pack and not asking questions. It’s almost as bad as sleepwalking through our working lives.
Seth Godin’s movement is to make movements. Eat more prunes.

After reading this book and talking to colleagues about it I remarked how I had always felt comfortable with the revolutionist tag but was now on my way being comfortable with the heretic tag. My colleague’s response – ‘You aren’t a heretic, you are a heresiarch.’ I would probably rank the likes of Alistair Cockburn, Jeff Sutherland, Martin Fowler, etc with that tag rather than myself as they started the revolution. For me, it is about evolving the revolution to the next phase.

Some key quotes and thoughts on them:

Some tribes are stuck. They embrace the status quo and drown out any tribe member who dares to question authority and the accepted order.

Is Agile stuck? Are the heresiarch’s beyond reproach and questioning?

Everyone’s a leader.

Hmm we aren’t there yet – but everyone should be a leader of themselves. Do something you are passionate about!

Leadership is about creating change that you believe in. Leaders have followers, managers have employees.

Nice!

Organisations don’t have to be factories, not anymore. Factories are easy to outsource.

This is where our real value add is. As work gets continually outsourced we need to be innovative as thought leaders to continue to preserve our way of life.

When a CEO takes the spoils of royalty and starts acting like a selfish monarch, he’s no longer leading. He’s taking.

Don’t get me started on this one. I just want to re-affirm that I believe this strongly.

It’s easy to underestimate how difficult it is for someone to become curious. For seven, ten, or even fifteen years of school, you are required to not be curious. Over and over and over again, the curious are punished.

Wow. I say this regularly and it always felt like no one understood this. Maybe Seth is a secret twin? It’s not just the curious, we are molded to do exactly as we are told by parents and teachers, to comply. Why is it so hard to say ‘no’ to your boss for that new piece of work when you are already 150% overloaded – it is because of many years of conditioning as a child to not say no to a perceived position of power?

Heretics don’t settle. Managers who are stuck, who compromise to keep things quiet, who battle the bureaucracy every day – they’re the ones who settle.

Around about this time in the book I began to wonder – Do you have time to be a heretic? It felt like the book was pushing everyone in the direction of getting their word out. That could be internally within the organisation or wider on the internet. The internet approach would take time out of your busy personal life. If it is something you can spare and have the passion for it will be an easy choice. For those focussed on many things, juggling many activities including a family this will be harder. You might have to drop a hobby, but then again, your hobby should be an area of your key passion.

The new leverage available to everyone means that the status quo is more threatened than ever, and each employee now has the responsibility to change the rules before someone else does.

Innovate quickly, fail quickly, adapt quickly.

Faith is the unstated component in the work of a leader and is underrated.

The book makes a point that religion = rules and faith = culture. Your tribe is your religion. Your faith is in your tribe’s values. I have heard Agile evangelists often called ‘The Agile Jihad”. It made me think about the training we provide and how from an outsider’s perspective it does look like an attempt to ‘convert’ others to our religion. For my two cents my religion isn’t necessarily Agile, it is a religion of embracing new ideas and change, of keeping people first.

It’s okay to abandon the big, established, stuck tribe. It’s okay to say to them, “You’re not going where I need to go, and there’s no way I’m going to persuade all of you to follow me.”

And lastly,

If you hear my idea but don’t believe it, that’s not your fault; its mine.

If you see my new product but don’t buy it, that’s my failure, not yours.

If you attend my presentation and you’re bored, that’s my fault too.

If no one cares, then you have no tribe. If you don’t care – really and deeply care – then you can’t possibly lead.

You’ve got mail!

Renee Troughton

3 comments

September 7, 2011

Is e-mail ruining our agility? Should more effort be taken to restrict it or dare to even ban it within the workplace?

Lets take a look at e-mail and how agile or lean it is vs not.

ANTI – For team members who are located in the same building, using e-mails is not encouraging face to face communication and we all know that face to face communication is king.
ANTI – For team members that are distributed using e-mails is not encouraging video or even telephone communication which is certainly better than the written form.
ANTI – Safety concerns. I recently got told by someone not to send them an email (or that they wouldn’t want to send one to me) that had the slightest declaration of a cultural issue in their department for fear that it would be found and used against them. Similarly I have heard of people keeping mountains of emails to create of documented trail of promises/conversations in case their boss points the blame finger towards them.
ANTI – E-mails create invisible wait zones. Reply’s are rarely immediate, they get forgotten scrolled past the visible area of the screen; there is limited visibility of where your request is response is in the recipients backlog.
ANTI – Context switching. ‘You have mail’ pop up boxes creates immediate context switching in our brains. We see that box pop up and think ‘Hmm that could be interesting!’ tab out of what you were doing to seek the new. We have just re-focused our brains and consequently incurred productivity loss.
MID – Transparency. This one could go either way. In some cases being left out of the right email group or not being thought of in the first place means potentially important information doesn’t cross your path. Alternatively mass group e-mail are way more efficient than old school pamphlet newsletters or internal mail for information. There are better ways to mass communicate – do a webcast or a blog that allows for a feedback loop or better yet get around and talk to your people.
MID – Factual data. Need to send actual detailed data? An email is okay, but again there are better mechanisms such as sharing it for the whole team on a collaborative intranet site. On a collaborative intranet site it is accessible by all and version controllable.
MID – PRO – Meeting invites. It is an effective way to organise a meeting with someone. Of course you could just walk up to that person, but for groups it is good. Then again, is that group your project team and are not your project team meeting every morning for a standup and at the start and end of the iterations – so what are these superfluous meetings for exactly?

It all comes back to the manifesto – individuals and interactions and customer collaboration. Email doesn’t help us, it is stopping us from effectively communicating with each other. Don’t try ‘no emails for a day’, it doesn’t work – people will just store their emails for the following day. Try ‘no emails for a month’ and see how you go. I think you would be amazed by the change in communication as a result of this.