One of the most important and may be the most difficult part of commencing any SAP Project is zeroing down to a number i.e. Budget. The best brains of the company put all their knowledge/techniques learned and acquired; to get as close as possible to the magic number (read: Budget).
We all know, most of the SAP Projects follow “Waterfall model“.
Figure: Waterfall model for Software Project.
You thought requirements are frozen in blueprinting phase. You got it wrong. 🙂 Only if requirements were sealed, implementation would have been a cake walk. All possible scope and design details for any project can be identified by Big Design Up Front approach, popularly known as BDUF. But we know nothing is 100 percent.
During the Implementation phase, the motto is to fulfill the requirements identified in the blueprint. If for some unavoidable reason the project exhausts all fund, the only option left is to arrange more funds. No manager would like to orphan a project half way.
How many times does the Implementation go as per the blueprint plan? The actual realization phase is like the real match. However good you might be in the net-practice, the real game is the Realization/Implementation phase. The sign-offs received in the past months often seem to be half-baked cakes. The actual scenario creeps in when you make your hand dirty in the system. You would find exceptions in the process, business and even in data.
So, what option are we left with? All the brains need to regroup and revisit the requirements. If you get new Change Requests, consider you are on the right path. If you identify the risk during the realization phase, you do not need to work overtime after Go Live. Recently, you must have read about hundreds of flights and thousands of flight tickets canceled by a very popular airline in USA leading to loss of millions of dollars (forget about the reputation and good will) only because of some small technical glitch. Industry experts doubt it was a small Implementation failure. 🙂
SAP Project needs continual planning and monitoring. The amount of fund put into any Implementation project is huge and if one follows traditional project management style then it might lead to unwanted management overhead.
Agile considers management overhead to be one of the largest sources of waste on a project. Although the consultants are niche but if they follow BDUF (Big Design Up Front), they might not meet the deadlines and it might lead to an answerable discussion between project delivery team and finance/management team. And we all know, when the project is running late and is at risk, consultants burn the midnight oil and every activity are tracked and management look for a reason to escalate. End product – Project Stress and Team Stress.
Agile Methodology, on the other hand, bypasses all these menaces for SAP Project because new requirements locked during realization go for an iterative loop and enhance delivery executive decision-making mechanism.
The popular 80-20 technique (roughly 80% of the effects come from 20% of the causes) can be used and an assessment of value delivered till date can be made and checkpoints would be identified throughout the project, to decide where to continue spending and where to stop. If for an unforeseen reason, there is an issue in the schedule, Agile suggests getting the higher value items done. They are the number 1 priority. The lower value items means less budget needs to be sneaked out later to get the requirement fulfilled (High value is not always priority 1. Sometimes cheaper but the critical piece also takes precedence).
The significant difference between Waterfall and Agile Methodology is, Agile follows “Spiral” approach whereas Waterfall has an irreversible approach. Theoretically, Waterfall approach cannot enhance prior phase even when there is a dire business need.
Also Read: SAP Acitave Methodology for S/4 HANA
Agile is the Methodology; Scrum and Kanban are two tools which follow this Agile Methodology.
Scrum and Kanban
We have tried to compile an overview of Scrum and Kanban. Each has considerable different base elements but both have the same effect. Different paths to the same destination.
Scrum was developed by Jeff Sutherland and Ken Schwaber in the early 1990s. It uses time-boxed iterations. Scrum calls its iterations, “sprints” and the goal of each sprint is to build a tested, workable piece of the system, that is ready to be released to production.
Figure: Scrum sprints
Scrum relies on “product backlog” to collect requirements and manage the scope. Each sprint builds a selected set of items from the backlog.
There is a KPI (Key Performance Indicator) expert sitting around and the end of every sprint he collects the backlog after realization and prioritizes, discuss it with other Key Persons and align then in a queue of being delivered.
At the starting of every sprint, Key Person dictates requirements to every team involved and define the preferred list of objectives to the duration of the sprint. Sprint starts with a kick-off the team meeting. The team then negotiates the sprint scope, based on their estimates. A conversation then ensues where the team gains a high-level understanding of the selected backlog items and creates an initial draft of the tasks required to complete each selected item.
A unique aspect of Scrum is its approach to teams. There are no “unique” roles in Scrum, other than the developer, Scrum Master and Process owner (KPI Expert).
Scrum master is the rule expert for the team, makes the team understand the rules of the project and clears all the encumbrances of the duration of the sprint.
Figure: One Sprint demonstration
The Process Owner is responsible for defining the project vision, deliverables and priorities.
Other than the ScrumMaster and process owner, all other team members are referred to as “developers.” The reason behind this is to maximize collaboration within the team. The objective of every team member to do every task assigned to him.
This means that any one person should be able to perform requirements and design analysis, code, configure, test and write documentation. This generalization causes issues in the specialized world of SAP configuration.
“Smaller Team performs much better under this Agile methodology” — Scrum Experts Say.
Independent study found that a “five to seven person team will complete an equivalently sized project in the shortest amount of time.” Jeff Sutherland writes that the “team in Scrum is seven, plus or minus two people” (Scrum Handbook). Due to the smaller team size, Scrum has a method of coordinating projects of larger sizes and refers to this as a “Scrum of Scrums”.
A Scrum of Scrums involves Scrum Masters from each team meeting to coordinate work between the teams. In the Scrum of Scrum approach, planning must include careful consideration of dependencies between the teams, to help ensure that each team can proceed independently on their work as much as possible. Scrum believes that only historical performance, or velocity, is a valid predictor of future performance.
Kanban has its origins in lean and just in time (JIT), manufacturing processes. Japanese, the term Kanban refers to a “signal card”. Signal Card for a process owner (or an upstream process) means that (Manufacturing process) needs the raw material or service and process is signaling that it is going low on this object.
Figure: Kanban in SAP SDLC
No new procurement or a new process is initiated till the signal card is raised which says you can initiate the process to fill the vacuum created consumption of a raw material or service.
Kanban was developed as a mechanism to help control scheduling of the work needed to produce a product. It serves a number of key purposes which center around visualizing work so that producers know what needs to be produced when it needs to be produced, and how much to produce.
David Anderson took Kanban principles and applied them to software production (Kanban: Successful Evolutionary Change for Your Technology Business). He found that the core principles of Kanban served well to help address issues of waterfall software production. Specifically, Anderson was able to define a Kanban approach to software that allows its users to improve throughput and reduce lead time.
On a software project, this is revealed in lower quality work and an increase in unfinished work. Kanban addresses this issue by recommending Work In Progress (WIP) limits for each of our work item types.
Project Manager try to reduce the lead time. Lead is just like delivering the first quantum of deliverables according to the scope of the project. “From starting a feature to completing it”.
By increasing throughput, the project is able to get more work done in a given time period. By decreasing lead time, the project is able to more quickly deliver value to the customer. Anderson recommends a number of lean techniques to improve throughput and lead time. These include, for example, reducing multi-tasking, addressing bottlenecks and roadblocks and reducing waste.
Multitasking literally means the simultaneous execution of more than one program or task by a single person. This puts down the quality of the delivery of tasks for sure because you again start to do sequential work in a round robin way. Multitasking is a good way to do many things poorly. 🙂
Project managers or Process owners bloat team with tasks which cause poor quality in delivery. They try to pretend that the team has more capacity than it truly has.
Once we start that method of working, it spirals and we find that we can never catch up because the team ends up with a stack of items in the process that never seem to move to “done.”
A Kanban board visually shows how much work is in progress and gives a simple checking mechanism to ensure that the WIP limits are respected.
These concepts further give rise to SLA (Service Level Agreement) and other agreements and penalties if WIP limits are not respected.
The project’s job at that point is to identify methods to relieve the bottleneck. Methods can include, for example, improving upstream processes to ensure that work arrives in a “ready to work on” state at the bottleneck point. If the bottleneck is a programmer, then it needs to be ensured that test specifications are in a well-finished state, so that the programmer does not require as much back and forth communication with the analyst. Another method is to redesign the work so that the bottleneck does not have as much work on their plate.
Dependencies are the reason for a bottleneck. If a process is in a wait state and is required for some context of another process to complete and then start its execution this is the biggest bottleneck.
In other words, upstream processes are waiting for the signal card to get issued from the downstream processes to move ahead. The Kanban board can be used to quickly highlight these blocks and focus the team’s efforts on working to resolve the block.
The structure of a Kanban board helps to communicate priorities to the team. The Kanban board begins with an input queue. The input queue should be loaded with just enough work from the product backlog to keep the team busy.
Figure: An example of a Kanban board
Kanban uses five core properties to improve software development:
• Visualize workflow
• Limit work in progress
• Measure and manage flow
• Make process policies explicit
• Use models to recognize improvement opportunities (Kanban: Successful Evolutionary Change for Your Technology Business).
Figure: Kanban meshed with CMMI
As in Scrum, Kanban believes that historical performance is the best predictor of future performance. In Kanban, one can use throughput, a measure of completed work items per time period and lead time, a measure of the duration it takes to complete a work item, to predict the time it will take to complete future work items.
Enjoy this: Different breeds of OnSite Coordinators
Scrum and Kanban are two flavors of Agile software development Methodology- two surprisingly simple but highly powerful approaches to software development. Sometimes keeping things simple is the best approach. 🙂
Which one is better?
Someone said, there is no such thing as a good or bad tool – just good or bad decisions about when and how to use which tool. No tool is complete and nothing in this world is perfect.
Agile methods are often called lightweight methods because they are less prescriptive than traditional methods. Ok, what does prescriptive mean? A doctor prescribes and we do not question him. Just take the medicines he prescribes. 🙂
Prescriptive means “more rules to follow” and adaptive means “fewer rules to follow”.
100% prescriptive means “No usage of the brain”. Just follow orders like Army men. 🙂
100% adaptive means “No rules or constraints at all”. Free bird. Do whatever you want.
And we know excess/extreme of anything is not good for our health.
Just to put in black and white, experts say, Scrum is more “Prescriptive” than Kanban. But both are highly “Adaptive”.
Since both Scrum and Kanban follow Agile fundamentals and principles, both are equally effective tools. Experts suggest, if an organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum is the first choice. If the organization is already having working processes, which they want to improve over time without reshuffling the whole system, Kanban should be the tool to be adopted.
If you want to mix and match and if it works for your organization, experts say – Go for it. Take the goods from both the worlds. 🙂
Agile SAP: Introducing Flexibility, Transparency and Speed to SAP implementations. By Sean Robson
Kanban and Scrum making the most of both. By Henrik Kniberg & Mattias Skarin
If you want to get such useful articles directly to your inbox, please SUBSCRIBE. We respect your privacy and take protecting it seriously.
If you liked this post, please hit the share buttons and like us on facebook.
Thank you very much for your time!!
About the Author: Gaurav Ahluwalia
Gaurav is associated with SAP world for 10 years now. He loves reading books, writing technical documents, analysis cricket and surfing knowledge on the internet.
Find more about him on LinkedIn.