1st Conference 2015 – Evoking Excellence Through Agile Coaching

Posted on July 11, 2016     Leave a Comment

The presentation I delivered last year at  1st Conference 2015 titled “Evoking Excellence Through Agile Coaching” is available on Slideshare.

 

LAST Conference 2016 – Pirate Metrics AARRR !

Posted on July 6, 2016     Leave a Comment

My Lightning Talk at the opening session of LAST Conference 2016 titled “Pirate Metrics” is available on Slideshare.

The talk is a quick 5 minute introduction to the Pirate Metrics based on Dave McClure’s startup metrics.  Fans of Lucas Art’s game ‘Secret of Monkey Island’ would enjoy the inclusion in my talk. AARRR!!!

Here’s some of the tweets from the session:

Scrum Australia 2016 – Lean Discovery

Posted on July 6, 2016     Leave a Comment

My presentation at Scrum Australia 2016 titled “Lean Discovery” is available on Slideshare.

Chris-Chan-presentation

“The hardest part of building any software system is determining precisely what to build.” – Fredrick Brooks.

Discovering exactly what customers, stakeholders, and sponsors want to create is often the most difficult part of product development. Getting everyone aligned can be fraught with misunderstanding and misinterpretation. Scrum starts with a product backlog, but how do you know that the development of the product supports the growth of your company?

Getting off on the right foot when starting an agile initiative can set you up for success. This presentation will outline a basic flow of light touch Discovery workshops as a way to start your agile product development engine.

And here are some of the tweets from the session:

Do you have a real deadline?

Posted on May 27, 2016     1 Comment

Do not cross the lineThe first written record on the use of the word “deadline” was in 1864.  It was a the term to describe the line over which prisoners were forbidden to go –
Along the interior of the stockade, 19 feet from the stockade wall, was a line of small wooden posts with a wood rail on top. This was the “deadline”. Any prisoner who crossed the deadline could be shot by guards stationed in the sentry boxes. [1]
The words are quite literal – a line where it will make you dead.
Not all deadlines are bad.  But we must be careful on how often we impose them and for what purpose.  Many deadlines are largely unwarranted and generally harmful.
Deadlines can provide a sense of urgency and focus.  Goals without deadlines are dreams, so deadlines can reduce the amount of procrastination and avoid Parkinson’s Law.  And when deadlines are self-imposed, it can challenge us to get stuff done – there is a sense of achievement on getting a job done in record time.  Deadlines used with the right mindset can help teams really focus on what is important and what isn’t.  With the right mindset, it facilitates bias towards action and help us prioritise so we are doing the important things for the customer and help identify wasteful (corporate) activities so we can improve and eliminate.
When used judiciously, deadlines can get an important piece of work over the line as it focus teams on production.  However, if this is forcing the pace of work that causes burnout, bad things start to happen.  Agile processes promote sustainable development
“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” – Agile Manifesto.
Deadlines used as an extrinsic motivator and holding a threat for unclear purposes is dangerous to our modern way of working as it imposes fear.
In a complex environment we do not know and cannot predict what will happen when we do action ‘ABC’ and there are many possible actions that we could do.  So when promises of dates are made early on, it causes a ripple effect as people will start setting deadlines off your deadline and it becomes self-reinforcing.  As a result of this you remove a lot of options for adaptation and unexpected events.
There are deadlines that have a “real” business impact or have an actual business consequence for failing to meet the deadline.  For instance, meeting an regulatory reporting requirement (eg APRA in the Australian Financial Industry, or Sarbanes-Oxley)  or studying for an exam.  There is little value in finishing something for an event (eg trade show) or holiday special (Mother’s Day) after the event.  The “Y2K Bug” is also another example of a real deadline.  Anything where the value of completing the work drops significantly or disappears altogether is a real deadline.  If the work is still mostly valuable if you get it done after the deadline, you probably have an arbitrary or “perceived” deadline pretending to be a “real” deadline.
A genuine deadline tells you “If we don’t get done by the deadline, there’s not much reason to get it done at all and we should stop”.  These type of deadlines, whilst are valid, they are actually not that common.
“Perceived” deadlines are actually the most common. There is a very significant difference between real deadlines and perceived deadlines.  Perceived deadlines tend to arise from questions like “How long do you think this will take?” or “Do you think we could have this by [date]?”.  They exist to keep work (eg a project) from going on indefinitely and create an arbitrary line in the sand where people can expect delivery.
Often these deadlines are a result of setting expectations, often very early on based on long-term or coarse grained estimates, and estimates of that sort are never accurate.  We are bad estimating – experience and scientifically it has been repeatedly shown that getting accurate estimates is extremely difficult, if not impossible.
The real problem with deadlines, is that any deadline longer than a day or two you are asking people to fail.  What you are really measuring with deadlines is the ability to estimate. If you are trying to convince people to get something by a deadline, the only way they could get something done by a deadline is by getting better and better at estimating.  This is something you cannot do, even with experience.  [2]
In a complex world where you can’t predict the future of doing ‘ABC’ you are constantly punishing people for something they can’t get better at.
Deadlines based on annual budgeting and financial cycles is also a type of perceived deadline.  Teams working towards nominal end date (or start date) that aligns with the financial year is also nonsensical as customers do not operate (and don’t really care) when you make your investments and how you fund and capitalise work.
The best way to determine if you have a perceived deadline is to ask the question, “What will happen if we miss this deadline?”  If the answer is mainly, “people will be disappointed”, “someone promised that date to the market” or “we already announced that date” then you probably have an arbitrary deadline with no actual business impact on it.  Many of these deadlines are actually wishful thinking or commitments made on behalf of others doing the work based on theoretical plans and no evidence of actual production work.  There is little surprise why we have missed expectations and the ensuing conflict and confusion on why things never get done “on time”, why the quality of the product isn’t better and why we don’t have time to improve.
These perceived deadlines tend to cause undue stress on teams for no particularly good reason.  This creates short-term thinking and approaches aimed at getting across a finish line with little sense of what comes afterwards.  Heroics are often required to get things done and the product is sub-optimised as quality is sacrificed as hidden technical debt is accumulated which are rarely quantified or explained.
Jim Benson, author of Personal Kanban, has been credited with the diagram attached – deadlines as influencers of ‘crap’.  Simply put – as your deadline approaches your options are reduced and you choose options to fit the deadline rather than satisfy your customer.
DeadlinesAndCrap
In the novel, The Phoenix Project this common situation was aptly portrayed –
I’ve seen this movie before.  The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers.  Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment.  And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.
A much better way to get a predictable timeline is to make projections based off the team’s actual metrics of progress and constantly adapt based on new information.  That’s why agile promote working solution/product (ie shippable state) as a measure of progress.  We need to act our way to the future, rather than plan or guess our way to the future.  We should only commit at the last responsible moment.  Never commit early unless you know why (ie have you got a real deadline such as an “AFL Grand Final moment”).
Not all deadlines are bad but next time before setting a deadline please consider why you are imposing the deadline and what is the real need for that deadline.  Be on the look out for a perceived deadline acting as a real deadline as these will undermine teams with a constant push towards an illusory goal resulting in sub-optimal results, poor customer and business outcomes.  And along the way, hopefully we will reduce the number of times people crossing the deadline being shot.
—
[1] Reading 1: Andersonville Prison, https://www.nps.gov/nr/twhp/wwwlps/lessons/11andersonville/11facts1.htm
[2] Jabe Bloom, Beyond Deadlines, https://vimeo.com/52255565

7 Stages of Waterfall

Posted on March 12, 2016     Leave a Comment

7 Stages of waterfall

The seven stages of waterfall:

  1. Perfect plan
  2. Wild enthusiasm
  3. Total confusion
  4. Death march
  5.  The search for the guilty
  6. The persecution of the innocent
  7. The promotion of the incompetent

 

 

Adapted from Roger Rothstein’s ‘6 Stages of (film/movie) Production’.

Leaders need to focus on providing Clarity and Competence, not control

Posted on March 2, 2016     Leave a Comment

Self-organising teams is the antithesis to hierarchical structures that exist in many organisations.  Traditional leadership required a strong leader to take control, attract followers and make it happen.  Modern leadership is about leaders giving control and creating leaders.

Self-organisation requires autonomy and control to be given to teams.   This includes trusting individuals to figure out how to solve problems, make decisions and how to best get work done.  With knowledge work the best decisions are those in teams who are closest to the information and customers.  However, structure, policies, processes and hierarchy often take the decision making away from these teams.

clarity and competenceIn his book, Turn The Ship Around!, nuclear submarine Commander David Marquet describes how control was given to the ship’s crew.  It required each member of the team to improve his or her technical competence and have a clear understanding and clarity of the organisation’s driving purpose:

Competence:   Provide teams with the tools and technical competence to get the job done; create the environment for thinking.

Clarity:  Define and communicate the organisational intent so everyone is clear on the vision, goals & objectives.  Everyone understands what is the right thing to do.
As a leader you trust the teams are competent and have clarity of vision.  Individuals have the freedom to adjust actions and make decisions in line with the vision and intent.

So what does this mean for a leader in today’s ever fast changing world?

If leaders do not believe individuals are competent and have clarity of vision, the leaders should fix THAT rather than remove power by putting in more controls or structure.
As a leader your job is to ensure people have clarity of vision and the competency needed to succeed.

If leaders don’t believe individuals can understand the vision or pick up the skills, why did the leader bring them in the first place?  And if there is a competency gap, why did the leaders not mentor or provide training?  We all have the extraordinary meta-skill to learn and acquire new skills.   If people do not have the competence, the role of leaders is to mentor, give people training and provide the environment for learning.

Rethinking Agile Procurement and Contracts

Posted on February 12, 2016     1 Comment

One of Edward Deming’s 14 Prinicples from his book Out of the Crisis (1982),  contains a very astute principle that procurement should grasp:

End the practice of awarding business on price tag alone. Instead, minimize total cost – move towards a single supplier for any item, on trust.

I was recently interviewed for an article on agile procurement and contracts by Cath Thompson for the Procurement Leaders Global Intelligence Network.

The current thinking and policies for procurement in organisations does not match the agile values and principles.  There are infinite tales of troubled projects as a result of fixed price (implicit fixed scope) using agile approaches.

Comparing vendors/partners on fixed price is fraught with danger when product development is inherently unpredictable and uncertainty is the natural order.  This is more complicated when vendors attempt to put a price on the work when the team that will work on the product development hasn’t even been assembled (self-organising teams plan and estimate their own work).

Organisations and teams are complex adaptive systems (human systems) that interact and connect with each other in unpredictable and unplanned ways.  Complex problems require experimentation and learning.  As a result each team will approach creative/knowledge work differently and will highly likely produce different results even when teams have the same starting conditions.  Pitting vendors in a competitive position against each other in order to get the best price under these inherently unpredictable and uncertain circumstances wastes time and energy.

Agile approaches

are counter-intuitive to [procurement] expertise built on containing risk and ensuring value for money through rigour, clarity and specificity
– Cath Thompson

However, there is a way forward for procurement – it will require a change in mindset to one that understands the need to develop a long term relationship with the vendor/partner beyond just the immediate contract transaction.  Procurement needs to realise agile ways of working are easier to govern as a result of increased transparency and visibility, ability to adapt, increased collaboration based on trust, and focus on working solution.

 

Here’s the link to the entire text of the article – Reinventing the office (Cath Thompson, Procurement Leaders, September/October 2015)

Leadership Debt

Posted on October 29, 2015     2 Comments

For the past 10 years I have been working with various organisations to humanise the workplace, help improve the leadership capability and dampen the toxic culture that may currently exit.  A recent article  (28 Oct 2015) in the news has provided no relief.

The article indicated that the thinking and culture of tomorrow’s leaders being taught at school’s today still resembles ‘traditional’ management of command and control borne out of the industrial era and Taylorism.  Traditional command and control is about managers telling subordinated what to do, when to do it, where to do it and how to do it.  There is very little thinking required of the subordinates and very little autonomy in this hierarchical culture.

The article has quoted a student stating to some other students:

Just remember your parents work for mine, so don’t go complaining to them.

Remember to say ‘hi’ to me when I’m your boss one day.

Girls who replied to the thread were told to shut up to “let the men handle business”:

Could all woman (sic) please refrain from expressing there (sic) opinions thank you

This type of thinking is a big contrast to modern management and leadership styles of ‘Servant Leadership’ where the leader is servant to those they work with.

The student’s comment resembles Level 1 of John Maxwell’s 5 Levels of Leadership.  Level 1 is more about “hierarchy” rather than “leadership”.

John Maxwell's 5 Levels of Leadership

John Maxwell’s 5 Levels of Leadership

There is a real leadership debt in some organisations.  We have too many leaders who work “in” the organisation rather than working “on” the organisation.  Organisations and machines don’t build great products and services, people do. It is the collaboration and the human spirit that are at the heart and mind of great work. We need to stop viewing people as ‘resources’; treating them as robots or commodities who are easily interchangeable. We need to enable performance rather than manage performance. 

Humanising the workplace is about making a work environment that puts a greater emphasis on knowledge, passion, inspiring people to collaborate towards common goals, and fostering teamwork where creativity can flourish.  Leaders have a large role to play in humanising the workplace.

Effective leaders are increasingly collaboraters rather than being command and control.  Effective leaders realise great outcomes from setting appropriate context, rather than trying to control people.  Modern leaders provide vision and purpose that allows individuals and teams to be self-organising and self-disciplined.  It’s not about “managing” people but more about “leading” people and being more facilitating.

Further to my last post, Malcolm Turnbull – The Agile Australian Government, Turnbull has said:

We need a different style of leadership.  A style of leadership that respects the people’s intelligence, that explains these complex issues and then sets out the course of action we believe we should take and makes a case for it.

We need to stop accumulating more leadership debt and start erasing this debt in schools so we can survive the challenges of today and tomorrow and build better world for the future.

LAST Conference 2015 – Agile Start Me Up – Using the Minimum Viable Discovery (MVD)

Posted on September 18, 2015     Leave a Comment

My presentation at last year’s LAST Conference 2015 titled “Agile Start Me Up – Using the Minimum Viable Discovery (MVD)” is available on Slideshare.

Malcolm Turnbull – The Agile Australian Government

Posted on September 16, 2015     2 Comments

Malcolm Turnbull

Malcolm Turnbull

The Australian Government took a pivot 2 days ago with a new Prime Minister after a leadership spill.  In his acceptance speech, Malcolm Turnbull talked about a more ‘agile Australia’ and urged Australians to ’embrace disruption’.  He said his government would be “focused on ensuring that in the years ahead as the world becomes more and more competitive and greater opportunities arise, we are able to take advantage of that.”

The Australia of the future has to be a nation that is agile, that is innovative, that is creative. We can’t be defensive, we can’t future-proof ourselves.  We have to recognise that the disruption that we see driven by technology, the volatility in change is our friend if we are agile and smart enough to take advantage of it. – Malcolm Turnbull

I have been following from afar the evolution of UK Government’s Digital Service Design Principles.  In summary the 10 principles are:

  1. Start with needs – Talk with customers, have empathy with users
  2. Do less – Government should only do what only government can do, for all else link to others
  3. Design with data – Let data drive decision-making, not hunches or guesswork, take a a Lean Startup approach.
  4. Do the hard work to make it simple – Don’t take “It’s always been that way” for an answer. The right thing to do is make things simple although that is hard to do
  5. Iterate. Then iterate again. – MVPs and agile, do I need to say more?
  6. This is for everyone – Build for needs, not audiences. Everything built should be as inclusive, legible and readable as possible
  7. Understand context – Don’t design for a screen, design for people.
  8. Build digital services, not websites – Uncover user needs, and build the service that meets those needs.
  9. Be consistent, not uniform – Use the same language and the same design patterns wherever possible. Make sure the approach is consistent (but this is not standardisation).
  10. Make things open: it makes things better – Use open source, but return the favor by sharing with others too.

In hindsight these principles were quite advanced for a Government given these came about 3 years ago.  More recently the UK Government has released the Digital by Default Service Standard.  In particular, one of the standards is very explicit:

Build the service using the agile, iterative and user-centred methods set out in the manual.

Both these principles and standards are wonderful and you will notice there a lot of modern delivery and management thinking behind them.

If you go from the UK across the North Atlantic Ocean you will find that the US digital services projects do not work well, are delivered late, or are over budget. To increase the success rate of these projects, the U.S. Government created a new approach with the U.S. Digital Services Playbook:

  1. Understand what people need
  2. Address the whole experience, from start to finish
  3. Make it simple and intuitive
  4. Build the service using agile and iterative practices
  5. Structure budgets and contracts to support delivery
  6. Assign one leader and hold that person accountable
  7. Bring in experienced teams
  8. Choose a modern technology stack
  9. Deploy in a flexible hosting environment
  10. Automate testing and deployments
  11. Manage security and privacy through reusable processes
  12. Use data to drive decisions
  13. Default to open

There are striking similarities between the UK Government Design Principles and Standards and the US Digital Services Playbook with both taking a citizen-centric view of customer needs as their first point.

When I last worked on some initiatives for the Australian Government there was no such principles and agile approaches were not widely adopted.  A search on Australian Government Information Management Office (AGIMO) website revealed only one reference related to agile – Behold the Power of Agile.

Early this year (2015) the Australian Government established the Digital Transformation Office (or DTO) to lead the government in transforming their services to improve customer experience.  The DTO has come up with their own Digital Service Standard.  A close look at these standards will reveal that it has been adapted from the UK Government’s Digital by Default Service Standard (almost exact word for word), and it includes the similar statement:

Build the service using agile, iterative, collaborative and user-centred methods

I would recommend you spend 30mins of your time to review the various governments Digital Standards and Principles.

Being a customer and citizen of the Australian Government I am eager to see the government put an agile value and principles approach on the agenda so that products and services are delivered faster and meets my needs.  The future will judge Turnbull’s comments of a more ‘agile Australia’ – is there going to be real change? or are these just buzzwords?

Follow Blog via Email

Enter your email address to follow this blog and receive notifications of new posts by email.

Archives
%d bloggers like this: