Agile Transformation is a strategy, not a goal.

I came across an article, “Transforming from Projects to Products.”

Excerpts of the article:

The general understanding and perception of “Agile.”

” ‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you ar.e reading this.  I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.”

Each company or organization should be concerned with becoming more agile (as defined in the dictionary). This is a matter of sound principles and ‘common sense’ (for example, eliminating waste and becoming more effective in what you do – indeed, in software development/product delivery, there are many ways to achieve this).

What is the goal if an agile transformation is not an end goal?

Organizations shouldn’t embark on a mission to become agile without understanding what it takes in terms of cultural and organizational changes – and, most importantly, figuring out what they want to achieve – why do you need a change?

Questions to be asked:

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you (or your clients) feel you are not getting value for money?
  • Are you slow to market?
  • If you are creating software products for internal teams, are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your ROI on software development too low?
  • Are you losing key development staff?
  • Is there a lack of transparency in the software development process?

As you notice, these questions which concern the whole organization. Any initiative for improvement should be looked at globally – at an organizational (systems) level – to avoid local optimizations.

  • What are the significant areas of improvement?
  • Transform from projects to products, including:
    • Stop managing and start leading.
    • Shift from “output” (deliverables) to focus on “outcomes.”
  • Embrace the idea there is (and will be) uncertainty instead of fighting it.

“Agile Product Leadership is about accepting the plan is likely wrong or at the very least unclear and the scope is unknown, and so adapting to change and building the right things to fulfil our customers’ needs.”

  • Reward people based on contribution to a common goal instead of individual performance.

Changing from:
“What will I do today?” to “What can I do to help the team towards our goal today?”
It can make a huge difference in behavior.

A common understanding of why we want to change as an organization

“Your business should be saying:

  • Where do we need to improve?
  • And how will we measure success?

Agile transformation may be a means of reaching that goal.

“If you choose an Agile Transformation you will measure success by delivering what customers need, by creating happy and satisfied customers not adherence to a plan. You will measure teams success by those that are willing to learn and grow.  By empowering teams to make decisions for themselves you can create an environment of continuous improvement.”

Read the full article at InfoQ.

and recall:

Image source: https://quickscrum.com/Images/article_detail/Whyagiletransformationisdifficult-1.png