S3 tech blog

Businesses with digital projects have accepted that lean thinking and agile methodologies provide the best approach for their projects and ventures, for example mobile application development, web application development. Start-ups use them as a matter of necessity. Commonwealth Bank, Suncorp, Telstra, Fairfax and even the Australian government have realised the value in this new method.

Lean thinking and an agile approach work by taking an iterative, evolving approach to developing an idea rather than the more traditional, stages of plan, develop and deliver as a whole. Lean and agile can shorten product development cycles, reduce the risk of misunderstanding user needs, increase the likelihood you create something that sticks and, if it doesn’t work, decrease the cost of the failed project.

Lean isn’t for everyone and here are six watch outs to think about before embarking on your own lean project:

1. Lean is not the ‘no plan’ plan

Far too often people say ‘we’re running agile, so we don’t write plans or requirements any more’ and the speed and low-cost benefits are used as an excuse not to invest time and money into thinking things through, opening up a project for failure.

Going lean doesn’t mean doing away with planning.

Each project should have a list of completed or outstanding tasks. Use documents, diagrams or mock-ups describing what needed to be done to keep everything on track. You don’t need to spend months planning but you still need to plan, do requirements and think ahead to keep stakeholders on the same page. You may even choose to evolve your planning and requirements iteratively.

2. You and your stakeholders must accept things will go wrong

Lean means that you would prefer to try, fail, learn, improve and repeat in small incremental and manageable investments. Failing is part of the process of understanding where things are going wrong.

Demanding that things go smoothly is therefore false economy. Sure, there are mistakes that are avoidable but more often than not, if you have good team and you’re following the process correctly, the errors will be important. Errors mark a need to change approach, re-evaluate or, in extreme cases, kill the project – a much more favourable, low-risk outcome compared to an investment in something that isn’t going to work.

But you need board, senior management, customers and suppliers to buy in. Google does this really well. They brand their products or features as “beta” or “labs” signalling that they’re trialling something and it may go wrong. People accept that these features may have errors because they know it’s part of the process of producing a better outcome for them.

This might sound obvious, but when you’re innovating and outside your comfort zone the temptation to return to the comfortable can be strong, especially when the board or senior management is breathing down your neck demanding to know why things aren’t going smoothly. But if you succumb, you face a much greater risk: a project with the expectations of “lean” but none of the flexibility to experiment and learn.

3. Lean isn’t an excuse not to commit to things

With the emphasis on trying, failing, learning and improving it is easy for teams to start avoiding any commitment but you can’t let lean or agile be a scapegoat. At the end of the day, your team is still operating in a commercial environment and results need to be delivered.

4. Accumulating technical debt

Projects that use lean as an excuse to go as quickly as possible without much forethought tend to pile up what engineers call ‘technical debt’ that is an amount of future effort required to fix technical tasks that were done the quick way instead of the right way.

5. Lean doesn’t mean you can always change your mind and expect immediate results

Lean can help move things along faster and can be better at dealing with change when compared to more traditional approaches. This is often how it is sold to management and stakeholders. However, lean and agile don’t mean you can repeatedly change your mind and expect immediate results.

Software engineers make decisions and create logical structures based on the current requirements and future vision of the project. Some changes can easily slide inline with prior decisions and the existing logical structures but other changes may require a significant restructure which in turn results in a significant effort to make changes.

6. Knowing when to move away from lean

The landscape may have changed; you may have thousands of users, new regulation to deal with or greater certainty that the project will succeed. Ignoring more “traditional” planning or risk mitigation strategies may result in missed opportunities or worse, in a damaged brand or fines.

The lean methodology has already brought great rewards and better business practice to many firms, but like any other process, misunderstand it and it can go wrong.

Source: Start-up Commons