Email is a time waster

Reading the paper on the train home from work I came across this article. Banning corporate email seems to be an extreme approach, but I do agree emails are sometimes a waste of time as its a poor form of communication.  I think we have become lazy with technology and send too many emails when a face-to-face conversation or a phone call would be more effective.

According to Radicati, 294 billion (in 2010) email messages were sent per day.  This means more than 2.8 million emails are sent every second and some 90 trillion emails are sent per year.  Around 90% of these millions and trillions of message are spam and viruses.

So by the company, Atos removing emails from their corporate environment they avoid having people waste time or putting systems in place to manage the spam and viruses.  By using  instant messaging Atos employees can increase their communication effectiveness through two-way real-time interaction.  Email is a broadcast mechanism and has little scope for real-time interaction.  However, I can’t help to think instant messaging alone is still a poor form of communication when compared to other alternatives.  It’s somewhere between email and phone conversation.  I have added a few additional communication options, including instant messaging to the below chart first created by Alistair Cockburn.

Many instant messaging tools now support video (including audio) and desktop sharing – so combining instant messaging with video and desktop sharing would provide a better and more effective communication channel than instant messaging alone.

Email still has its place, especially in today’s reality when you have a global economy where teams are distributed across different countries with different languages and culture.  And with this comes the reduced available timezone bandwidth that don’t allow the use of real-time communication channels.

According to the article in Digital Trends, the CEO of Atos Thierry Breton says

“It is not normal that some of our fellow employees spend hours in the evening dealing with their emails.  The email is no longer the appropriate communication tool.”

“Companies must prepare for the new wave of usage and behavior.  If people want to talk to me, they can come and visit me, call or send me a text message.  Emails cannot replace the spoken word.”

For me, I agree with Breton and always prefer face-to-face conversation which explains why I find myself walking between office buildings in the city a lot.

Getting people together face-to-face provides richness in our communication through, tone of voice, eye contact, visual gestures and the ability to convey tacit knowledge.
– from my previous post

Maybe some level of pragmatism is required to educate people on when and when not to use email rather than having a zero email policy.

Posted in Lean-Agile | Tagged , , , , , , , | 1 Comment

Leadership styles

Donald Gray has written a great and interesting article on Three Leadership Styles, based observations on managing traffic at an intersection.  In the article the most successful leader is the one that sees people as “adults that most of the time they can take care of themselves, and that the role of a manager is to support these competent adults”.  To be effective, the leader should not place themselves at the center of the management task so that they can be much more flexible and effective at the key management activities.   A must read.

Posted in Leadership, Lean-Agile, Management, Project Management | Tagged , , , | Leave a comment

Useless sprint goals

A sprint goal helps to enable the team to focus on for the next 2 weeks.  What does everyone want the team to work on next?

 

The Scrum Guide [Oct 2011] states:

The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.  As the Development Team works, it keeps this goal in mind.  In order to satisfy the Sprint Goal, it implements the functionality and technology.  If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.  The Sprint Goal may be a milestone in the larger purpose of the product roadmap.

A sprint goal will be met through the implementation of the appropriate product backlog items.  Working with the product owner, stakeholders, customers and users, the team identifies the product backlog items it believes it can develop during the next sprint to meet this goal.  However, like many things in agile a key concept is ‘negotiation’.    A reason for having the sprint goal is to give the team some leeway regarding the functionality and technology it delivers.  During the iteration, the team determines daily how to meet the sprint goal.  If the work turns out to be harder than expected, the team might only partially implement the functionality.  At the sprint review meeting, the opportunity is given for the product owner and stakeholders to review how and what was implemented – they review how the sprint goal has been met.  If they are dissatisfied, they can make decisions about the product backlog, architecture, team composition or release plan.

For short iterations (e.g. two weeks), the sprint goal may not always add a lot of value.  With a two week iteration the team’s work may be sufficiently described that their goal becomes “complete the backlog items we selected.”  For some teams I’ve observed a sprint goal may be useful but usually having better thought-through product backlog items works better.  For these teams having release goals may make more sense than sprint goals.  The teams that benefit most from sprint goals are those who have  longer iterations (e.g. four weeks) or have just a few large product backlog items, as the goal provides some guidance as what we want to achieve and focus on.

Here’s an iteration goal for a team:

“Finish the agreed  forms, portlets and web pages for News and Media then pick up additional stories to increase the team’s velocity”

Whilst this goal is ok, it gives no room to negotiate – it’s a very ‘command-and-control’ type statement rather than a goal to work towards.  A small tweak by removing ‘agreed’ would provide some room for negotiation – Develop the forms, portlets and web pages for News and Media site.  In addition, the second part of the iteration goal, “[...] then pick up additional stories to increase the team’s velocity” may be better suited belonging in the team’s social contract rather than in the sprint goal.  ‘Doing more story points’ is an indirect result from focusing on WIP limits, pull, removing blockers, being a collaborative team and continuous improvement.

I have seen some sprint goals simply stated as “Complete x story points”.  This is a useless goal as it provides no focus on what to work on other than to do achieve a number of story points (which leads to other issues such as story point inflation).  So what if we have delivered ‘x story points’ if we didn’t deliver what the customer wants or delivered no business value.

So the idea behind a sprint goal is for the team’s output to be evaluated against the goal rather than the specific product backlog items they selected (there is a subtle difference).  In a way it gives the team the opportunity to say “Well we didn’t finish all the backlog items but we met the goal.”  Instead of having a sprint where we just ‘do more stuff’ the sprint goal can provide a theme the team can work towards.  A sprint goal could be:

“This Sprint we will allow users to do a basic search, and enable the results to be filtered and the view sorted”

Posted in Agile Practices, Lean-Agile, Project Management | Tagged , , | Leave a comment

Seeking the exact answers

“No battle plan survives contact with the enemy.”
– Helmuth von Moltke

Sooner or later you will have the business asking questions like “How much is it going to cost?”, “What will I get?” and “When can I have it?”.  The honest answer to this which often provokes a reaction of surprise are: “How much do you want to spend?”, “Tell us what you want” and “As long as it takes” respectively.

Technology projects are complex and high risk, and in particular there is high uncertainty especially before any actual development taking place.  The Cone of Uncertainty [McConnell] describes the uncertainty in estimates of software development project cost, effort, and duration, throughout the lifecycle of a project.   The degree of uncertainty is very large at the beginning of the project, which is often when decisions are made about project pricing and contracts which results in unrealistic project plans and expectations.

Agile or traditional, estimates on duration and costs are inherently very vague at the beginning of a project.  For some complex projects, this uncertainty can last much later in the development process.

We are so accustomed to fixed price, time & cost projects, but in reality they are anything but.  None of this information is new.  However, project sponsors consistently latch on to the initial estimates project managers propose for the schedule and cost of a project at the start when the least is known and when there is the highest variability.  And because project sponsors don’t understand project complexity and other factors influencing cost and schedule when requirements change and emerge, they may see the project as a failure if costs increased, even if the changes improved the value delivered to the business.  Unfortunately, business executives’ lack of understanding about project management influences their perception of IT project success and failure [CIO].

There is inherent uncertainty, even in well-run projects.  This is especially true in projects that involve complex software, large systems, large development effort, new application domains, new users.  Furthermore, unlike manufacturing or building a house software development is a creative process and largely knowledge work which does not fit a cookie cutter model.  We need to recognize that the Cone of Uncertainty implies substantial risks for traditional fixed-price and fixed-scope projects.  The Cone of Uncertainty indicates we cannot predict the future accurately and that we need to restrain from traditional thinking.  If you can’t predict the future, don’t plan it in detail.

A barrier to agile is the lack of the comforting predictive detailed plan whereby we plan out the uncertainty in a project, plot the path, determine the end date and the cost then produce the nice reports along the way.  Interestingly enough whenever we question “are those plans ever right?”  the response is often negative.  Yet we place so much faith in them and they absolutely have to be there because it would be too scary to proceed without one.

Agile practitioners will do an order of less magnitude less effort to come up with a plan and provide answers to the questions “How much is it going to cost?”, “What will I get?” and “When can I have it?” that are just as good and just as inaccurate as traditional approaches.

We strive to ask for exact answers when exact answers don’t exist (estimates are just an approximate judgment or calculation – it’s a guess, but we seem to forget that).    Reality will come to light soon enough.  Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy of the estimates to show for it.

An agile project will come up with a baseline view of how much the project will cost and when it is likely to be finished.  The only difference to traditional thinking is that agile is very explicit right from the start that this is not accurate and the team will strive to understand more as soon as we start working it.  We want to get to the actual development effort where we regularly deliver high quality, working software that maximizes the business’ ROI.

There is an amazing feeling of relief when agile teams can become comfortable with uncertainty and a freedom to actually discover what is needed at the appropriate time.  Instead of relentlessly following the pre-defined plan agile teams will adapt to the inevitably changing conditions.

Being on time, on budget and to specification means nothing when we have delivered the wrong product with low quality that has no business value.

So rather seeking the exact answers, should we be asking if we are delivering business value?

Posted in Lean-Agile, Project Management | Tagged , , , | 2 Comments

Focus the change on the situation, not people

In the book Switch: How to Change Things When Change Is Hard by Chip Heath & Dan Heath, the authors described the results of a study to answer the question: Would people with bigger popcorn buckets eat more at the movie cinema?

As part of the study, it was carefully engineered to serve the popcorn five days stale.  Some people received medium sized buckets and others got a large bucket.  The results were stunning:

People with the large buckets ate 53 percent more popcorn than people with the medium size. That’s the equivalent of 173 more calories and approximately 21 extra hand-dips into the bucket.

The book further states that other popcorn studies were always the same:

It didn’t matter if our moviegoers were in Pennsylvania, Illinois, or Iowa, and it didn’t matter what kind of movie was showing; all of our popcorn studies led to the same conclusion. People eat more when you give them a bigger container.”

No other theory explains the behavior. These people weren’t eating for pleasure. (The popcorn was so stale it squeaked!) They weren’t driven by a desire to finish their portion. (Both buckets were too big to finish.) It didn’t matter whether they were hungry or full. The equation is unyielding: Bigger container = more eating.

Recently in To Change Culture, Change the System David Joyce says:

Deming learned it’s not a problem of the people it’s a problem of the system that people work within. He found that if you want to change behaviour, then you need to change the system, and change management thinking that creates it. Doing so, culture change is then free.

To change someone’s behaviour, you’ve got to change that person’s situation.

Posted in Agile Culture, Lean-Agile, Systems Thinking | Tagged , , , | Leave a comment

Learning from mistakes – it’s all about continuous improvement

Kaizen (改善), Japanese for “improvement”, or “change for the better” refers to philosophy or practices that focus upon continuous improvement of processes.

Teams I coach frequently ask me for “best practices”.  Do not assume that “best practices” in previous projects will be equally successful in another project.  In some cases, “best practices” from one context can be counter-productive in another context.  Practices and processes from previous projects should be used for learning and improvement.  No practice or process is both complete and optimal – once we master it at one level, we see deficiencies that were previously hidden and the cycle of improvement begins again.  You should always challenge yourself to experiement and find better ways of doing things and beating your own standards for excellence - 

Improvement usually means doing something that we have never done before.
  — Shigeo Shingo

Mistakes are a part of being human.  Mistakes are not a sign of failure.  Appreciate mistakes mistakes for what they are – precious life lessons that are used for learning and for others to learn form.  Part of continuous improvement is learning from mistakes.  The only failure is the failure of not learning from your mistakes. 

Insanity: doing the same thing over and over again and expecting different results.
 – Albert Einstein

James Hird, the coach of the Essendon Football Club (a team in the Australian Football League (AFL)) took over the coaching of a team this year that was struggling to win games in recent years.  A priority for Hird was improvement in the team – “We’re trying to push for continual improvement.”

The club started the season well winning several games, however, they also made many mistakes along the way and had some big losses.  The club learnt many valuable lessons from those demoralising losses which enabled it to obtain an all-important victory against the best team in the competition.  One of the team players said:

“The coaches were never too up when we won and they were never too down when we lost.”

“The coaches are all just about learning, evolving and improving.”

Even when the team won games and making the finals was in sight, it was still about improvement and getting better.  Hird is solely focused on continuing to develop his team – “improvement first, finals second.”  Through continuous improvement, Hird believes they will build a good team that can compete effectively and achieve the goal of winning a finals premiership:

“Whether or not we make the finals this year… in 18 months time we want to keep coaching and teaching so we do become a good team.”

“Our team is not built on superstars it is built on all-round effort across the board.”

In a previous post, IDEO had a fail safe culture and which allowed them to fail often in order to succeed sooner:

 Enlightened trial and error succeeds over the planning of the lone genius.

It is important organizations foster continuous learning so teams constantly get better at everything they do—improving their work, making decisions, holding good meetings. That’s why successful teams emphasize continuous learning, always going over what they’ve done, identifying what went well and what didn’t, and finding ways to get better the next time around.

The following from Gemba Panta Rei highlights the importance of learning from mistakes through continuous improvemment:

Here are three important lessons from Irish novelist and playwright, winner of the Nobel Prize for Literature, and wicked wit George Bernard Shaw:

“A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing.”

We often say that continuous improvement depends on the ability of people to experiment, make mistakes, reflect and learn from the mistakes. It is truly honorable when leaders create an environment in which it is safe for people to experiment, fail and learn. In fact it may take more courage to allow others to make mistakes than to make mistakes oneself. The good results of these experiments we call kaizen, and the learning that occurs from poor results we call development of human potential. When we achieve good results free of mistakes we call it competence, but mostly it is luck.

“The power of accurate observation is commonly called cynicism by those who have not got it.”

While opinions and ideologies can be had and held with only minimal effort from our armchairs, facts require that we put forth some mental and physical effort. The act of observation requires presence and attention, the accuracy thereof open-mindedness and the will to release held opinions when they conflict with observed fact. Seeing the truth can be uncomfortable. Having truth that conflicts with one’s belief can be even more so. Pointing out the misconceptions in the minds of others can result in being called cynical or worse. Accurate observation must be preceded by and paired with education, alignment and commitment to act to improve a situation, regardless of our preconceived notions in order for continuous improvement to take root.

“The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.”

Posted in Agile Adoption, Agile Culture, Leadership, Lean Thinking, Lean-Agile | Tagged , , , , , | Leave a comment

I am an Agile Plumber

I am an Agile Plumber – I eliminate waste, remove blockages and increase flow.

This week we had an agile workshop to establish some goals and create some epics for next quarter’s release for the agile change team at an organization I am coaching.

One of the items we covered in the workshop was to come up with a new team name for our agile change team as a result of some organization changes.  Some of the names included:

  • Agile Change Team (A.C.T.)
  • Agile Capability Delivery Centre (AC-DC)
  • The Enablers
  • Centre for Agile Practices

….and there were many more.

When we went to vote on a name, a clear winner was Agile Plumbers.  This name was quite humorous at first and we all got a good laugh, but the name is symbolic and there is some serious intent behind it.

An important aspect of agile and lean is about eliminating waste, removing blockages, and increasing flow which can really can change the way you build software.

There are many forms of waste including partially done work, extra processes, extra features, task switching, waiting, motion and defects.  By looking at the waste that is in the steps you are doing and removing the waste you can do more with less.

We also have failure modes because we’re not paying attention to what it really takes to be agile.  There are many roadblocks and blockages to getting to success.  There are roadblocks that occur within teams and projects, but there are larger organizational roadblocks which are impediments to any agile approach.  Agile touches on many aspects of an enterprise organization and changes many existing organizational processes that are more acquainted to waterfall.  Examples include:

  • Procurement, such as selecting and working with vendors.
  • HR, especially what type of people we want to recruit, and changing manager’s KPIs to align more with a collaborative culture.
  • Finance, how we structure the organization’s funding model to align with agile approaches and incremental delivery.  Also funding may need to change to support a lean pipeline of work (continuous flow of work), rather than ‘individual projects’.
  • Legal, how we write contracts that support agile teams and approaches.
  • Training, creating training programs for agile (not only including agile specific topics, but also leadership and soft skills that are required in a collaborative organization).
  • Governance, most traditional governance does not work with agile.
  • Add your own organizational impact and blockage here that needs removing.

Finally, a goal of lean and kanban is increasing the efficient delivery of value through limiting the work in progress (WIP), making work visible and increasing the overall flow.  Optimizing the entire value stream, from initial concept to consumption is fundamental to increasing flow of value through the organization.  The idea is to get an idea into the development pipeline and out to the customer as fast as possible by looking at the existing processes and improving them and in the process eliminate waste and create value.

The other advantage of being called an Agile Plumber is that the name creates an memorable impression.  In a large organization with many business units and organizational teams, one thing that can be difficult is being able to identify where agile help can be found.

So next time you need someone to help eliminate waste, remove blockages and increase flow, call your nearest Agile Plumber!

Posted in Agile Adoption, Agile Culture, Lean Thinking, Lean-Agile | Tagged , , , , | 2 Comments

I want to run an agile project

This is all too funny!  Whilst the video is intended to be humorous, the pain of the “Agile Guy” maybe all too familiar for some.  Agile changes many things we have become use to over many years – agile questions the status quo and challenges our muscle memory……..

Posted in Agile Adoption, Agile Culture, Lean-Agile, Project Management | Tagged , , , , , | 1 Comment

Don’t collaborate here!

I saw a few of these signs posted up around an office site I visited today and was amused by it.  The office cubicles were also very high (‘Dilbert’ cubicles come to mind).  In fact they were high enough that we couldn’t see people’s heads.  The workspace was definitely reflective of a non-collaborative culture.

A couple of my recent posts on Facebook and IDEO illustrates how teamwork and collaboration is important to the success of those organizations – teamwork and collaboration is part of their DNA.

If you go to an agile workspace you will generally find it a hive of activity with a lots of collaboration and verbal communication.  Anyone not familiar with how agile teams work would mistake this as (unproductive) ‘noise’ and wonder how people get any work done.  However, most people in agile teams get use to the ‘noise’ very quickly and are able to filter out the ‘noise’.  The high amount of ‘noise’ on agile teams never bothered me.  I found myself naturally developing selective hearing whereby I only tuned into conversations that were relevant to me and ignoring the rest.  That’s why co-location is important on agile projects – to participate in the ad-hoc conversations as well as having the richness of face-to-face communication.

Posted in Agile Culture, Lean-Agile | Tagged , , | Leave a comment

What about Agile Documentation?

I have been asked countless times “how is documentation managed on agile projects?” or “can you give me a template for agile documentation”.  I have also heard statements like “we do not need to do any documentation when using agile”.  And more recently I was asked “how do I best document an agile build as it progresses….I want to build up a picture of what it does by documenting the requirements”.

To start off, let’s get one thing straight – documentation does actually exist under agile, albeit not in a traditional sense.  One of the most common misunderstandings is that agile = no documentation.  Agile is not anti-documentation or agile does not disregard or exclude documentation.  If you look at the Agile Manifesto, it states Working software over comprehensive documentation.  Now where does it state that there is no documentation?  The intent of this statement is that whilst documentation is important, the real value is producing working software that does something valuable for the business.

Anybody who actually works with code or close to the coalface knows that (overly) detailed and comprehensive documentation ages very quickly and actually becomes an impediment to respond quickly to business change as it diverges from the source of truth (the code).

One of the Agile Manifesto Principles that sums up the approach to documentation very succinctly and that is simplicity the art of maximizing the amount of work not done is essential.  Let’s be pragmatic on what documents are really needed and keep it simple.  Simple in number of documents needed, simple in the amount of detail and simple in the formality.  Like most agile approaches, we produce just enough documentation.  Keep documentation lightweight and simple – wikis are great and photos taken with a (phone) camera of whiteboard sketches often suffice.

The question you should ask yourself is what “value” does the document add to the process?  What purpose do the documents serve?  Who is the audience?  There needs to be a pragmatic balance of documentation (requirements, architecture, design) along with well structured, clean and readable code.

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.

– Dave Thomas, from Clean Code by Robert Martin (“Uncle Bob”)

This is an example where disciplined agile engineering practices is vitally important to the agile process.  Don’t be afraid to rely on team member to team member communication to distribute knowledge about the system.  Use pair-programming to share understanding with others so there are no dark areas and less need for people to document what has happened.

Another recent question I was asked is “how is business modeling handled in agile?”  The Agile Modeling website provides some guidance.  By Agile Modeling I don’t mean just UML – think ‘just barely good enough sketches’ on whiteboards – everyone should be comfortable bringing them on and in the language of the domain (ubiquitous language) – see Eric Evans’ Domain Driven Design.  Domain Driven Design provides some guidance on how you think of the domain, the language you use to talk about it, and how you organize your software to reflect your improving understanding of it.

Automation of tests is important at both the whitebox (unit tests) and blackbox (functional) levels.  These automated tests describe the behaviour of the system at the code level and functional level and as such by nature are a form of documentation themselves.  For example, a glance through a suite of functional tests, you should be able to get an understanding of the functionality of the system.  Unlike documentation, there is no fear of automated tests getting out of date as these will be constantly maintained to reflect the behavior of the system.  Therefore, clean code and automated tests are seen as the primary repository of detail on how the software was implemented.

There is no one right answer as to what documentation, how to write it, and who should create it.   However, constantly ask yourself before producing a document whether it is worth the effort to create and maintain it.  Keep documentation simple and produce just enough.  Documentation doesn’t have to be perfect – it just needs to be good enough for the purpose they serve.  Once there is no use for it, stop producing it.

Related links:

Posted in Agile Practices, Lean-Agile | Tagged , | Leave a comment