Avoiding local optimisations in an agile project [closed]

Question

I'm very positive towards agile development, and have worked on agile projects on and off for about 13 years. But I have a concern that I've never really been able to address. It doesn't always seem to manifest, but it has bitten me a few times.

Agile seems to be in some sense a 'greedy algorithm'. Start with the highest value story, optimise the system to precisely fulfil that story, and repeat.

Actual greedy algorithms are prone to suffering from converging to locally optimal solutions, while missing a globally optimal solution.

Has this been people's experience?

Is it actually a problem?

If so, what techniques do you use to avoid such local optima and yet remain agile?

Answer 1

Actual greedy algorithms are prone to suffering from converging to locally optimal solutions, while missing a globally optimal solution.

This holds true if EPIC technical User Story and guideline is not established, along with the normal business EPIC user story.

Has this been people's experience?

At times yes, it has been my experience. One instance was when the user stories we worked on were broken down too much, and the solution was to broaden them to get a more global outlook at our designs. And at times it was different enterprise scrum teams in the same projectt, conflicting with different technical framework uses and approaches.

Is it actually a problem?

It is only a problem, if you ignore the technical EPIC user story or guideline.

If so, what techniques do you use to avoid such local optima and yet remain agile?

Here is one Agile approach to solving this: During Agile Release planning, instead of just coming up with a Business EPIC User Story, also come up with a Technical EPIC User Story. The Technical EPIC User story would have the product vision from a technical stand point, in terms of technical architecture, application framework, quality standards, and global design considerations etc. These could be broken down into smaller technical user stories, and have a Scrum Team which works on getting those user stories working. An example of a user story could be: "As a Technical Project Manager, I want the whole enterprise project using A, B, C framework, and coding as per X,Y,Z coding standards, so that there is uniformity in project development work. If you don't want to form a scrum team separately for this, then just keep them as reminder cards next to backlogs for development teams to use as guidelines.

As a testing guideline, we used to have successful integration testing as a done criteria for each backlog. A global test was conducted in an integration environment, on all working software deployed from all enterprise teams, to deem it shippable. So right from inception to end of the backlog, the theme is set for global working software and not just local working software.

Finally, Agile development involves keeping a constant eye on quality, and one of the quality issues could be bad design or a too localized design. As and when this is discovered, it should be redesigned within that backlog itself, and followed going forward for other Backlogs.