Enterprise Performance Management Solutions - Agile Projects (Scrum)

Enterprise Performance Management Solutions - Agile Projects (Scrum)

Waterfall Project Methodology is too often misused. It never was supposed to be the default software design life cycle (SDLC) for all project scenarios but for some consultants it has become just that.

Waterfall works best when there is a defined problem and a prescribed solution that meets it exactly. Not a solution template or design but actual real-life product that meets the requirements which are all known.

For example if a company has decided on a pilot roll out of software and so the software is delivered first to region A. The problem (requirements) have not been fully defined and the solution is not known too well but region B, C, D, and E have exactly the same requirement. It would then make sense that you would use waterfall to implement the solution in region B, C,D, and E but only after region A had been successfully piloted. Region A would benefit from an agile project.

The waterfall methodology it is assumed that requirements are known exhaustively and can also be static while the product is defined, designed and delivered. The difference with agile is that assumption is never made.

So what is an Agile project? It is many things to many people. So lets leave the hype and get down to the facts about Agile.

Agile is not just one methodology it is many strands weaved into one banner of Agile.

Agile methodologies evolved from the adaptive software development methods in the late 1950's and later be called "lightweight" software development because of their incremental development methods and were in stark contrast to the "heavyweight" software development of the waterfall. 

Agile projects come in many forms the particular form we are looking at is Scrum. The Scrum methodology involves capturing input from the "product owner", stakeholders and business users to form a to-do list called the backlog.

Then run up to a product release is called a "sprint" an unfortunate term as it gives the impression of dashing headlong with abandon towards a finish line when agile is nothing but that.

The backlog is user centered and consists of user stories describing features or issues with features. The features can be prioritized using an agile triage system on the follow factors.

  • Value - What value does this bring to the product as a whole?
  • Cost - A low cost for designing and deploying the feature may make that feature a good candidate to implement first. 
  • Risk - What is the risk versus reward of a feature to the entire product?
  • Knowledge - The knowledge should be sufficient about a feature.
  • Resources - What resources are available to design and deploy the feature.
  • Dependencies - Does the feature need a pre-requisite action or task done before it can be designed or deployed?

How is Scrum setup and run? Lets get down to the detail.

  • Envisioning by the product owner
  • Define start date
  • Define sprint duration
  • Define scrum planning, sprint review and retrospective schedule
  • Define the "done" state
  • Define sprint durations
  • Define release plan and milestones

 

The release plan and milestones can be a bit of an estimate initially as it assumes no serious impediment backlogs and a linear or increasing velocity cycle.

 

Deciding on the number of iterations for each release is dependent on the user stories.

 

 

If the are two or more teams work on different but dependent feature the release plan can be done in the following way.

 

 

Sprint Meetings with Team leads with backlog, team capacity, done definition to agree on the spring goal and final sprint backlog.

 

 

The deliverables at the end of the first sprint are described as the sprint artifacts

Product Backlog - known activities remaining specific to the product

Sprint Backlog - activities remaining relating to the next sprint

User Stories - UX and issue list from a user perspective or directly from the product owner

Tasks - A breakdown of the activities into smallest unit of work

Burn down charts - work done so far

Product increment - A completed portion of the product

Impediment backlog - show stoppers and obstacles

Definition of done - the list of activities that make a sprint complete

How many sprint cycles do we need to produce the first release?

The release date for the product will depend on the scrum plan and sprint schedule and sprint backlog velocity (rate at which a backlog is completed)

When the milestone for the first release approaches we are aiming for a stable release in Production with the agreed features working and tested with no priority 1-3 backlog items. 

Once the first release is in Production then in my experience of running SAP Enterprise Performance Solutions it is best to approach it with a Lean Go Live set up.

Sprint (Technical Cycle Release) Realisation - are the activities required to realise a technical cycle release.

1) Refactoring code

 

If the code is said to "smell" it means the code is defective in some way. Refactoring is how we fix the defect without having to rebuild the code from the ground up which could me design change, scope change and full product testing.

 

 

 

2) Sprint Backlog Triage - Prioritising the backlog items.

3) Product Backlog Review - Ensuring the product backlog are consistent and current.

4) Quality Reporting - Measuring quality of code design, configuration, deploy and test work.

How do we quality assure and risk assess the code you write?

 You should have quality built-in to your code. Not just reporting on quality measures but actually raising the standards of the code that is in the legacy system you are refactoring.

 

So you now you want to build quality into your solution.

The Quality reporting should be triggered on input.

5) Sprint Review Meeting - After a sprint we review the sprint and impediment backlogs.


6) Sprint/Impediment Backlog adding/deleting/changing - Making the necessary changes to the backlogs for cycle N+1

Release Maintenance - are the activities required to realise a full release.

Let us look at the bigger picture at Enterprise Level for the Agile Project now we have delved into the main areas and workings of the methodology.

Agile is more advanced than its predecessor Waterfall but in certain scenarios where a waterfall project has failed to deliver an optimum solution or define the concept model/start up model, Agile can be used to refine and lock in the optimal solution.

Now SAP has started recommended Agile software development and delivery as part of its brand new SAP Activate methodology.

Agile is more cost effective that traditional forms of software development and that makes for happy SAP customers who are happy to keep paying licence fees.


The SAP Activate methodology is actually a hybrid of a Rapid Deployment Solution and an Agile solution, the modular approach is incremental and cross functional so you can develop and test features in true agile style.

SAP Enterprise Performance Management solutions like SAP ERP solutions like S4/Hana need software development methods which will validate the solution and have quality built-in and Agile gives you all that and more. It is time if you haven't to become Agile.

 

References:

 

 

 

 

 

 

Paul K. Smith 保羅・史密斯

Financier, Producer, Physicist, Neuroscientist, Impresario, and Playwright.

7y

: I'm going to call this what it is: Another masterpiece, Michael.

To view or add a comment, sign in

Insights from the community

Explore topics