I want to share with you a recent discussion. The question is: How am I able to use SAP Solution Manager to make my company more "agile"? The question that has to follow is: "What does agility mean for my enterprise?". Being asked this questions, I tried to get some more information about the common meaning of "agility".
I've used my tried and true way again: Hey google: "agile software development?".
The list of answers is huge. Let me just take this one:
http://searchsoftwarequality.techtarget.com/definition/agile-software-development. [1]
" ... Agile is a methodology that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product ..."
"... Agile requires a cultural shift ..."
"... Agile has replaced Waterfall as the development methodology of choice in most companies, but is itself at risk of being eclipsed or consumed by the growing popularity of DevOps."
So according to all experts the agile cultural shift paved the way for DevOps. (see [1]).
Taking some further investigations you will stumble over the Agile Manifesto and its 12 principles.
http://agilemanifesto.org/iso/en/principles.html. [2]
As an Solution Manager enthusiast my first choice for agility, flexibility and DevOps in a SAP environment is Solman. As I described here https://blogs.sap.com/2018/01/31/pylons-of-the-airvaves-here-is-my-request/ SAP has put a scaled agile implementation approach around DevOps principles into Focused Build in SAP Solution Manager 7.2.
An often used picture for the DevOps tool chain is the eternity symbol (continuous process of software delivery). I adapted mine by adding some of the tools available in Focused Build:
Let us do the reality check. (following the 12 Agile Manifesto priciples, [2] ).
(1) Early and continuous delivery of valuable software:
The key issue is to speed up the delivery process by avoiding complex requirement processes, release processes and complex test approaches. This should be possible in Solman.
Let me give you some examples:
- requirements:
Added by an FIORI app in initial status "created".
After saving, it's just one click to set it to "approved".
You add a categorization and the link to the process documentation by simple choosing it from the
value help.
- a workpackage is then created by a simple click.
Set the workpackage to "scope analysis" and add a workitem.
With another klick finalize the scoping. Just by setting the workpackage to the status
"to be developed" creates the workitem in status "created".
- the workitem is then ready to be planned within a scrumboard.
The sprint planning can be done and the sprint execution can start.
(picture: scrumboard bsc solutions)
- testing: this is supported by a tiny little application called "assignment analysis and test plan generation". There is one function which shows you immediately the work packages without
test plan coverage.
From here you simply add test cases and create the test plan.
So to my opinion: plan, code, build and test ==> CHECKED.
(2) Welcome changing requirements, even late in development. Agile processes harness change:
Tipp: In an agile software development you should use user-stories instead of huge blueprints and concepts. You can add them in Focused Build by simple drag & drop mechanisms.
Hint: Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user. (source: Atlassian)
... in the following situations and phases changes to existing requirements (and more over deliveries) are possible:
Changing requirements almost everywhere in the end-2-end process: I think ==> CHECKED.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale:
The typical cycle in Focused Build is a sprint, lasting 2 weeks. Several sprints are tied together in waves.
(source: SALT Solutions AG)
As shown in the picture a sprint lasts 2 weeks, the three sprints build one Wave (Wave1).
After a wave you do a "touch and feel" session with your business.
The following picture shows how an incremental deployment with constant feedback loops can be realized by using Focused Build along an DevOps approach.
(picture source: original by SAP).
Several test types are assigned to release, project, waves and sprints.
So, frequent incremental software in short time frames? To my opinion ==> CHECKED.
(4) Business people and developers must work together daily throughout the project:
Focused Build comes with technical roles for "business analyst", "developer", "release manager"
and "enterprise architect". The joint base of information is the transaction types for requirements,
work packages and work items. The roles plus the available FIORI apps and dashboards are
suitable to support the so-called "Core Team". Thanks to jarley.nascimentogonalves for the picture taken from the blog post https://blogs.sap.com/2017/08/12/sap-activate-with-agile-really-works-and-save-time/.
(6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation:
Nothing is more valuable than talking to each other, giving honest constructive and mindful feedback.
Using the SAP Solution Manager you should motivate your business to add their feedback and ideas into special text fields of the requirement or the work package. Also comments in user acceptance tests (UAT) could be added in the appropiate text field. See my examples as follows:
a.) Business requirement:
b.) Work package:
c.) User acceptance test:
The Scrum Board allows to save comments for retrospective and reviews.
(picture: scrumboard bsc solutions)
(8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely:
The so-called "sponsors" that I will call "the lean management" is interested in KPIs and dashboards.
An enduser is always able to see the status of his/her request by simple using the "my requirements" App. You can decide by filtering those requirement where you are the owner or the business expert.
A developer or a Scrum master gets his information out of the Scrumboard.
(picture: scrum board bsc solutions)
Other sources of information for the management:
Further KPIs are named by Atlassian, ... (sprint burndown, epic and release burndown, velocity, ...)
(Source: https://www.atlassian.com/agile/project-management/metrics ). [3]
Constant pace observing, I think ==> CHECKED.
(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly:
Like in Scrum there should always be regular sharing of results, faults and experiences.
(see the CALMs topic, e.g. here http://conferences.unicom.co.uk/balancing-devops/. [4]
The "S" means sharing.) As defined there, sharing means "... Collaboration and optimisation of ideas, stories of problems and success is essential and also the realisation for the teams to treat the problem as an enemy and not each other. Sharing of ideas opens the channels of feedback and so leads to improvement. ..." (see [4]) ).
I like "the problem is the enemy, not each other" aspect most.
Some companies brought the feedback culture to excellence.
More and more #chatops (a collaboration model to connect tools, people and processes) is
used. The advantages are summarized here https://techbeacon.com/chatops-essential-guide-basics-benefits-challenges. [5].
"... Moving to a more efficient and extensible method of communicating not only opens the doors to highly collaborative companies.." and "... IT professionals are looking for ways to begin their own journey. Companies are placing a strong focus on creating a culture of increased collaboration, shortened feedback loops, and task automation. As a result, high-performing cross-functional teams are the new norm..." (original from [5]).
This needs a combination of tools and changing in communication behaviour.
Observing some of the principles of communication you will find reasonable tools for team collaboration, then you can also follow this part of the 12 agile principles. ==> CHECKED.
Conclusion:
If you ask me if agility and flexibility is possible in SAP development projects, then my conclusion is "Yes". Does it depend on the tools? No. Interacting with each other, observing agile principles, reducing work to the minimum, and agreeing on metrics aligned with management are the key to success. For the supporting software, you have the edge with the Focused Build in SAP Solution Manager 7.2. The Solution Manager can do it.
Turn it ON again.
I've used my tried and true way again: Hey google: "agile software development?".
The list of answers is huge. Let me just take this one:
http://searchsoftwarequality.techtarget.com/definition/agile-software-development. [1]
" ... Agile is a methodology that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product ..."
"... Agile requires a cultural shift ..."
"... Agile has replaced Waterfall as the development methodology of choice in most companies, but is itself at risk of being eclipsed or consumed by the growing popularity of DevOps."
So according to all experts the agile cultural shift paved the way for DevOps. (see [1]).
Taking some further investigations you will stumble over the Agile Manifesto and its 12 principles.
http://agilemanifesto.org/iso/en/principles.html. [2]
As an Solution Manager enthusiast my first choice for agility, flexibility and DevOps in a SAP environment is Solman. As I described here https://blogs.sap.com/2018/01/31/pylons-of-the-airvaves-here-is-my-request/ SAP has put a scaled agile implementation approach around DevOps principles into Focused Build in SAP Solution Manager 7.2.
An often used picture for the DevOps tool chain is the eternity symbol (continuous process of software delivery). I adapted mine by adding some of the tools available in Focused Build:
Let us do the reality check. (following the 12 Agile Manifesto priciples, [2] ).
(1) Early and continuous delivery of valuable software:
The key issue is to speed up the delivery process by avoiding complex requirement processes, release processes and complex test approaches. This should be possible in Solman.
Let me give you some examples:
- requirements:
Added by an FIORI app in initial status "created".
After saving, it's just one click to set it to "approved".
You add a categorization and the link to the process documentation by simple choosing it from the
value help.
- a workpackage is then created by a simple click.
Set the workpackage to "scope analysis" and add a workitem.
With another klick finalize the scoping. Just by setting the workpackage to the status
"to be developed" creates the workitem in status "created".
- the workitem is then ready to be planned within a scrumboard.
The sprint planning can be done and the sprint execution can start.
(picture: scrumboard bsc solutions)
- testing: this is supported by a tiny little application called "assignment analysis and test plan generation". There is one function which shows you immediately the work packages without
test plan coverage.
From here you simply add test cases and create the test plan.
So to my opinion: plan, code, build and test ==> CHECKED.
(2) Welcome changing requirements, even late in development. Agile processes harness change:
Tipp: In an agile software development you should use user-stories instead of huge blueprints and concepts. You can add them in Focused Build by simple drag & drop mechanisms.
Hint: Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user. (source: Atlassian)
... in the following situations and phases changes to existing requirements (and more over deliveries) are possible:
- you can split requirements (user-stories) into 1 + x workpackages
- a work item my be shifted into another (the next) sprint
- you can re-prioritize your backlog of requirements by changing the business value to a
higher value - a work package can easily be shifted to another project with a different time box
Changing requirements almost everywhere in the end-2-end process: I think ==> CHECKED.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale:
The typical cycle in Focused Build is a sprint, lasting 2 weeks. Several sprints are tied together in waves.
(source: SALT Solutions AG)
As shown in the picture a sprint lasts 2 weeks, the three sprints build one Wave (Wave1).
After a wave you do a "touch and feel" session with your business.
The following picture shows how an incremental deployment with constant feedback loops can be realized by using Focused Build along an DevOps approach.
(picture source: original by SAP).
Several test types are assigned to release, project, waves and sprints.
So, frequent incremental software in short time frames? To my opinion ==> CHECKED.
(4) Business people and developers must work together daily throughout the project:
Focused Build comes with technical roles for "business analyst", "developer", "release manager"
and "enterprise architect". The joint base of information is the transaction types for requirements,
work packages and work items. The roles plus the available FIORI apps and dashboards are
suitable to support the so-called "Core Team". Thanks to jarley.nascimentogonalves for the picture taken from the blog post https://blogs.sap.com/2017/08/12/sap-activate-with-agile-really-works-and-save-time/.
(6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation:
Nothing is more valuable than talking to each other, giving honest constructive and mindful feedback.
Using the SAP Solution Manager you should motivate your business to add their feedback and ideas into special text fields of the requirement or the work package. Also comments in user acceptance tests (UAT) could be added in the appropiate text field. See my examples as follows:
a.) Business requirement:
b.) Work package:
c.) User acceptance test:
The Scrum Board allows to save comments for retrospective and reviews.
(picture: scrumboard bsc solutions)
(8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely:
The so-called "sponsors" that I will call "the lean management" is interested in KPIs and dashboards.
An enduser is always able to see the status of his/her request by simple using the "my requirements" App. You can decide by filtering those requirement where you are the owner or the business expert.
A developer or a Scrum master gets his information out of the Scrumboard.
(picture: scrum board bsc solutions)
Other sources of information for the management:
- Sprint Burndown
- Wave Progress (this is one view provided by Focused Build within SAP Solution Manager identifying the progress of Work Packages in a wave and distinguish if they are still in scoping or already in development.(picture source: SAP)
- overall status of the wave progress (shown in a tile of the so-called "Solution Readiness Dashboard".
Further KPIs are named by Atlassian, ... (sprint burndown, epic and release burndown, velocity, ...)
(Source: https://www.atlassian.com/agile/project-management/metrics ). [3]
Constant pace observing, I think ==> CHECKED.
(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly:
Like in Scrum there should always be regular sharing of results, faults and experiences.
(see the CALMs topic, e.g. here http://conferences.unicom.co.uk/balancing-devops/. [4]
The "S" means sharing.) As defined there, sharing means "... Collaboration and optimisation of ideas, stories of problems and success is essential and also the realisation for the teams to treat the problem as an enemy and not each other. Sharing of ideas opens the channels of feedback and so leads to improvement. ..." (see [4]) ).
I like "the problem is the enemy, not each other" aspect most.
- Always think about treating failures as opportunities
- Don't blame someone, share your knowledge and support with generosity
- Share common goals
- Agree about senseful metrics
- Always keep the end in mind, which is a succesfull sprint or an excellent product
- If something went wrong, spend enough time to investigate, eliminate the error and go for a next optimized try
Some companies brought the feedback culture to excellence.
More and more #chatops (a collaboration model to connect tools, people and processes) is
used. The advantages are summarized here https://techbeacon.com/chatops-essential-guide-basics-benefits-challenges. [5].
"... Moving to a more efficient and extensible method of communicating not only opens the doors to highly collaborative companies.." and "... IT professionals are looking for ways to begin their own journey. Companies are placing a strong focus on creating a culture of increased collaboration, shortened feedback loops, and task automation. As a result, high-performing cross-functional teams are the new norm..." (original from [5]).
This needs a combination of tools and changing in communication behaviour.
Observing some of the principles of communication you will find reasonable tools for team collaboration, then you can also follow this part of the 12 agile principles. ==> CHECKED.
Conclusion:
If you ask me if agility and flexibility is possible in SAP development projects, then my conclusion is "Yes". Does it depend on the tools? No. Interacting with each other, observing agile principles, reducing work to the minimum, and agreeing on metrics aligned with management are the key to success. For the supporting software, you have the edge with the Focused Build in SAP Solution Manager 7.2. The Solution Manager can do it.
Turn it ON again.
- SAP Managed Tags:
