Agile thinking
Organisations need to be more responsive and adaptive in the face of an accelerating pace of change.
Agile thinking enables companies to deliver products and services faster while involving customers and staff in improvement cycles they genuinely enjoy.
Case study
Imagine you have just joined Bank Yoyo as the CEO. Your customer satisfaction is somewhere in the middle of the pack (mildly negative in Net Promoter Score terms), your revenue growth is pedestrian, your staff engagement scores are around the industry average, and there are 40 strategic projects in the pipeline, 50% of which are behind schedule. Not surprisingly, market share is static, and there seems to be little you can do about it other than pull the price lever, because it takes you 120 days to release even simple product changes.
As a point of contrast, you have just had lunch with an old colleague who has joined a middle-sized specialist finance company focusing on the business market. Her company can release a product change in 12 days; the last major product release happened via something known as a Minimum Viable Product, which took 8 weeks to launch. That product needed later refinement but it captured market share before anyone could move, and cemented the company’s reputation as an exciting innovator. From your conversation with her, it seems that it is possible to work cross-functionally to innovate, learn, and deliver faster.
How do you get some of this magic?
You start by applying agile thinking to improvement projects, and then move on to product development. The reason for this sequence is that internal improvement projects allow you to experiment with the new techniques before you are seriously exposed to a customer outcome.
Agile thinking
A project is only agile if it meets a number of minimum conditions:
- You pull together a team that will work together to solve a clearly defined problem (or implement an opportunity) over a fixed timeframe. The fixed timeframe is an essential element of agile thinking. Often the team works in periods of time known as ‘sprints’, which deliver all or part of the solution at an accelerated pace, by a given deadline.
- The decision-making framework for agile projects is dramatically simplified. A small number of sponsors (1-2) will define the objective of the team’s work, and the team will decide what to recommend. The sponsors will then approve or otherwise. The decision-making bureaucracy is hereby simplified. If there are people who need to be part of the decision then they either need to be a sponsor OR they need to be part of the agile team. It’s that simple.
- The team members are given permission to experiment to test their hypotheses. These structured experiments are often known as minimum viable product This is the least sophisticated version of a product, practice, policy, or technology that might work. Essentially it tests hypotheses before you burn too much money on something that might not work.
The key thing to realise is that, in normal projects you try to control cost, functionality, and time, while for an agile approach you are principally focused on time. You may or may not get everything you want by a given date, but you will get something. It is based on the premise that "great is the enemy of good". In other words you can wait for perfection, or you can get something done and learn along the way. Delivering faster results through agile is all about getting something done, then learning and adapting more quickly than your competition.