Scrum Australia 2016 – Lean Discovery

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

“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?

The 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 sponsors, developers, and users should be able to maintain a constant pace indefinitely” – Agile Manifesto.

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’.

Rethinking Agile Procurement and Contracts

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)

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

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

Passed the PMI-ACP Exam

Yesterday I passed the PMI – Agile Certified Practitioner (PMI-ACP) exam with Proficient results. Woo Hoo!!

I took a very very light weight approach to my preparation.  I am currently very time poor which has led me to do minimal and just enough study.

I did not read any of the prescribed reference books for the exam (I have no time) – there’s 11 of them (ouch)!!!  But I have read parts of some of the books at some stage in the past.  The only book I read once 4 months ago was “The PMI-ACP Exam: How To Pass On Your First Try” by Andy Crowe.  In hind sight after completing the exam, I didn’t find this book very useful in that I didn’t learn anything that would prepare me for the exam.

A few days prior to the exam, I used http://www.agileexams.com as a guide to what to study. Whenever I got an answer wrong I would do a short study spike by researching the topic. Most of the time the questions I got wrong on the practice exam were ‘off-the-road’ agile concepts or ensuring I got the ‘text-book’ agile theory right.  As most would know, there are various approaches and adaptations in agile that would work, but for the exam you are tested for the theoretical correct approach.  I would recommend using agileexams (I found it useful) as a study/prep tool as a way to hone in on study gaps.

I am an agile practitioner and have been coaching agile for a number of years now so the above light weight, minimal marketable reading approach worked for me.  I suspect if you have agile experience, then passing the exam would not be too difficult without having to read all the books too.

For the actual exam I took 3 iterations, 2 hours in total (you have 3 hours to complete the exam):

• Iteration 1 – Went through all the questions and selected the best answer. Marked about 20 questions to review (60mins).
• Iteration 2 – Reviewed all the marked questions (15mins).
• Iteration 3 – Went through all the questions again to double check my answers (45 mins).

In most cases, 2 answers can be easily ruled out (i.e. obviously incorrect).  There were a few instances where in practice several answers would be plausible, but there was only one theoretical and ‘correct’ answer for the exam.

Good luck if you are planning to take the exam!

Now that I am PMI-ACP certified, what now?

Leadership styles

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

Useless sprint goals

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

The Scrum Guide [Oct 2011] states:

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

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

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

Here’s an iteration goal for a team:

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

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

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

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

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

Seeking the exact answers

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

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

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

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

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

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

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

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

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

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

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

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

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

I want to run an agile project

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