In one or two progressive companies I worked for, there was an understanding of the saying “Fail-fast, learn-fast”. In these companies, it was safe to fail. I even remember discussing a decision with a senior manager and whether the decision would work out. Eventually, we agreed to “Fail-fast, learn-fast” and dived in, preparing to reverse the decision if it didn’t go the way it was planned.

Fail-fast, learn-fast

In my training, I try to express this idea, but it’s a difficult concept for a lot of people as they tend to focus on the “fail” part. Failing can be expensive.

When I was back on the farm with my brother, we hired a digger to drain a swamp. That afternoon we saw the events as they unfolded.

The digger was opening a new part of the drain, and the heavy machine began to sink into the bog. Panicking, the inexperienced driver turned the tracks hoping to head for firmer ground, instead of just backing out the way he came. That was a mistake. The act of turning the tracks cut the top of the bog and the whole digger began to slide under the swamp. Firm ground to pull himself out with his scoop was too far away.

That was a mistake

At first light, on the third day, all that could be seen of the digger was about a meter of the top of the boom (the digger arm) showing above the swamp. About then several trucks turned up with two more massive diggers and the largest bulldozer in the country at the time – for the size of its winch. The brothers who owned the company joined us at our vantage point to oversee the operation.

After a few hours of operation, they had uncovered the digger, and the driver was informed that he had “volunteered” to strip down to his undies to climb into the cab where they would try to restart it.

We watched as the driver reluctantly waded waist high to the digger door, where mud and eels poured out all over him from the cab where he had to climb in.

mud and eels poured out all over him

In the end, they did get it out and we were talking to the brothers about the original mistake causing the situation. We asked what was going to happen to the driver.

The brothers then told us that the driver would need to supply a couple of crates of beer for the team, and the jokes would continue for some time, but he wouldn’t be fired, even after the huge cost to the company in both machine costs and lost revenue.

the whole team working on this now learned from that same mistake.

If they fired him and hired someone else, the new person may end up doing the same thing but keep this person on, and there will be no way that he would ever make that mistake again. That was guaranteed. More, the whole team working on this now learned from that same mistake.

It’s not about failing, or even about Failing fast. It’s about the learning. If we are not prepared to fail, we would never learn anything new, never stretch ourselves, and never become competent at new skills and situations.

I’ve even heard of one company who has a “fail-wall” where they display all of the things they learned, for others to also learn.

Lao Leadership is a term that I created a few years ago.

“Lao” translates into “Senior” as a title in Chinese Mandarin. For example, “Mr Lee”, when given the respect of an elder, would be addressed as “Lao Lee”. Lao, or in this case Elder, can relate to the father figure, or elder brother. Lǎo bǎn (written as shown in the picture) is the name given to the Boss in China. In this instance, the words Lǎo bǎn is a relatively recent Cantonese addition to the language but its the concept of Elder, or Senior, or Lao Leadership style that I wish to discuss here.

I have always had a great interest in Chinese history. I am lucky enough to have a lovely Chinese wife, and we had the pleasure of spending a number of weeks in China where I fell in love with both the country and its people.

One area that I found interesting is the leadership style in many large Government organisations in China and how nothing more than a simple difference in thought leads to a very different style of leadership that is worthy of consideration. I’m referring to Lao as a leadership style in China. What I am referring to comes from centuries of the teachings of Confucius and family values.

comes from centuries of the teachings of Confucius and family values.

Meeting my wife’s brothers in Qinhuangdao and then again in Beijing, was a very enjoyable few days and gave me a family insight to this thought of the Lao. Younger brother and I hit it off immediately and his easy-going casual style had laughter flowing as smoothly and abundantly as the beer even though we don’t speak the same language. Elder brother though showed great responsibility in

organising transport, accommodation and taking care of all the details of our visit. I felt a bond with both, but a respect for the elder brother for the responsibility, dignity, and presence that he showed; a hallmark of many years of being Lao to his family and his shouldering of that responsibility. In the case of my wife’s brothers, both were younger than me but elder brother was definitely my “Elder” and I gave respect to that.

There have been numerous articles explaining the respect offered to your elders in Asian cultures. What most articles fail to get across is not so much the respect that is shown to elders, but the immense mantle of responsibility that the elder takes on for those who are under their care.

is not so much the respect that is shown to elders, but the immense mantle of responsibility that the elder takes on

In other words, it’s not so much telling the young to “show respect to your elders”, but that the young respect the responsibility and care that they are being shown.

The responsibility of Lao or Elder is not taken lightly and means a great deal more than simply being in command. As an elder, or Lao, you would be responsible for the actions and the success or otherwise of those you care for.

you would be responsible for the the success of those you care for

I had a very interesting discussion with an experienced Scrum person the other day which caused me to investigate why I held a different view from them. This person challenged me on my dislike of the Scrum practice of “Terminating the Sprint” if the product owner comes to the team with urgent work. We held different views: I expressed my view that terminating the sprint was never necessary, and he expressed that it’s the underlying principle of development teams in Scrum. There is a good argument for both.

Note that when I use the term “Scrum master”, this relates to whichever term is used in your teams (e.g. Iteration Manager, DevOps Manager, Team Coach) and not directly to Scrum.

The Scrum Alliance talks about Abnormal Termination of a Sprint and gives these guidelines. Reasons for an Abnormal Sprint Termination may include, but are not limited to:

• The company changes direction

• Market forces render the work obsolete

• A major technology change occurs

• A better technical solution is found that makes the current Sprint’s activity throwaway work

• Fundamental and urgent external changes that invalidate the Sprint Goal or the bulk of the functionality

• Urgent bug fix or feature development request that cannot wait until the normal completion of the Sprint

Sounds reasonable, doesn’t it? After all, if the team is working on something that no longer has any relevance, why continue?

This person also put forward another very valid argument: He said that this allows teams to deliver to their commitments without interruption and surely anything, no matter how urgent, can’t wait until the end of the Sprint, and if it just can’t, then we abandon Sprint as the last resort.

I thought differently but had to look into the reasons why as I enjoy and promote Scrum as a means towards Agile, and this person’s view is valid.

After thought, I realised that this comes down to the differences between Scrum and Agile. Remember Scrum is not Agile, it’s a framework. That’s a fundamental difference that needs explanation.

• Agile is a mind-set that is governed by the four values described in the Manifesto and following the 12 Principles of that Manifesto.

• Scrum is a framework consisting of a set of procedures, rules, and ideals. Scrum was defined many years before the Agile Manifesto was created.

I like Scrum as there are few rules, which allows us to follow the Manifesto and 12 Principles – however, the Scrum Rule around Abandoning a Sprint seems to go against the second Agile Principle:

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage

Even more than that, the third value of the main manifesto itself states that we value…

Responding to Change over Following a Plan

So what then would I suggest in its place?

Let’s say that business finds that in order to implement something absolutely necessary, and has so much value, that it must be implemented as soon as possible. Following Scrum, the Scrum Master and Product Owner calls for the Sprint to be terminated and a new Sprint Planning session is created.

However, I propose that we follow the Agile Principles here. If Business can convince the Product Owner that this new need is of greater value than the work currently underway – remember, he/she is the owner of the Priority – then the Product Owner will approach the Scrum Master.

While the Scrum Master is in charge of the Sprint Backlog, and while they will always lay great value in the direction of the Product Owner when it comes to priority, they must be convinced that this is worthy of changing their Sprint Backlog. Once the Product Owner and the Scrum Master agree that this piece of work is of higher value than the current work, then they will both go to the team.

At this point, the team can size the new work. If this new work can and should be done within the current Sprint, then the team has a decision to make:

If the team is ahead, and this new work is small enough that it can be included in the Sprint without change, then they will accept the new work

Otherwise, the team will ask the Product Owner which outstanding piece(s) of work of equal estimate, should be dropped off this Sprint in order to deliver the new work.

In this way, not only can the team follow the Agile Manifesto for welcoming change, but the team themselves get a kick out of showing how well they can respond to this change and deliver great value to the organisation as per the Agile Principle of welcoming change.

It’s a win-win situation.

Terminating the Sprint has several downers that must be considered:

• A Product Owner will only present to the team what is currently uncompleted in the Sprint plus the new high-value story. Your new Sprint will not gain anything in this case

• To start a brand new 2-week Sprint from a new point, the general cadence is broken. Previously the team, other teams,  plus the business has set up their habits around the Sprints and the Showcases and now many planned meetings may have to be reorganised around this new change

• While some teams simply start a smaller Sprint consisting of the number of days remaining in the Sprint, this seems contrary to any reasonably perceived gain for abandoning a Sprint.

However, there are also several Pro’s relating to terminating a Sprint

• Stops a Product Owner being lazy or not properly engaged and constantly “remembering” this new urgent requirement that has been in the backlog all the time. This may be due to a Product Owner having several other roles or working for several teams and simply don’t have enough hours in the day to correctly prioritise.

• A Product Owner and team may come under unreasonable pressure to say YES to every new idea if the change is that easy.

• There is a certain disruption to a team and if done often, can lead to lower productivity. Terminating the Sprint, in this case, is visible and questions are then asked.

The Scrum Master must run a fine line between being responsive to the Product Owner and protecting the team from disruption.

Contact Us

A lot has been written on Sprint estimates, pointing, or planning poker, but often little will be discussed on estimating larger pieces of work. Often development teams get asked to perform estimates on larger pieces of work that is nowhere near an Epic, let alone a Story. Management still needs these estimates to assign teams, gain funding, quote externally, and plan releases with customers.

No detail, no planning, just “how long will this take”?

Some of these estimates we are asked to make, is almost like asking “How long is a piece of string?”. How should we respond to estimate requests like that? No detail, no planning, just “how long will this take”?

As it turns out, there are various methods we can use to give management that estimate they need and tell them just how long that piece of string is. We do that through being pragmatic. At that stage, we simply don’t know enough, but we can still give an estimate. For example, most pieces of string are between 2 to 3 feet long, and your gut feeling in this instance is that this is a little longer – therefore your estimate may be that this piece of string is likely to be between 3 and 4 feet long. That’s it!

To translate this to your development estimates. A piece of work can be estimated to take “about a week, but possibly a little longer”, then estimate between 1 and 1.5 or perhaps 1 to 2 weeks if that feels better for you.

If you can, split the requirement up into manageable pieces first. That will make your estimates a little more understandable and closer to true estimates. Also, estimates that are split into pieces of work are less likely to be re-estimated by management.

If it takes a single team member a quarter of a Sprint or more – your estimate will be wrong.

In software, there is a general understanding that if something takes more than about 20 hours or a quarter of a Sprint (your mileage may differ), then the estimate will be wrong. However, here we are not giving detailed estimates; we are giving management and others “some idea” for them to plan. We know it will be wrong, after all, we don’t know the detail as yet. However, we can give an indication based on experience, your technical knowledge, and gut feeling.

Realistically estimate but don’t over-estimate to save your back, or worse, under-estimate to show how good you are. Simply make it known how certain or uncertain your estimate is and the easiest way to do that is to give upper and lower estimates.

If you really don’t know what you are trying to estimate, relate that “you don’t understand” and get more information.

it’s an estimate, not a quote

One last piece of advice – don’t spend too much time on estimates, it’s an estimate, not a quote.

Contact Us

Retreat to our large and modern semi-rural facilities just north of Upper Hutt. Advantages include being able to spread training across the weekend or over a day a week.

• Takes up to 8-10 attendees comfortably
• air-conditioned plus a gas fire and heat pump in the winter months
• plenty of space with all the training essentials on site including whiteboards
• two comfortable break-out rooms
• a private outside patio area with its own outdoor suite plus auto-levered roofing allowing full sun or shade and weather protection at the press of a button
• coffee machines so you don’t miss your flat whites and lattes
• simple morning and afternoon teas and cold drinks supplied free
• free street parking for any number of cars
• Large lawn

Attendees must bring their own lunches but there is a full kitchen including microwave and a sandwich press available. Catering can be supplied by arrangement.

This has the advantage of a relaxed, semi-rural environment, free parking, and undisturbed learning and interaction.

While this option does not offer lodgings, we can arrange for suitable places close by, including the famous WallaceVille House venue just a few minutes from our retreat.

There’s an old and true saying

“When you’re up to your ass in alligators, it’s hard to remember that the main purpose is to drain the swamp”

Agile Leadership is not about directing the alligator fight – it’s about the vision. Let the team know the vision of draining the swamp and ask them to come up with a plan to do that and then ask how you can help them achieve the objective.

Understand the alligator problem, but ensure the vision of draining the swamp is the direction.

Agile Principle number 5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done“

10 Reasons to Love Story Pointing.

Pointing (or planning poker) is a way of estimating that focuses on the size and complexity of the user story (task) assigning points rather than hours. Here are ten reasons for pointing:

1. It forces the team to understand the story, you can’t size something you don’t understand

2. You are less likely to overestimate

3. If you say something will take 2 hours, then someone will be back in 2 hours time wanting to see it finished. You will get blamed if it’s not done

4. It’s less likely to be adjusted by “someone who knows better”

5. no-one in the team can ignore the story – everyone gets to point

6. Healthy, unexpected discussions come out of pointing

7. As you don’t know what others will point, your estimate will be real

8. You “THINK” about the task which gives rise to more slicing or discussion

9. When you come to do the task, you have already partly planned how to build it

10. knowledge is spread – you learn about other areas of the project you don’t normally go into

There are more I’m sure. I also enjoy the discussion around no-estimates, but pointing is much more than estimates.

A hard and fast rule is only a rule when it suits.

help align the teams towards Agile, not to hold the teams back

While I am very supportive of most frameworks, these should be there to help align the teams towards Agile, not to hold the teams back. Abandon the rule if it is not helping the team towards becoming fully Agile.
Remember, a framework is not Agile in itself and the team should be working towards a fully agile team.
Spotify noticed this with their teams a few years ago and started making small changes which lead to a whole new growing and forever changing “framework” of their own that favours the agile mindset over any rules.

Most Agile frameworks tell us that it’s the Scrum Master / Iteration Manager / Team Coach who removes blockages, but who OWNS that blockage?

My message to teams is that, while you have your Scrum Master, their role is to assist to unblock, but the team still owns that blockage – in other words, just because you handed something off, doesn’t mean that you no longer need to concern yourself with it.

it’s your problem, not theirs

Anything that stops you getting things done (blockages) is your problem. You can ask for help, and the Scrum Master will likely take that on, but it’s still your problem. Don’t blame the Scrum Master if the problem still remains, it’s your problem, not theirs.

I have often been asked to explain the difference between a Framework (Scrum, Kanban, SAFe, XP, LeSS, DA, etc.) and Agile. There are a lot of people out there that are convinced that the framework itself is “Agile” when in fact, Agile is the mindset, defined by the 4 Values of the Manifesto and followed by the 12 Principles. You can have a framework without Agile just as you can have Agile without any of the Frameworks.

Agile is the water, the Framework is the container

I describe this as – Agile is the water, the Framework is the container. While people buy water in bottles and are convinced that the bottle is “water”, it is not. The Framework will describe the bottle or container in detail. These “bottles” are ideal to contain water but are not themselves the water. Without water (Agile), they are empty containers.

There are those in the industry who know every detail of the bottle, the shape, the construction, the cap, but really have no idea about the water, thinking that they do because, well, “bottle”. To put that another way, there are highly trained, qualified, and experienced people who understand completely their framework (Scrum, SAFe, etc.), but do not understand Agile at all. This can be good, so long as you use such people to help in the early stages of becoming Agile only, ensuring that the rigidity of the bottle does not become permanent. Allow Agile to flow and replace or reshape the container as required by the environment.

By all means, select an appropriate container but don’t forget, it’s the water that is the value.

But take care, it’s worth noting the following:

• Bottles (frameworks) don’t change shape, they are rigid in their construction and can lock in the water – without Agile being able to flow and find it’s own shape, you are stuck with a rigid, highly constrained structure that disallows Agile.

• Often people get attached to the rigid and defined structure of the bottle and will enforce that structure and value the rigidity over the water – some will place the value of the framework (e.g. Scrum) over becoming Agile.

• Bottles can be, or can become, empty – installing a framework will not make you Agile.

• Some bottle experts insist they are water experts – A Scrum or SAFe coach is not an Agile coach, these are two different things.

• Water needs a container only to the point where it allows the water to flow – Frameworks like Scrum, SAFe, LeSS etc are your starting point. It allows teams to know “What to do” while they learn why they are doing it.

• Water can exist without a container and, like a river, will find it’s own path – Agile itself only needs the framework while the team comes to understand Agile (use your Agile coach), and can decide to progress through regular refinement in such things as the Retrospective. This allows teams to work in the most productive and inspired way for both the team and the environment.

• Water can end up in still ponds and become contaminated – Ensure that you have regular (not necessarily permanent) contact with an experienced Agile Coach (experienced in more than one scenario) or the team will drift back into … well, not a nice or productive place.