Skip to main content
uk

  • Increase Speed to Market
    Deliver quality quicker by optimising your delivery pipeline, removing bottlenecks, getting faster feedback from customers and iterating quickly.

  • Enhance Customer Experience
    Delight your customers in every digital interaction by optimising system quality and performance to provide a smooth, speedy and seamless user experience.

  • Maximise Your Investment
    Realise a positive ROI sooner and maximise your investment by focusing your energy on high-value features, reducing waste, and finding and fixing defects early.
  • The Wellington City Council (WCC) wanted to deliver quality outcomes without breaking the bank. Find out how Planit’s fast and flexible resources helped WCC achieve this goal.

this is a test Who We Are Landing Page

BANKING
Banking like a start-up.
MEDIA & BROADCASTING
Capture your audience
EDUCATION
Do your systems pass the grade?
MINING & RESOURCES
Innovate with confidence.
GAMING & WAGERING
Game day performance.
 

Agile: Before and After

By Leanne Howard | Agile Practices Consultant

INSIGHTS // Articles

20 Jun 2018

#Agile|#Performance|#Strategy

INSIGHTS // Articles

#Agile|#Performance|#Strategy

By Leanne Howard

20 Jun 2018

Many of the Agile methodologies and frameworks are really good at helping teams and organisations with the actual delivery, but what comes before and after? And can we use Agile to help with those activities?

This article takes some of the before and after delivery activities and explores how you may want to think about changing your ways of working or may want to introduce these disciplines if you do not currently do them.

Agile: Before and After

Before build starts

Firstly, how about building your Business Case? This is a great point to begin with your experimentation.

Let's start with some hypothesis and collaborate with all your stakeholders, including the delivery team, to see what is likely to give us the highest business value, i.e. our Return on Investment (ROI). We can use some Value Stream Mapping techniques to help us identify our priorities.

Value Stream Mapping

We then learn a little and adapt our requirements so we are focused on maximum value, whether that be for our customer or internally. This is the true implementation of "shift left." We cannot get any more left, as we are at the very start of the initiation of an idea.

At this stage, it also allows us to make some very strategic decisions for our business without having outlaid too much money. It should allow us, if the whole team is involved, to identify possible product risks and put mitigating tasks in place early (yes, deciding to do nothing is a valid option provided you have considered the impact and likelihood). Of course, one of the reasons that you may be writing the business case in the first place is that you are already starting with a product risk which you are putting in a solution to mitigate.

Once you have your funding approved, how do we turn our five/six high-level bullet pointed ideas into something the teams can start to consume? Here, we can use a range of practices and techniques. Some of these are not strictly Agile only, but they are certainly ones that you could see more commonly in Agile teams.

We can use techniques such as Kano Analysis to identify our customer delighters. Just remember that something that excited your customers last year and was a key differentiator for your product, may now be taken for granted in your next version. Just think about cameras in mobile phones! 

Kano Analysis

Agile should be very customer-centric and focused on delivering maximum business value, either through criteria such as the Minimum Viable Product (MVP) and/or Minimum Marketable Feature (MMF). Using techniques such as Kano allow us to identify our excites, for example, as separate to basic desires.

Once we start to elaborate our ideas, how do we decide how we are going to divide our backlog items up? Not everything can be the highest priority, right? Otherwise, we will return to traditional projects where we have to wait at least six months to deliver any benefit at all to our customers.

Now we can use Story Mapping to help us decide what to deliver next and the high-level dependencies that we may have. We should try to make stories as independent as possible, but we all know that in practice integrations, etc. are inevitable in the modern, complex world in which we live in.

After we have built the product

Now let us take a look at the after.  Right back at the beginning, we wrote a Business Case where we identified our high-level requirements, maybe some solutions options (again, high level), and we stated what our ROI was to be.

This is where I see a big gap in the whole delivery cycle. Very few organisations end up closing the loop, and what I mean by that is going back and doing a benefits realisation exercise.

We, as IT professionals, were particularly bad at doing this in traditional projects, and we seem not to be any better in Agile projects. I did some research with Project Managers, Product Owners and Business Analysts, and found that the overwhelming reasons were because:

  1. We have spent the money now anyway and it is in production, so it is too late if it does not give the benefit we envisioned at the Business case. There is no more money left to fund this activity (Benefits Realisation). At least with Agile there is the opportunity to mitigate both of these excuses.

    The first, we get feedback on what we have just delivered very quickly, in fact close to the end of our iteration. If the team is working towards delivering a shippable product at least at the end of each iteration, that means that we have only burned approximately two weeks of the team’s cost, if we are saying that is their cadence.

    If we are not giving value, then we stop the delivery. Plus, we will get the real, intended customer to provide feedback in a very quick feedback loop.
     
  2. Secondly, somewhat related to the explanation above, is that we are measuring our realised benefit on a gradual basis very soon after each release (two weeks in the case of above.)  In fact, in Agile projects we take it one step further and use empirical methods, as well as learn and adapt (i.e. we welcome changes in requirements based on actual feedback from our customers.)

Agile practices and techniques are not just for use by the teams to deliver products. The Agile Manifesto and Principles should apply from the very first idea to the wrap up of the products, and arguably even until its decommission.

Unfortunately, lots of the methods and frameworks make assumptions that you have done something somehow to get to a workable product backlog, and that when we have delivered the product, it is the end of the story. All shortcomings in my view, as they do not deal with the whole value chain and benefits realisation of those outcomes. Those practices and techniques should give you some starting points for considering ‘whole life Agile projects’.

Become Agile now

Seasoned Agile users may already be aware of some of the issues above but not be acting on them, or for those who are new to Agile, it is important to get form these good practices from the start. This will ensure you avoid falling into bad habits that can significantly impact project delivery, quality and cost.

Our coaches and experienced professionals can help to support your Agile transformation, bringing proven frameworks, templates and a wide body of Agile knowledge that can accelerate your Agile journey. To learn more, visit our Agile training and Agile testing sections.

Join The Discussion
Enquire About Our Services