And what could help to make them successful
You might experience that especially large organisation that have been used to traditional SAP implementation projects struggle with the transition from a waterfall to an agile project methodology.
Especially the transition from traditional requirements gathering to a user story based approach sometimes seems to be a challenge. While IT delivery managers have often been trained in agile methodologies, e.g. as Scrum masters, business process experts might sometimes been lacking respective trainings, e.g. as Product Owners.
While traditionally gathered requirements could be broken down into a product backlog, it would be mandatory that the ownership for this restructuring remained with the business. Otherwise the product backlog would not be accepted as a replacement for the original requirements documents and the agile process would not work:
- Sprint definitions would not work because even if the entirety of the backlog was covered the completeness of the solution would not necessarily be given.
- Agile change management would not work because change requests would not introduce refined stories but potentially only changes to the original requirements document that should instead be reflected in changed backlog items.
- Agile documentation would not work because the completed backlog items would not necessarily replace traditional test scripts and user guides.
Since the aspect of playbacks after each sprint is usually received very positive by organizations not used to that constant opportunity to give feedback on what has been developed so far, these playback are eminent to reinforce trust in the agile process and should therefore not be missed.
Also there are pitfalls with the agile process that need to be managed. Especially the concept of user stories potentially not being delivered in a sprint, because of other user stories being accepted into that sprint instead, or blockers requiring time to be unblocked, might be seen as missed milestones. That is why insisting on those playbacks as an opportunity to demonstrate the current state of development and to explain deviations to stakeholders not close to the dynamics of the product backlog is a major success factor. Falling back to waterfall behaviour is a major risk in these circumstances.
Once the unit tested solutions leave development, there is a danger that organizations used to waterfall developments do not handle defects as additional backlog items to be dealt with as any potentially outstanding user stories because test managers might sometimes been lacking respective trainings, e.g. as Product Owners, similar to the situation with business process experts versus IT delivery managers. IT delivery managers trained in agile methodologies might therefore have to merge defects with the remaining product backlog to present both business analysts and test managers a unified basis for priority decisions.
To overcome some of these challenges project managers familiar with agile development methodologies could assist both business analysts and test managers to leverage their full potentials by assuming, e.g. the role of agile Product Owners.
