Don’t Always Believe What’s Been Written Down

At the turn of the millennium I was managing a project for a software house who had been contracted to develop a software system to support the sales process for a large financial institution.

I started off with the expectation that I would work with the client to detail a set of workshops that would produce the vision of the product, would capture the features of the product and would rank these features so that we could then take them into development over a number if iterations with our customer present, answering questions, further detailing what was needed and verifying the product did what they wanted it to do.

I couldn’t have been more wrong.

The starting point for my teams engagement in this project was a huge constantly changing beast of a document that detailed the sales process in minute detail. We were simply asked to go develop it.

Why did we need to understand the vision for the product? It was all there in the document.

Why did we need to talk to the client? It was all there in the document. If we needed clarity on anything then be sure to ask and we will get back to you.

The problem we had was that we just didn’t believe the document was complete or that the strategy for the product was correct. Eh – we were just the supplier and we were asked to develop it the way it was so why not just crack on?

In addition, the beastly document came with a high level description of how the process worked and hundreds of detailed forms that described the questions asked to the client as part of this Sales Process.

There were sample letters and reports that were to be fully automated, and simple examples of calculations that would work out client premiums and valuations.

The key business outcomes for the project were to reduce the overall time and cost it took to make a sale and to reduce the number of queries and rejections raised by the organisations compliance function.

It was absolutely essential therefore that the product automated the generation of the letters and reports that justified the advice and automated large parts of the compliance function to ensure that the advice was right first time.

As the story unfolded, and we were kept in the background, we found that behind each page of this document there where thousands of anomalies, inconsistencies and ambiguities that led to statements such as:

“It’s been agreed in principle” – translated to “We’re on the right lines but not there yet”.

Or

“It’s a placeholder” – translated to “We’ve no &%&*^% idea what’s supposed to go there.”

The detailed forms gave the impression that they were complete. Far from it, some basic ones were fine as these questions were always asked of clients (e.g. what’s your name?), but the forms that were there to support the advice given as part of the Sales Process fell well short of the mark. These were the critical questions as they were there for us to determine if the advice given was sound.

The calculations were too simplistic so as to be worthless and the automation of the reports and letters was proving to be impossible because of the errors in the forms.

The client was getting more and more frustrated with the problems with the beast of a document and it soon became clear that what was needed was an acceptance that the document wasn’t an appropriate vehicle for moving the project forwards and a new approach was required based on fast feedback cycles.

This lead to an intense three month period whereby my team camped out at the clients premises and delivered the requirements week by week.

The automation of the reports and letters was seen as a key justification for the project so the team focused there first as it was also the most risky. We were in danger of not being able to deliver anything. Fully justifying every recommendation was proving to be a nightmare, and most stakeholders agreed was a near impossibility. We therefore suggested a solution that was semi-automated which would still justify the business case but would be practical to implement. This included asking key questions up front, then, depending on the answers given, a consistency checker would run that would:

a)    Highlight any further questions needed

b)   Highlight any justifications required

c)    Highlight any risky scenario’s in the data captured and recommendations provided

These would all then be presented in a letter whereby the advisor could answer the additional questions, supply the justifications and understand the risky scenario’s.

The results of this letter would then be given to the compliance function which would highlight in red / amber / yellow paragraphs in the letter that they would need to check to ensure the advice was sound.

If there were no paragraphs highlighted, the letter would go through as accepted. Right First Time.

This approach was prototyped and demonstrated to the stakeholders and they loved it.

They endorsed the approach and could see the whole system shaping week by week over the following months. At its completion, the customer felt huge satisfaction in the part they played in shaping the product and as they took it on the road to train the advisors in its use were proud to demonstrate its functionality and glowed as the tributes came flooding in.

The starting point for my teams involvement in this project was the big document. It was just that, a big document.

But because it was big, it was deemed as complete (in principle).

The key thing here is that just because something is written down it does not mean it is right. Just because lots of things are written down, it does not mean it is thorough and compete.

We have a terrible affliction in that when we take the time and effort to write things down then somehow we think that we have put thought, analysis and diligence in our approach. Far from it, writing stuff down is a solitary exercise, the power lies in the hands of the guy with the pen and, as we know it, language has a terrible habit of being interpreted in many different ways.

As a software development team embarking upon a new project it is ill advised to take carte blanche a bunch of documents given to you that describe the product. They will describe the writers view of the product, it may even have been reviewed by the stakeholders to some degree, but it won’t contain the tacit knowledge garnered from their conversations and I’ve never come across one that contains the disclaimers it deserves (e.g. this section is incomplete, this requirement is vague, have a whole bunch of requirements we haven’t investigated yet but we run out of time so this lot is a best guess).

Regardless of your starting position, you will need to understand value from the customers perspective. You need to understand the business justification for the project and how this value is delivered by the product. You will need to translate whatever beastly documents you are given at the start into something that gets the product (even as a throw away prototype) into the hands of the stakeholders and users quickly.

You can’t always believe what is written down but if you can feel it, play with it and test your assumptions and hypotheses against it then this is the one source of the truth.

The product in the hands of those using it.

Saving Lives

In 2010, over 7500 people died of cholera world wide.

That’s 20 every day.

That’s 140 a week.

That’s 280 in a two-week Sprint.

That’s one hell of a velocity.

According to the World Heath Organisation[i] this was a 52% increase from 2009, attributed to an outbreak in Haiti following the earthquake in January 2010. The outbreak was so significant that 53% of this global total occurred over a period of just 70 days.

Cholera is caused by ingestion of food or water that is contaminated with the Vibrio Cholera bacterium that can rapidly bring on acute diarrhoea and lead to severe dehydration and ultimately death if treatment is not received promptly.

In May 2011, the World Health Assembly recognized the re-emergence of cholera as a significant global threat to countries that cannot guarantee access to safe drinking water and minimum standards for hygiene.

Consequently, almost every developing country faces the potential for cholera outbreaks.

Given the experiences in Haiti, a single catastrophe, such as the outbreak of war, an earthquake or a flood in a developing country can lead to a cholera epidemic of biblical proportions.

One of the main problems in containing cholera is the time it takes to identify a water source as being contaminated and for this source to then be quarantined and the community notified of this.

The sampling process is done on a monthly frequency, depending on the local population, and more frequently if an outbreak has occurred. In can take a number of days to test the sample in a laboratory and once the source has been identified as being contaminated it takes a significant effort to then communicate and isolate the source from use by the local population.

While this is happening lives are being lost.

Remember we have a velocity of 280 deaths per Sprint.

Now imagine we have a project that aims to provide the locals with a number of inexpensive devices that send an electric pulse into a sample of water to test for the presence of the Vibrio Cholera bacterium. The outcome is reported immediately and through a wireless connection in the device, the results are transmitted back to a centralized database instantaneously, that highlights the water source as contaminated or not.

This information is then used to communicate sources of contamination, understand where outbreaks or epidemics are likely to occur, which populations are the most at risk, and more importantly, it can help pinpoint the origins of contaminated sources.

The benefits of a successful project are numerous. The front-end devices can immediately warn or endorse a water supply for consumption, and the back-end analysis of the results across an area, country, continent or planet provides the ability to isolate the origins of an outbreak for rapid treatment. The end result, our velocity reduces from 280 deaths per sprint to a number approaching something more agreeable / acceptable / manageable…….no term seems appropriate where deaths are concerned….it is just less than 280.

Utilising our imaginations a little more, let’s now suppose we adopt a traditional waterfall approach to developing and delivering this project.

It takes 3 months to document the requirements in their entirety.

It takes 4 months to design the complete system, including the device and the back-end functionality.

It takes a further 9 months to develop then 6 months of testing before implementing a 6 month roll out plan across the globe.

That’s 28 months before we start to see the benefits. That’s the equivalent of 60 Sprints and, with a velocity of 280, that nearly 17000 deaths.

And that’s if the project goes to plan. What about all the risks?

  • Will the devices operate appropriately? How are they powered? Will they actually work?
  • Do they have a shelf-life?
  • How are they calibrated?
  • Does the continent have the appropriate infrastructure to support the wireless communications?
  • How are the devices distributed and the population trained in their use?
  • How do we roll out the devices in war-torn territories?

Given our past large scale project experiences, the schedule is more than likely to overrun, let’s say by a mere 50%. That’s another 8500 lives lost.

So to deliver the potential outcomes of this project using a traditional approach, it will cost millions of pounds and more importantly it will cost about 25000 lives.

Each day we delay delivering the benefits, it could cost 20 more lives.

Each week we delay delivering the benefits, it could cost 140 lives.

Each month we delay delivering the benefits, it could cost  560 lives.

Is a traditional waterfall approach appropriate for this project given the dire consequences of delayed Return on Investment?

So let’s assume the business case for this expects the project to not only reduce the number of deaths to pre-2010 figures, but to cut them further still by 20%. That’s a reduction of 72% from 7543 to 2112.

That’s 6 deaths a day.

That’s 40 deaths a week.

That’s 80 deaths in a two-week Sprint.

That’s a much worse velocity (but a better one given our unit of measure).

These savings are attributed to:

  1. 45% to the use of the wireless devices that immediately detects contaminated sources
  2. 20% to communication of contaminated sources in centralized database
  3. 35% to isolation of origins of contaminated sources and treatment to remove contamination

In addition, the business case also reflected which areas of the globe are most vulnerable to an outbreak of cholera. Based on figures collected by the World Heath Organisation the countries with the highest number of deaths from cholera are:

Country

Number of Cases

Number of Deaths

Case-fatality rate

Haiti

179,379

3,990

2.22%

Nigeria

44,456

1,712

3.85%

Cameroon

10,759

657

6.1%

This equates to 84% of the total of cholera related deaths in 2010.

Now there’s a great example of pareto’s law.

Given this information, the associated risks and a recognition that a traditional waterfall big-bang approach is going to not just cost a fortune, it’s also going to cost lives, what other approach could we possible adopt?

Now lets not fall into the trap of labeling the approach. We could call is Agile or we could call it Lean but for now let’s not, let us define an approach to the project that helps us start to meet our goals the quickest…..

In this project, time to market and product utility are paramount.

In this project, our biggest risk is the devices not being fit for purpose.

In this project, if we can get utilisation high in three countries, we are well on our way to achieving our ultimate goals.

If we can therefore implement the feature of the system that gives us the most benefit (i.e. the devices) that also attacks the greatest risk to project success early (i.e. the devices not being fit for purpose) in the countries most impacted (i.e. Haiti, Nigeria and Cameroon) then we start to save lives.

Consequently, our plan shows a number of releases over a two year period showing testing of the devices in Haiti before roll-out to Nigeria and Cameroon as our initial releases. The central database, the communications from the devices to the database, the infrastructure to support wireless communications and the complex analytical features are all added in later releases building the project incrementally.

The project develops a prototype of the device and demonstrates it working on known contaminated sources in a controlled laboratory within four weeks of project startup. There were some minor problems with calibrating the electric pulse, analyzing the results, and presenting the results back in a form that could be understood and acted upon with minimal training but these were rectified and the design of the device (which resembled a light-weight aluminium pen) was fine-tuned.

After four weeks, the go ahead was given to manufacture 10000 devices for shipment to Haiti. 1000 could be manufactured a week and each week 1000 were distributed to Haiti and locals were trained in their use.

The large scale use of the first 1000 devices detected numerous sources of contamination that would have led to ingestion of the bacterium but also marked a small number of sources as contaminated that did not contain the bacterium and would have provided water that would be safe to drink. The boffins back in the project modified the software, calibrating it so that these sources would be marked as safe and released this software for the second batch of 1000.

The role out continued, water sources were sampled and the number of cases and the case-fatality rate began to drop.

From the initial release of 1000, not only did the team quickly get feedback on how the devices worked in situ, they also spotted the need to be able to do software updates while the devices were being used in the field (the first 1000 had to be recalled and the software patch applied).

This caused the project to adjust their schedule so that the next release would cover setting up the wireless infrastructure so that patches could be applied to the devices using their wireless capabilities. This proved invaluable as numerous changes were made to improve the devices over the initial releases to Haiti, Nigeria and Cameroon.

Six months into the project, the death rate  attributed to cholera in Haiti, Nigeria and Cameroon had dropped by 25%.

Six months into the project we were saving  4 lives a day.

Six months into the project we were saving 30 lives a week.

Six months into the project we were saving 61 lives in a two-week Sprint.

If our target was to reduce global death rates by 72%, after six months from project startup we were 75% of the way there.

The approach to project delivery we are yet to label, with its quick feedback loops that validated our assumptions quickly, contained our risks while they were small enough to deal with and allowed us to get the key features into the target users hands quickly. It was the white labeled approach that was the key reason for achieving these benefits so quickly.

Now this is just a fictitious project, where we have used our imaginations to demonstrate why the approach described is so powerful. It is void of technique, but it is common sense, it is logical is it not when the unit of measure for success is saving human lives.

The intent of using this fictitious project was to shock. To carve the rational of why such an approach should be used on the readers memory. Talking about saving lives leaves longer lasting trails of understanding than if we talk about efficiencies or investments……

But our projects are different.

Yes they are. They always are.

They always involve different people who all have different personalities, different experiences, different skills and different values about how the project should operate and what it should do.

They always have different customers who have different priorities, different goals, different problems, different infrastructure and different cultures.

In our projects we measure success in market share, in pounds and pence, in return on a monetary investment, in increased profits, in reduced costs. Not in lives…..

Our projects use technologies that are proven.

Our projects are based on automating known business requirements. We know what we want.

Our projects use inexpensive resources in India.

Our projects are based on fixed price contracts.

Our projects are enterprise-wide and involve hundreds of developers.

Our projects are not driven by time to market they are legislative and all requirements must be there by A-day.

All projects are different but they all have one commonality. They are all based on a myriad of assumptions that remain until the hypothesis has been proven. The best way to prove a theory or validate an assumption? Do the work and get the feedback. If the feedback proves the supposition then stay calm and carry on, if the feedback suggests an alternate is true then adjust, calibrate and try again.

Hopefully, by now you understand why the white label approach described in saving lives is a better approach to a traditional waterfall big bang approach. That the approach evolved because it was what was needed to start saving lives NOW! Not in 2 years.

All projects are different but they all have another commonality. They all have a myriad of statements about what the system should do. We call these requirements. Each of these statements is an assumption about what is needed, what problem is being solved or how the system should work. Each of these statements should provide some value to some entity of the systems external environment.  The totality of these statements covers a complete description of what the system should do and why.

However, they are still assumptions and still need to be validated. They are all statements of intent that need to be communicated. They are expectations. We therefore need feedback loops in place to quickly understand what we are trying to achieve, to ensure that those who work from these statements of expectation get it! and we need to validate that we are on course to achieve it.

We need to ensure we are doing the right thing and we all agree on what that thing is.

The best way to know this is to just do it.


[i] Weekly epidemiological record, 29 July 2011, No. 31, 2011, 86, 325–340, http://www.who.int/wer/2011/wer8631.pdf

Kanban and Retrospectives

Kanban is a tool that helps us achieve continuous flow by setting limits on the amount of Work in Progress that can be in a products value stream at any point in time.

Kanban also offers us the concept of heartbeats or cadence against which we can perform regularly scheduled activities.  However, we should be cognisant of leans pursuit of perfection so the use of cadence type activities should be treated with care. As our organization and project team matures, we should be aiming to respond to changes in priorities as they happen and not on scheduled weekly, fortnightly or monthy heartbeats. Failure to react immediately could result in producing less valuable items which would be plain muda.

While we are still in our infancy and we are trying to resolve some dysfunctions in our current setup, cadence can be a helpful tool to ensure we get the relevant people together to perform vital activities.

For example, we can set a cadence of one week to revisit and reprioritise the items for inclusion on the Kanban board. Similar to Scrum’s Sprint Planning.

We could set a cadence of 4 weeks to review and reprioritise the items in a release plan. Similar to Scrum’s Release Planning.

We could set a cadence of 1 day to review queues / blocks / impediments. Similar to Scrum’s Daily Stand-up.

We can also use a cadence of 2-4 weeks to perform an analysis of our current approach as a means of acquiring a means for continuous improvement. Similar to Scrum’s Retrospective.

There are a number of different helpful techniques for running Agile Retrospectives (see Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen) and these can be used as appropriate.

A simple approach is to allow a short amount of time for the team to identify what made them glad, what made them mad and what they would like to change.

The team can then vote on their favourite three change actions and implement those changes.

This works well in Scrum or when using a cadence in Kanban. However, the lean team are actually looking to refine the value stream by removing waste and reducing cycle time (or takt time as it is called in lean) from the customers ask to the customers get in an attempt to improve flow and improve quality. This should be the focus of the retrospective rather than basing it on what went well, what went badly and what we want to change.

The value stream needs constant attention and needs relentless improvement.

Once these improvements are made we can then start to see the impact on our cycle time (since we plot the average cycle time each day we can visualise any improvement very quickly).

We can happily do retrospectives this way every four weeks using cadence to step back and do a drains up on how we do things as a team but we should also supplement this with something that is more specific and more timely.

The following 3 techniques may help with this.

  1. WIP Limit on Issues
  2. Root Cause Analysis on Blockages
  3. Retrospective on completion of each item

WIP Limit on Issues

Just as our Kanban system has WIP limits on each activity in the value stream, we can apply a similar concept to our issues / impediments board and place WIP limits on the amount of impediments that are allowed to be open before the teams resources swarm on a resolution.

The problem resolution team can look at why the impediment occurred, what can be done to resolve it and how it can be prevented from happening in the future.

Root Cause Analysis on Blockages

Using a cadence of one day to review the Kanban board we can do something similar to Scrums Daily Stand-Up.

The difference here however is that in Kanban we do not care about what happened yesterday and what is happening today. We review the kanban board for evidence of queue’s building and blockages forming.

When this is spotted, the team can swarm on the problem and resolve it, doing a root cause analysis while the information is still fresh with plans to implement changes so the queue / blockage does not happen again.

Retrospective on completion of each item

Another option is to include a review of the approach to delivery on completion of each and every item (i.e. a retrospective swimlane at the end).

Again we can set a WIP limit on this so we are forced into a retrospective when the limit is reached.

When this happens, a select number of the team congregate and review the value stream for each item and what can be done to improve flow, throughput and quality.

If this is done on each and every item, rather than on a small batch of items (as defined by the WIP limit) then the team members involved in the value stream for this item can quickly meet for 10-15 minutes to discuss and agree improvements based on fresh and relative information.

In Summary

In Scrum we use retrospectives to view what made us glad, what made us sad and what we want to change. Which is great – just as long as we then go change things – otherwise just another history lesson.

In lean however, improvement is relentless. So much so, that the objectives of the project focus more on learning and making improvements than on delivery.  The goal is learning, not delivery. Completely counter-intuitive to the traditional delivery focused managers and organizations.

In addition, lean has this view of perfection and it is part of its guiding principles. Scrum doesn’t. Scrum just wants us to improve….Lean wants us to define what perfection means to the organization then strive to achieve it. For me, the latter summons all sorts of powerful emotions and motivations; the former makes me want to do just about enough.

What can be observed about process problems in software development is that they often show up in the boundaries between one units work and another’s – the handovers.

These typically generate detailed specifications that clearly state, in a contract like manner, the information that crosses the boundaries. One approach to this is to specify the boundary conditions as tests. If the test fails, the problem is identified quickly and can be solved immediately by the team doing the work. Thus feedback and therefore learning is relatively immediate.

Also, in Scrum, boundary crossing impediments are often handed over to the Scrum Master to resolve. This may be convenient but is far from ideal. Those best placed to solve a problem are those who are suffering because of it. The Scum Master can help mentor in its removal but the actual team member who has the angst will also have the drive to see it removed.

In the form of a Retrospective, Scrum teams are encouraged to reflect on how they could improve. However, we often find that these Retrospectives only identify problems but fail to diagnose them and identify, plan, implement and assess the change actions that will eradicate the problem from arising again.

One Lean technique used in problem solving is the five whys.

Taiichi Ohno, father of the Toyota Production System, believed that “by repeating why five times, the nature of the problem as well as its solution becomes clear.”

As an example, we often find that when developing software in iterations against a definition of done, our stories fall short of achieving said done-ness.

Problem:

We regularly fail to complete stories in a Sprint

Analysis:

Why 1 – we don’t have enough time to test them all

Why 2 – the stories are too big

Why 3 – because they are initially too vague to break down any further

Why 4 – because our development team don’t understand the detail of the requirement

Why 5 – because we don’t work with the customer and the tester enough to understand the acceptance tests prior to starting development

Solution:

Customer, tester and developer to define acceptance tests that accurately specify the requirement for each story a Sprint ahead of the Sprint they are to be developed in.

Kanban and Release Tracking

Value is delivered in releases.

In the project world, releases are scheduled and release content is defined upfront. Progress towards that release is monitored and, if behind schedule, trade-offs between release content and release date are made.

In Scrum we define the release content, size the content in story points, measure the number of points we complete each Sprint (our velocity) and work out how many sprints we need to complete the job.

This level of tracking gives us a good view to measure our progress and adjust accordingly.

Kanban does not prescribe an approach to release planning and tracking.

However, this does not mean it shouldn’t be done. You need to do as much release planning as you need. If there are no dependencies on your release, which is rare in the project world, then do you need to do any release planning at all? If the need is to fix a critical defect rather than meet some legislative drop-dead date, then the lead time to release is entirely dependant on the time to fix that defect.

When progress towards a release date with an agreed release content are important measurements to you (as they tend to be in the project world) then a mechanism is needed to size the release, track progress of completed items towards the release and extrapolate time remaining to complete that release based on current performance.

We have this using a release Backlog of User Stories, Story Points from Planning Poker, Iterations, Release Burndown and Velocity.

However, it is often argued that the overhead of planning and estimating that surrounds a Sprint can be waste so how can we achieve measurement towards a release without Iterations?

As a starting point we need a measure of size. One suggestion would be number of stories or features though this is problematic as stories / features in the immediate vicinity of development tend to be more granular and those stories in the distant future tend to be larger. If this is the case, then our current delivery (e.g. average of 10 stories per week) cannot be used to determine an end date as the stories developed will be wildly different in size and complexity than those remaining.

This is why we need a method to size backlog items relative to each other. Planning Poker and story points are excellent candidates for this.

The customer (i.e. Product Owner) will select the stories required in the next release from which we can then determine the size of the release.

We can then start to capture the number of story points completed every single day and from this extrapolate the following measures:

  • Story points completed per day
  • Story points completed in the last 5 days
  • Story points completed in last 4 weeks
  • Story points completed in each 4-week timebox
  • Total planned points for the release
  • Release Burndown

This can be plotted as a visible indicator of progress as shown below:

This gives us the ability to measure trends over static periods of time (Velocity) or a rolling velocity which shows immediate trends of days and weeks. In the latter we can look (on a daily basis) to see if we have a volatile flow (if last 5 days goes up and down sporadically) or whether we are suffering from process bottlenecks and cycle time impediments (if last 5 days / last 4 weeks starts to show a trend downwards). What we are also looking for here are trends upwards. If our rolling velocity remains static then we are not continuously improving.

It also allows us to plot release burndown which we can use to determine if we are on schedule for the agreed release date with the agreed release content.

We do not need iterations to do this. All we need is a release content, for each item in that content to be sized in relation to the other items, and for us to capture how many points go in the “DONE” column each day.

Organizational Agility

Are you doing enough or just doing enough?

What defines Agile?

We know its a culture rather than a set of techniques and practices and tools (well, by now, I hope we do).

We know its aims are to embed an ability to do things better, faster, cheaper and be happier; otherwise why do it?

We know its infectious, it’s growing, it’s embedding itself into all walks of the organisation; just like lean has moved from its roots in building cars into the medical profession, administration, service industry, etc. agile is being adopted outside of software delivery.

We also know, from our long history of “improvement initiatives” that they plateau and dissolve, that there is a high probability of them being abandoned once the latest management gimmick is replaced by the latest management gimmick. I often wonder what that new gimmick will be.

So what defines an agile organisation?

It is still about a culture over a process.

It is still about the driver for being better, faster, cheaper and happier.

It can only be achieved if the culture and the drivers are the guiding light for the whole organisation. That it is not an “improvement initiative”, it is the organisations life blood and heart beat.

When it comes to deciding to implement “improvement initiatives” it is often in response to some organization threat or crisis. The problem with this is that, while operations are plodding along nicely and smoothly, you are developing an organisational culture which endorses “just doing enough”.

As an organisation it is time to stop “just doing enough” and start to ask “are we doing enough?”

Defining Organizational Agility

An Agile Organization can be described as one that has the ability to anticipate and respond quickly to changes in its environment to identify and maximise the return from an opportunity or avoid the costs of a threat.

Agile Organizations are imaginative and innovative. They develop simple but brilliant high value solutions. They recognize that Innovation and leadership are key to their success.

Agile Organizations do not rest on their laurels, they do not wait for a crisis or an opportunity. They constantly strive to increase value, reduce costs and improve the customers’ experience.

Agile Organisations value organizational learning through continuous feedback cycles of plan, do, inspect and adapt.

Figure 1. Organizational Agility

Agile Organizations have a well-communicated and clear organisation mission and set of values fostering a culture of execution focused on achieving clear unambiguous measurable objectives.

Agile Organizations receive, generate and share knowledge. Knowledge management and collaboration are key and silo based departments and information are avoided.

Agile Organizations embrace change. The portfolio of on-going work is constantly managed and refined. Projects can be started, executed or abandoned for high value work without de-railing the achievement of the organizations goals.

Agile Organizations demonstrate fast decision making based on trust.  Quick decisions are made at all levels.   Lengthy, centralized, long-winded review and approval processes are avoided at all costs.

One type of organization that must demonstrate true Agile qualities is that of a Startup. An organization that thrives on new ideas, on innovation.

I introduce this type of organization in The Light Bulb Moment.

Smelly Stand-Ups

The Daily Stand-Up is one of the wider known and frequently utilised techniques coming out of the Agile arsenal of practices. Why? Cynically, some might argue the Agile newbies think the Daily Stand-Up is Scrum or even Agile. 10 years ago, to the uninitiated, agile meant not writing requirements down and developing stuff in pairs, and now, to a new breed of uninitiated, it means standing up (or at least leaning with a coffee cup in your hand) and talking about stuff you did yesterday, stuff you think you’ll do today and a brief moan about anything that’s getting in your way.

If I take my cynical glasses off then the Daily Stand-Up is so widely adopted because it’s such a simple technique that engages the whole team, synchronizes their work and fosters collaboration on a daily basis ultimately helping to lead to total collaboration across the whole team. It’s a whole team technique that provides rapid feedback and a rapid, constant flow of feedback is essential in learning, which is essential for improvement, which is essential for delivering the right stuff when it’s needed……

It really is truly simple and effective. To do it, the whole team meet for a short (15 minute) stand up meeting where each individual takes a turn answering three simple questions:

  1. What did you achieve yesterday?
  2. What are you aiming to achieve today?
  3. What obstacles are getting in your way?

Let’s face it, if all you need to do is stand-up and answer 3 simple questions, what could go wrong and what harm could it do?

As an example, the conversation below has lots of smelly problems (each one labelled SMELL then described after the conversation). All these odours have some impact on the effectiveness of the Daily Stand-Up (and perhaps the effectiveness of the whole team), so, rather than leaving you retching at their stench, I suggest some deodorants that may help make your Daily Stand-Up smell of spring flora once again.

Read on (with a peg on your nose)…..

In a meeting room in an office not too far away, the members of s Scrum team in attendance sit around a desk, most of them slouched [SMELL1] as they wait silently for Sally the Project Manager turned ScrumMaster to load up her progress spreadsheet.

“I’ll start”, said Bob the Developer as Sally the ScrumMaster gives the signal the sheet has almost loaded. “I have another meeting to be at so need to drop out after twenty minutes.” [SMELL2].

“Yesterday I worked on the Checkout Widget story,” Bob the Developer continued, looking Sally the ScrumMaster firmly in the eye [SMELL3]. “Today I’m going to carry on with it. No impediments.” [SMELL4] [SMELL5]

“Will you finish it today?” asked Sally the ScrumMaster, visibly showing signs of frustration. “You’ve been working on this for two weeks now. What’s wrong with it?” [SMELL6]

Bob looks uncomfortable. “Well it’s not as simple as I first thought. I’ve almost finished but I have to develop the link to the payments engine and I’m struggling with it. We still don’t have the API documentation so I’m guessing my way through. I told you this last week.”

“Okay. I’ll email them later but I have monthly reports to get out first.” [SMELL7]

The team sit around the desk [SMELL8] and wait patiently as Sally’s fingers frantically tap away at the keyboard [SMELL9]. Once she has finished typing in Bob’s update she turns to the next developer.

“John,” she asks. “Have you finished your story?”

“Yes. I finished it last night. I was here until 10pm wrapping up the last of the tests,” he beamed. “What next boss?”

“Well done,” [SMELL10] Sally the ScrumMaster beamed back. “Move onto the Change Address feature.” [SMELL11].

Again all wait as Sally the ScrumMaster types up her notes.

“Jenny?”

“I’m working on the Store Finder story.”

“Is it done?”

“Not yet. I need to work out how to interface to Google maps. It’s a low priority feature but it’s a good one to get my teeth into.” [SMELL12]

“I’ve done something like this before….” Julian the Architect begins. “I was working on a Book Publishing system 2 years ago….blah, blah, blah.”

…several minutes later….[SMELL13]

“…it was hard but ultimately rewarding….”

…others join in the conversation as the problem is gradually solved…

“I think that will work,” said Jenny the Developer smiling.

“I have to go now,” said Bob the Developer. He gets up and leaves the meeting.

“Can I ask something?” Claire the Product Owner interrupts. “How long will it take to complete the Process Payment user story?” [SMELL14]

“I’m doing it next,” says Jim the Developer. “It’s big so will probably break it down over three Sprints. Should be done release after next.”

“Not good enough,” says Claire the Product Owner. “This absolutely has to be in the next release.”

“Make it happen Jim,” says Sally the ScrumMaster. “John you can help!”

“But it’s pretty complex and I’m not convinced we can chunk it up for two people to work on.” Jim the Developer looked worried.

“Just find a way Jim. John can you do it quicker?” [SMELL15]

“I can have a look and get back to you tomorrow.”

“Excellent,” Sally the ScrumMaster smiles.

Having typed in her notes once more, Sally the ScrumMaster looks for Craig the Developer.

“Where’s Craig?” she asks.

“Not in yet – he doesn’t get here until 10,” Jenny the Developer pipes up.

“Okay. I’ve also asked Alan to update some stats for my meeting this afternoon so he is excused.” [SMELL16]

“How is he getting on with his stuff?” asks John the Team Lead.

“Not sure. He can give us an update tomorrow.”

“Will Matt the Senior Developer be here tomorrow?” asks John the Team Lead.

“What do you think?” replies Sally the ScrumMaster. “He came to the first two but doesn’t see the benefit. I’ve excused him also. Plus he has the config and build stuff to maintain and it’s all in his head. He’s bogged down in support issues all the time. We just have to figure a way to share his knowledge.” [SMELL17] [SMELL18]

At that moment, Doug the DBA arrives. “Sorry I’m late again. I have to run some DB stats for Matt every day so can only make the tail end.” [SMELL19]

“Okay,” Sally the ScrumMaster responds. “How you getting on with the database scripts?”

“I’ve reviewed John and Jenny’s scripts and updated the stored procedures against our Oracle standards and made some performance improvements. I’ve emailed them to Matt to include in the build and get the test environments updated. Today I’m going to have a look at reviewing some of John’s earlier developments. Ones he did before I joined the team.” [SMELL20]

Sally the ScrumMaster finally turns to Dave the Developer. “How are you getting on with your story?”

Dave the Developer contemplates for a while…”Let me think. I’ve slept since I last worked on it and went through my emails this morning before the Stand-Up [SMELL21]. I think I’ve finished it. I’ll check and get back to you [SMELL22]. I think it’s probably worth running the tests again at least.”

“If you finish today then what’s your next assignment? I don’t have access to the backlog here and can’t remember what I assigned you,” explains Sally the ScrumMaster.

“Can’t remember myself. I’ll have a look at my emails when I get back.”

“Okay, that’s it,” Sally the ScrumMaster says. “I’m in a management meeting tomorrow and the day after that, then it’s Friday. Let’s can the daily meeting until Monday. How’s that suit?” [SMELL23]

“Yes please….” they all look really happy about this [SMELL24], including Sally the ScrumMaster, who congratulates herself on another well run Scrum.

SMELL1: Lack of energy

The Daily Stand-Up should feel like a high energy quick focused meeting. If there is an observable lack of energy in your team then you need to get to the bottom of this. It could be that your team don’t believe the Daily Stand-Ups are worth it, that they are paying lip service to a new management gimmick that is being forced down their throats (this years Scrum is last years  RUP). If this is the case you need to understand why this is and  address it. Look for other smells (absences, not addressing impediments, etc.) and talk to your team members off-line. Talk to all of them. Try reviewing what the team thinks of Daily Stand-Ups at Retrospectives but still make sure you talk to them off-line as the team may have a similar lack of energy during Retrospectives and the real issues may not come out.

This lack of energy could also be to do with timing. Doing them first thing or last thing may bring with it an inherent inertia or just plain tiredness. If this is the case consider doing just before lunch.

It could also be to do with the team size, duration and the choice of sitting rather than standing. Try keeping the meeting to 7 +/- 2 people, less than 15 minutes, take  discussions off-line and make all standing to help maintain focus.

SMELL2: Leaving half way through

Although not as bad as not attending at all (half as bad maybe), leaving half way through means that others work is not synchronized with yours. This is not a status assessment where an individual feeds their progress back to a leader then switches off while the rest of the team have their go. This is about synchronizing team members work so attending for the duration is essential.

This is potentially linked to duration and timing. Make sure your meeting is limited to 15 minutes and is done at a time that doesn’t overlap with others commitments (first thing, last thing or around lunch are usually good candidates).

SMELL3: Feels like reporting to a leader

To repeat – THIS IS NOT A STATUS MEETING!

The meeting is not for a leader it is  for the team. If this happens then it is a threat to productivity in that the feeling of management control directly impacts a teams commitment to their responsibilities and affects their desire to be a self-organising team.

If this is happening then consider rotating the facilitator. Try having today’s facilitator choose tomorrow’s facilitator. If you are the facilitator and feel like you are being reported back to then break eye contact, move position, let others speak in gaps of silence. Also try using a token to pass the baton of who speaks next rather than the facilitator prompting the next person to speak (but before doing this make sure your team don’t bring cups of coffee with them or they will either drop the baton or spill the coffee).

SMELL4: Objectives of the Stand-Up are not clear with the focus on getting done in 15 minutes and not on synchronizing team members work

If it’s not done in 15 minutes then it’s probably not working for one or more of many reasons: too many people, in-meeting problem solving, late arrivals, sit down meeting, observers interrupt and timing.

Make sure your Stand-Up is limited to 7 +/- 2, that discussions are taken off-line, that the time and place of the Stand-Up is fixed and communicated clearly (e.g. always in War Room 1 at 10:15), that the members (where physically appropriate) are standing, that attendees who are invited as observers (e.g. managers, users) understand that they are not allowed to interrupt and ALL cases are taken off-line. Make sure that the meeting is at a time that encourages completing in 15 minutes (e.g. 15 minutes before lunch).

However, watch out for the side effect of trying to get done in 15 minutes which is the essence of this smell. This occurs when the focus of the meeting is to answer the three questions in 15 minutes. This is NOT the objective of the Daily Stand-Up. The objective is to synchronize team members work.

Simply saying “Yesterday I worked on the Checkout Widget story. Today I’m ging to carry on with it. No impediments.” answers all three questions in a short time-frame but fails to meet the objective.

Instead if John had said:

Yesterday I worked on the Checkout Widget story. I have designed the UI based on the sketches I came up with Claire the Product Owner and have developed the tests to cover the happy day scenarios. I could do with getting together with Claire to make sure the UI is good to go and also flesh out some more edge cases around the tests which we can build as FitNesse tables. Can we do this today Claire? I’m also struggling with the payments interface as I need the API documentation. Has anyone worked on this before or can you chase up the documentation Sally as I’m getting nowhere? I’ll also need some of Doug’s time to look at the database scripts. if I can understand the API, pair with Doug to finish off the database scripts and get the tests and UI work done with Claire I can get his story done today. Jim is this okay with you as I know your desperate for me to finish this so you can crack on with the Process Payment story. Only impediment I have is the API documentation not being available and this is a real blocker.”

Much better!

This synchronizes what John is doing with Doug, Jim and Claire, gets the impediments out and actioned with Sally (especially if you have an impediments board) and gets commitment from John and the others to get the stories done.

SMELL5: Say one thing in Stand-Up another outside

Everyone’s different. Some people like to talk (and cause your 15 minute meeting to take an hour) and, on the flip side, some people are uncomfortable talking much at all and just want to get through it.

In addition, people get moody and can be garrulous one day and button-lipped the next.

You need to encourage each team member to open up and talk like John did above (well the new John anyway). You can’t force them, remember this, or this can be regarded as a form of bullying and is unacceptable.

If it’s down to the above then note this and try talking to the team member outside of the meeting. Don’t let their quietness foster as it could turn into mistrust and tension. Nip it in the bud and encourage them to open up by explaining why the Stand-Up is important and why they need to contribute.

However, this smell could be the symptom of something more sinister. In the example above, it is clear that John thinks the Stand-Up is pointless. He doesn’t understand that the objective is to synchronize team members work, he doesn’t believe his impediments are being addressed and he just wants out the meeting as soon as possible. See SMELL4: Objectives of the Stand-Up are not clear with the focus on getting done in 15 minutes and not on synchronizing team members work, SMELL7: Impediments not removed and SMELL2: Leaving half way through for more information on these smells.

SMELL6: Confrontational

Oh dear, our leader is doing everything she can to eradicate the team’s desire to be collaborative. Trust is the glue that binds a team, collaboration is formed on the basis of trust, trust is earned and not given away…and once lost, it is hard to retrieve and nothing eats away at trust more than aggressive confrontation (how many cliché’s there?).

This is a form of tyranny that  will prevent a team becoming self-organising and will directly impact productivity.

A well run Scrum not only synchronizes team member efforts it is supportive not confrontational.

SMELL7: Impediments not removed

Being supportive also means making sure that you meet your end of the Agile bargain. If impediments are raised during the Stand-Up and they are not owned and addressed then the team will begin to believe that the Stand-Up provides little value and they will either stop attending, will come late, will lack energy and will not report impediments (a bit like Bob).

One of the main reasons for this is that impediments are not captured and are forgotten or ignored. To avoid this, or at least make it difficult to forget them, slap your impediments on an impediments board with your backlog. At the end of the session check that they are being addressed.

The prime responsibility of the ScrumMaster is to support the team. Key to this is ensuring that the teams impediments are removed to allow them to flourish and then surge.

SMELL8: Sitting down not standing up

It’s not called a Stand-Up meeting for nothing. We stand up to keep the meeting short. We stand up to feel in a huddle, to keep the conversation volume low as some people don’t feel comfortable having to raise their voice so that they are heard the other side of the room / table. By standing up we can get closer together and feel a level of trust that this closeness brings.

Couple of things to bear in mind though. Don’t get too close and invade personal space and if someone is suffering during the Stand-Up (e.g. they have a bad back) then consider sitting rather than isolating the individual. Just be aware that this will probably impact the time it takes to run the Stand-Up.

SMELL9: Meeting notes kept

This is a meeting for the team by the team. As already discussed. this is not a status meeting for the leader. This is a meeting to ensure the team are committed and are synchronizing their work. This is about communication and collaboration.

Having an individual take notes puts the power of recording the meeting in their hands. Avoid this as it will make team members feel uncomfortable as they do not know what the writer is writing.

If things come up that need to be recorded so they are not forgotten (e.g. problems or impediments) then put them on a card or post-it and make them immediately visible on an impediments board or a problem parking lot.

SMELL10: Avoid giving praise

Saying well done or thank you gives the impression that this is again a status update for the leader. If you do this for one member but not another then the other will be left wondering why. This may bring a smile to the face of one but has a more negative impact on the majority.

SMELL11: Leader assigns work

Having a leader assign work to team members is a sure-fire way to excuse the team from accepting responsibility which in turn damages the desire for the team to become self-organising. For a traditional Project Manager turned ScrumMaster, with years of detailed planning and task management, this can be a difficult habit to break…but break it they must.

While this happens, the team will look to their leader for guidance. When they finish tasks they will wait to be assigned new ones, they will not look to collaborate and help other team members out, and, if the leader is absent, then essential activities that should happen regardless of their presence (Sprint planning, Daily Stand-Ups, Demo’s, Retrospectives) will be skipped.

SMELL12: Backlog not in context – work on low priority features

If the Stand-Up takes place away from the information radiators then it is difficult to keep the team aligned to the priorities. The key information radiators that help with this are Sprint Burndown charts and the Agile White Board. The former shows the amount of work still to complete (in your chosen unit of measure) and the latter shows the backlog of items in the Sprint, whose working on what, what state the items are in and which items have associated impediments (usually identified with a red sticky dot on the task / story card).

This information can be kept in a tool, and in many circumstances this is essential (geographically dispersed team, sensitive / secure information, powerful crazy furniture police). However, if a tool is used during the Stand-Up rather than a whiteboard then it’s not easy to huddle round and one person is in control of what gets entered into it during the Stand-Up…not to mention you now smelling like SMELL9: Meeting notes kept.

With this information (which should be updated before the Daily Stand-Up starts) the team can ensure they are working on the correct items. Without it (and without it up-to-date), it is difficult the keep the backlog in focus during the Stand-Up and make sure that the members are working on relevant items.

SMELL13: Problem solving & story telling

It’s very easy to start solving problems or go off at tangents. If this happens then the meeting can run on and on and on with the majority of members becoming increasingly frustrated and contemplating the value of the Daily Stand-Up.

Ways to resolve this are to communicate that this is a 15 minute meeting and ensure that the meeting is a stand up. If problems start to get discussed then politely remind the culprits to take it off-line. This will help if you have a problem Parking Lot. If the conversation starts to head down this route then record the problem on a post-it, put it in the Parking Lot and request that the meeting moves on. At the end of the meeting, review the Parking Lot items and work out who needs to be involved in resolving the problems.

Another technique is to use a token that is passed from one team member to another. Only the possessor of the token is allowed to speak unless you are directly addressed by the token possessor. When the token holder is finished, the token holder then chooses who to pass it onto next.

SMELL14: Observers talking (how very dare they!)

If you are going to get through this in 15 minutes it will need to be focused. Having observers (managers, stakeholders) interrupt the meeting with questions, observations, etc. disturbs the flow of conversation.

These questions may provide the observer with information they feel is essential and the observations may enlighten the team to a problem or requirement they hadn’t anticipated. It may also be argued that not allowing observers to talk is a guideline and such interruptions should be welcomed in that they add this value. Mike Cohn states in Towards a Catalogue of Scrum Smells:

Allowing chickens to talk can be a slippery slope. If a chicken is allowed to make a comment one time (when the comment is useful), how do we later prevent a chicken from commenting (when the comment may not be useful).

If, at this point you think all this discussion on talking chickens is a bit bizarre then let me point you to the explanatory joke (in the loosest sense of the word):

A chicken and a pig are together when the chicken says, “Let’s start a restaurant!”

The pig thinks it over and says, “What would we call this restaurant?”

The chicken says, “How about Ham n’ Eggs?”

The pig says, “No thanks, I’d be committed, but you’d only be involved!”

[Shwaber and Beedle, 2001]

In a Daily Stand-Up, only pigs are allowed to talk (developers, testers). Chickens are the observers (management, customer, other stakeholders).

If this is allowed once, then where does it stop? Pretty soon, the 15 minute rule is broken, the interference appears as questions are asked by management, problems are solved by stakeholders and the whole focus on the 3 questions gets diluted and the meeting turns into a traditional progress meeting and, eventually, the team members stop attending and a nominated team lead is sent to discuss all things progressee with management and stakeholders.

This rule of only pigs talking needs to be honoured and the facilitator must direct observer interference to the Parking Lot (not literally as in FIGHT! I refer to a solution to SMELL13), so the topic can be dealt with after the meeting by affected parties. This helps prevent the scenario where the chicken in question may feel that their input is being ignored and adversarial relationships may begin to develop. If items are put in the Parking Lot and resolved off-line then the chicken feels they have a medium for communication but recognises that the Daily Stand-Up isn’t it.

SMELL15: Leader overrides estimates

The Product Owner makes all decisions on the backlog but the team make all decisions on estimates and how the work is done.

The Product Owner says what, the team say how and how long.

If the Product Owner or ScrumMaster start to override the teams estimates then this will cause team members to stop estimating or will cause team members to pad their estimates. The resulting effect being that estimates no longer give any gauge to how long we think the work is going to take so are thus irrelevant. Not good is it!

The more important side effect of this though is the damage it does to the team morale and the teams desire to self-organise. If the team feel they are being overridden they will always look to the overrider for direction.

To tackle this, avoid questioning estimates in the Daily Stand-Up and perform the Daily Stand-Up around the backlog and burndown chart. Make sure your team update the backlog and burndown chart before the Stand-Up. This will help visualise progress and understand the impact of estimates that are changing or where new stories or tasks are being identified. If progress is wildly behind schedule or an individual is not performing then monitor this and address it outside of the Daily Stand-Up. Chances are it will resolve itself as the self-organising team work together to meet their commitments. If they don’t then be cautious of interference while the team is going through the transition to a self-organising team – you will only make it take longer.

The meeting should never hang individuals / teams out to dry for not performing. When this starts to happen then the team will feel that management are using their meeting as an excuse to micro-manage.

In addition, smaller iterations provide more feedback loops for revisiting estimates and can therefore help improve them based on performance to date.

When estimating, try using Planning Poker to estimate by consensus and practice commitment based planning where the team will estimate tasks and commit to delivering against those estimates. Back this up with Velocity based planning so the team, manager and stakeholders have a longer term view of what / how much can be delivered over future iterations and releases based on past performance.

SMELL16: Absence

Absence is unavoidable so isn’t necessarily a smell that something is wrong. Team members will have days off sick or occasionally will have other commitments that are essential and will just have to impact their attendance at the Daily Stand-Up. However, these should be exceptional.

Absence causes a stench when absence is continual (see SMELL17: Continued absence) or intentional and avoidable and the absentee’s update is unavailable. This suggests that the absentee is beginning to lose sense of the value of the Stand-Up, that their own work schedule is more important than the teams (and thus impacts the team’s ability and desire to be self-organising) or that they are behind schedule or having quality problems and are uncomfortable sharing this in the public eye of the Stand-Up.

If you really just can’t make it then, if not constrained by being wrapped up in bed with man-flu like symptoms, an update should be sent to the facilitator with apologies or, preferably, should be given by a team-mate who has the background and context of the individual’s work (your other half if practising pair programming or possibly someone impacted by your work).

SMELL17: Continued absence

Continued absence paralyses the Stand-Up. Forgetting the reasons why someone is continually absent, the impact this has on those that do attend is:

  • Recognition that it’s okay not to turn up
  • Gradual loss of belief in the value of the Stand-Up
  • Severely impacts teams ability and desire to be self-organising
  • Lack of awareness of the individuals work and the impact this work has on them

Why would an individual continually fail to attend?

The reason could be linked to perceived value of the approach. Are other smells evident and the individual is voting with their feet?

The reason could be linked to protection. Are they a coding diva and think they are greater than the team? Why is this? Are they afraid of losing some power or empire they have established in the team?

The reason could simply be down to logistics. Is the Stand-Up timing and location all wrong for this person?

If the team member is protecting their role and responsibilities then go directly to SMELL18: Hero’s – you have one on the team.

Alternatively, if, when discussing the lack of attendance with them, they enlighten you as to their perceived value of the Stand-Up then you should discuss the reasons with them and understand if there are additional smells. This is often down to SMELL3: Feels like reporting to a leader and the team member see’s the Stand-Up as the ultimate in micro-management. If this is the case, then it’s down to you or your leader to address this behaviour.

If the problem is logistical then you may have fallen foul of the “Stand-Up is first thing in the morning at 9:15” problem, without giving consideration to individual’s personnel preferences and working patterns.

Remember the motto:

For the team, by the team

Let the team decide on their own time and location. Just make sure its consistent: Same place, same time. This approach will give the team a sense of ownership and goes a long way towards encouraging collaboration. Having the Stand-Up in the same place, same time every day means that interested parties will also know where and when to go (to observe only – obviously!)

SMELL18: Hero’s

So you have identified an individual who regularly misses the Stand-Ups and recognise that this individual is Mr Product-X.

If the team member is protecting their role and responsibilities then you will need to work with them to understand this and for them to understand the importance of a self-organising team and how their protective, possibly elitist behaviour, is a direct threat to the team’s ability to collaborate.

The hero is likely to be a well-respected, highly technical individual who regards you as an ache in the rear and that they are tolerating you because this is just another management fad that will pass. Then they can get back to their proper job.

To get over this you will need to win them round and this will take time. While this is happening be watchful of how they are impacting the teams ability to self-organise and collaborate. Make sure you are eradicating impediments and no other smells are observant. This is likely to be evident in other collaborative practices (planning, retrospectives, peer reviews) not just the Stand-Up so be mindful of keeping an eye (or should I say nose) on them also.

One approach to bringing the hero into the team is to ask them to experiment with Stand-Ups for a period (i.e. an Iteration) where they can observe and take part in the teams gradual improvements in collaboration, thus becoming involved and committed to it rather than cautious of it. Ask them to help resolve some of the impediments and identify and eradicate process smells so they have a sense of ownership of the Stand-Up.

If all else fails, to put it bluntly, show ’em the door. There is no place in a team for someone who doesn’t want to be in a team.

SMELL19: Your late!

The Stand-Up should wait for no-one and should not be summarised for someone who is late. Doing this suggests that it is somehow okay not to be there on time (thus de-valuing the Stand-Up and impacting the teams ability to self-organise). Summarising will also impact your desire to be done in 15 minutes if you have to repeat everything.

Lateness could also be a symptom of not having an agreeable time and location and the late individual may just be logistically challenged. As discussed in SMELL17: Continued absence, let the team decide on their own time and location and make sure its consistent.

SMELL20: No impediments

As a consequence of SMELL7: Impediments not removed, the team will eventually lose confidence in the ScrumMaster’s capacity or desire or capability in helping them get over project hurdles. Once they start to think this then they will stop raising them.

Another reason this happens is that the team suffer from either SMELL1: Lack of energy, SMELL14: Observers talking or SMELL4: Objectives of the Stand-Up are not clear with the focus on getting done in 15 minutes and not on synchronizing team members work.

As stated in SMELL7: Impediments not removed, use an impediments board to capture and track the impediments when they are raised. This will help all individuals feel a sense that impediments are worth raising because they are being captured and dealt with. As a ScrumMaster – this is your part of the agile bargain – deal with them!

SMELL21: Stand-Up starts the day

How can this be a problem? They are meant to start the day aren’t they?

Absolutely not!

The Daily Stand-Up can be in the morning as this helps the team focus on what they need to achieve for the rest of the day, but when its seen as starting the day this can have a nasty side effect.

In today’s flexible workplace, individuals vary their start times and working patterns. As such, to achieve consensus on when to have your Daily Stand-Up, you will arrive at a time that is equal to about 15 minutes after the last person arrives into work.

For example, let’s say one person arrives in at 8am, two more come in at 9am, another two come in at 9:15am and the final member arrives at 9:30. They agree to have the Daily Stand-Up at 9:45am.

All fine and dandy.

However, chances are that those who arrive at 9am, or after (i.e. the majority of the team) will see the Daily Stand-Up as starting the day rather than just being an activity that happens in the morning. When this is the case they are more likely to spend their time leading up to the Daily Stand-Up looking at emails and discussing last nights TV or football results around the coffee machine. (Not me though cos as I write this my team Villa were just beaten by their local rival Birmingham City 2-1 ;-( and don’t get me started on England’s failed World Cup bid).

If this is the case, then consider having the Daily Stand-Up at the end of the day (additional plusses being impediments and progress are fresh in your mind, there will be a desire to get done in 15 minutes (to get home) but lose the value of focusing the team for the rest of the day) or just before lunch (which partially loses the focus of the rest of the day but increases the team’s desire to get done in 15 minutes (to get food…mmmmmmmm)).

SMELL22: Not prepared

You need to prepare for the Stand-Up otherwise you will end up like Dave and your communication is ineffective. To provide feedback that is more collaborative (in a way that we changed John’s feedback in SMELL4: Objectives of the Stand-Up are not clear with the focus on getting done in 15 minutes and not on synchronizing team members work), you will need to consider not just what you did, etc….but think around the tasks and the impact they have on other team members and where you need to garner support, help and feedback to collaborate on completing your self-assigned piece of work. As Stacia Viscardi puts it in Daily Standup Withdrawal in Scrum Teams your feedback should be meaningful, insightful and pro-active.

SMELL23: Skipped Stand-Ups

The Stand-Up should happen even if the ScrumMaster isn’t present. The meeting is for the team by the team and, as already stated, it is NOT a status update for the ScrumMaster (see SMELL3: Feels like reporting to a leader).

To prevent this try nominating the next days facilitator as described in SMELL3: Feels like reporting to a leader. This will help ensure the Daily Stand-Up is truly daily, even if the ScrumMaster is unavoidably absent.

Oh, go on then, you can have weekends off.

SMELL24: The dreaded ritual

To complete this assemble of unpleasant odours, we have the catch-all. If your team begin to see the Stand-Up as a dreaded ritual then there is something definitely wrong and it is probably a symptom of SMELL3: Feels like reporting to a leader and SMELL6: Confrontational.

The team hate them and they feel the Stand-Up is ineffective.

In some cases, some team members just don’t like talking in the public environment of the Stand-Up (see SMELL5: Say one thing in Stand-Up another outside).

Whatever is making the team ache inside at the thought of a Stand-Up you will need to get to the bottom of it. Ask the team to experiment with Stand-Ups to understand why they may not be working for you – look for the smells described above and try some of the suggested solutions to deal with them.

Summary

At its best the Stand-Up is an effective and dynamic means of feedback, communication, self-organisation and co-ordination. Your Stand-Ups will suffer from some of the smells above which will impact the effectiveness of the Stand-Up. If you are nauseated by their stench then experiment with some of the suggested deodorants.

My advice is to be more careful about falling into the trap of the Stand-Up turning into a status update than any other. This really does suggest micro-management and when it goes wrong, even though you maybe thinking your Daily Stand-Up is effective because as a manager you are forcing it to be focused, it affects the team and can cause a number of de-motivational issues that can significantly impact your teams morale.

If the Daily Stand-Up suffers from SMELL3: Feels like reporting to a leader, SMELL5: Say one thing in Stand-Up another outside, SMELL6: Confrontational, SMELL9: Meeting notes kept, SMELL15: Leader overrides estimates and SMELL24: The Dreaded ritual then this really is micro-management of the very worst kind. In this situation, we are far removed from the collaborative communicative environment we are trying to foster to one that cultivates confrontation where bullying, repression and autocracy are the norm. When our Daily Stand-Up’s are like this then they become management gimmicks that veil micro-management, ego’s and hidden agenda’s and are the equivalent of electric shock therapy.

Scrum vs Kanban – which is the best – there’s only one way to find out….FIGHT!

Back in the late 80’s I went on a training course at Magnetti Marelli on something called Kanban. I worked in an IT department of an engineering company who were implementing production control software in an attempt to hit the strong demands from our customers who were insistent that we should do more with less and deliver better quality, in shorter lead times and with reduced prices.

We looked at capacity planning, improved stock control, quality management, MRP & MRP II before setting our sights on what Toyota had been doing (at the request of our customer admittedly as they aimed to become a lean enterprise).

This lead me to the aforementioned training course and a book called The Goal by Eliyahu Goldratt. I didn’t realise the impact it would have on me then but a decade or so later, having gone through the RUP revolution, embraced agile in a way that was scarily passionate I returned to my roots as I started to see Kanban, the Theory of Constraints and lean gather momentum in the software community.

So what is Kanban?

How does it differ from Scrum?

Can the two be used together?

Kanban models your workflow. It does not concern itself with team; it is bothered about an item of work, described as an item of value to your customer, and the workflow getting from the conception of the item of value to the delivery of that item of value.

Kanban believes that the constant improvement of speed in the delivery of this item of value is the one true overriding goal. This speed of delivery is called the cycle time. Perception is viewed as “the customer asks for something and you deliver it to them instantaneously”. Impossible without magic, time travel or a touch of clairvoyance but its not achieving perfection that’s important it’s the pursuit of it. The constant strive to improve cycle time.

Lean thinking, of which Kanban is one technique in many lean techniques, recognises that a by-product of improving cycle time is improving quality and reducing cost. It does this by removing wasteful and complex processes, tasks and products and provides quick and regular feedback loops to review and manage and indeed improve the workflow.

Lean identifies a number of waste’s to look for in your process: waiting, motion, defects, etc. One that Kanban directly addresses is Work in Progress (WIP). While a product is in WIP it provides no value and worse, if an order or a specification changes, the product may become redundant for a while, require rework or become out and out scrap.

Kanban handles this by limiting the amount of work that may be in WIP at any one time. If a workflow item hits its WIP limit, then it is incumbent on workers earlier in the chain to stop what they are doing and help clear the bottlekneck – thus ensuring the item of value gets through the whole chain and into the hands of the customer as quickly as possible.

Kanban is therefore a technique that limits WIP and manages queue’s with the goal of minimising cycle times and ultimately delivering value to the customer as quick as feasibly possible.

Scrum differs in that it manages a teams work through Sprints to deliver a potentially shippable product at the end of the Sprint. With Kanban you can release whenever you have anything done, it is not limited to Sprint boundaries. Therefore Scrum limits WIP also, but only at Sprint boundaries, Kanban limits WIP in individual workflow states.

To limit WIP to Sprint boundaries, Scrum teams commit to items that must fit into a single Sprint. Kanban, however, allows for any size item but the focus on reducing cycle time encourages the team to break them down into smaller sub-items.

In Scrum, the contents of a Sprint are protected. The Product Owner may change, add, delete items on the Product Backlog but those in the current sprint are fixed. In Kanban, you define your own rules for what can change (e.g. Product owner is usually given a column on the left hand side of the board to do what they like with at any time). In addition, in Kanban, you often see a swimlane for “Expedite” with a WIP limit of 1. This means that the customer can put something of critical importance on the board and everyone works to get this through as quick as possible.

This means that Scrum works well where the team can work on items without distraction (usually good for new product development). Kanban, on the other hand, is good when the team are often distracted by unexpected pressures (usually observed in support and maintenance teams).

In Scrum, items are estimated in points (e.g. Stories and Story Points), tasks are identified and estimated in hours. Scrum produces a Release Burndown showing progress to delivery of a release (in points) and a Sprint Burndown showing progress to Sprint completion (in hours). Scrum also measures velocity (i.e. points completed in a sprint) and uses this to predict completion (i.e. points left divided by velocity to work out number of sprints required to complete). Kanban views this level of estimation and prediction as wasteful. It really only cares about keeping the queues down and reducing the cycle time.

Scrum provides a number of feedback loops to address problems, improve practices and steer the effort. These are at the Daily Stand-Up and at Sprint boundaries (in the form of the Demo and the Retrospective). Kanban provides feedback loops on the completion of every item (i.e. what is the new cycle time?) and when a workflow state gets crammed full (which results in the other members of the team helping to remove the bottlekneck).

Scrum prescribes cross-functional teams. In Kanban, the board is related to workflow not necessarily a team. However, even with cross-functional teams, there still is a tendency to have specialist roles. This is discouraged in agile practices but still happens. When this occurs you risk the problem that more is delivered into test than can be tested before the Sprint ends with the consequence that velocity is hit and the Sprint fails. In Kanban however, its the law that this cannot happen. If a workflow area is becoming a bottleneck (e.g. test) then its a rule that the other team members must help to remove the bottleneck.

Scrum prescribes the use of a Product Backlog which suggests 1 team = 1 product. Scrum can scale to multiple feature teams, still with 1 overall product backlog and multiple feature backlogs. Each feature team then has its own Scrum board and burndown. In Kanban, individual products can be combined as swimlanes on 1 board and members can work on any item to keep the items flowing through the workflow.

There are a number of smaller differences and similarities in that both are pull systems, Scrum has more prescriptive activities and roles than Kanban and the Scrum board is reset every Sprint whereas the Kanban board persists ad infinitum.

So which is best?

Scrum or Kanban?

Spoken like a true consultant – It depends………..if you have a problem with WIP or queues, you are overloading your test team with work, the work is variable and unpredictable and delivery is not based around regular heartbeats then Kanban is a technique that you should probably consider but not necessarily at the expense of Scrum.

If you are developing a release over several months before the release is required then using Sprints and measuring velocity, coupled with Demo’s and Retrospectives are an excellent technique for producing a quality product using the Scrum framework.

The thing to note is that Scrum and Kanban offer us techniques for managing different problems. Arbitrarily adopting Scrum or Kanban without consideration to the problem that needs addressing is foolish. Its like using a hammer to bang screws into a piece of wood or whacking a nail with a screw driver.

Consider your needs and your likely to find a necessary place for both…..