We were using SAP BPC 10.1 for our planning scenarios but at some point of project implementation and utilisation, we noticed BPC was not answering the requirements coming from the business users. System was full of workarounds which was far away from a stable and flexible architecture. We were creating a monster in the system.
“The simplest solution is usually the right one”
I had an idea of removing BPC layer totally from the planning scenarios and move to BW-backed custom SAPUI5 planning applications (this story deserves another article). It was time for it and we really did it. We also dropped the team members who were against the idea of change :D. It was the best decision we have ever made. Project scope was huge and it was containing several modules like planning data entry, pivot files generated from ABAP layer, document management system, dashboards, offline planning with excel upload/download, business-driven master data management, workflows, cost allocation, announcements, business-driven customisable email system, user designed PDF templates, electronic signature etc. This huge scope lead another issue which is related to project management, development, deployment, source code versioning and an environment needed to collaborate with the business users. Here comes the Azure DevOps.
What is Azure DevOps?
“DevOps is the union of people, process, and products to enable continuous delivery of value to your end users” — Donovan Brown, Microsoft
Azure DevOps is a platform where you have set of services that gives you the ability to collaborate with business users, plan your project in an Agile way with backlogs, epics, features, user stories, tasks and bugs, source code management with unlimited repository option, CI/CD pipelines for deployment and testing. Below image would be a good representation of DevOps. It is a continues process.
Problem to fall in love with :/
Majority of SAP projects are still following waterfall approach. Beside the methodology, entire project management done via excel sheets, word documents for blueprints which takes enormous amount of time to write, endless follow-ups to get it signed, communication via emails for the tasks and assignments, no proper tracking of development and deployment. Project management tools(even if it is used) decoupled from the development and deployment tools.
We also went through from same era. I had personal efforts to use notion, nuclino and asana for development tracking. Quip for planning and documentation. Gitlab for source code repository. They were all fine separately but as i said earlier they were highly decoupled from each other. They were all different environment and we were creating users in each application separately.
“Fall in love with the problem, not your solution”
Here comes Azure DevOps. It supports Agile methodology out of the box and it is already integrated with our company active directory. Same user who has a task assigned from the backlog also develops and pushes application to Azure Repo. You can easily plan your epics, features, user stories, tasks and bugs. Application also can be pushed to SAP server with CI/CD pipelines. Source codes or project can be easily documented via Wiki. Everything is one place and it is very convenient.
Why we prefer Agile ?
I am not going to explain agile manifesto and key principles here but Agile software delivery is great. If you don’t think so, i strongly believe you have been introduced to the concept in an improper way. First of all, Agile approach values people over process. It is human centric and aims collaboration of business users and project team more frequently, even daily. This emphasis on the people to put focus and their energy for innovation and problem solving skills. Any late request and change is always welcome and makes it easier to deliver in an iterative plan. In short, it is happy ending for both sides.
“Agile approach enables organisations to fail fast and fail cheap, in other words it enables faster release cycles by taking advantage of faster development cycles”
Adaptation of SCRUM, the best thing we have ever did!
After we decided to use Azure DevOps, we also wanted to adopt SCRUM framework. It is natively supported by Azure DevOps. My initial idea for Azure DevOps was mainly using kanban boards and repository. I was thinking, like majority of others, “we are already agile” but we weren’t. I was planning to combine our Asana culture and Gitlab practice easily in Azure DevOps platform. Once we had an Agile coach and SCRUM training, it really made a lot sense to give it a try for SCRUM with all its rules with a slight customisation. Sprint preparation, daily scrum meetings, sprint reviews, retrospectives and all the scrum values which we are adopting was really changing the team and working style. Output was amazing.
“Business users are happier, development team is happier and management is happier. We are back!”
Team started delivering everything planned on time. Efficiency was very high and customer satisfaction was sky rocketed. Trust to our team was significantly increasing (million thanks to our team). Our success was creating new project opportunities which we had to reject due to our resource limitations. To be honest, i never wanted to hire more developers and deliver a poor quality of work. I was lucky that my project manager was sharing same feelings like me. If you can not do it very well, better don’t do it. I didn’t want to risk thew way we are delivering product. Our current team harmony was amazing. Success was coming as a result of it. But, how all these things were happening ?
Remember one of the core value of Agile delivery;
- Individuals and interactions over processes and tools
Tools should be capable of managing product development and everything related to it. We should not purely rely on tools but they should be robust enough to answer all our needs. I am going to focus that core value now.
So here is Azure DevOps services that helped a lot during product delivery;
1) Azure Boards
Azure Boards is the service where you track your backlog items and categorize them based on on hierarchy, like Epic, Features, User Stories, Tasks and Bugs. Here is where we prepare our sprints and plan the items inside. Of course business users are always involved during this preparation. Transparency is very high. They are aware which items will be delivered at the end of each sprint.
Below screenshot from Azure DevOps documentations page;
A sample backlog items. It is not from my project but our items also similar.
First we grouped our items properly in the following hierarchy Epic->Feature->User Story. I am not going to explain one by one but you can think of breaking deliverables into smaller meaningful parts. Once we prepared the user stories and gave the story points based on complexity, i started creating tasks and assigning to the teammates. Here it makes very easy to monitor the workload for each member and see who is doing what. Discussions can be done freely on tasks or user stories. It makes very convenient for the team to communicate and collaborate. No one was sending email to each other and every discussion is going through the work items. I think this is very important for transparency and collaboration of each individuals in the team.
The best architectures, requirements, and designs emerge from self-organizing teams.
Burn-down charts are another good things that you can extract while your sprint is active. Basically it is telling you “bro you might not finish your user stories on time“. If you area dealing with a crowded project team and if you have so many user stories to deliver, this chart will help you on getting the idea of what is going on right now.
Another good thing is retrospectives. This is where you have the opportunity inspect team itself and create a plan for better sprint next time. This really requires attention, collaboration and honest opinion from each team member. Normally we are doing retrospective(or we are trying to do) after each sprint review and prior to next sprint planning. Is there anything wrong in the team ? Approach ? Working style ? Process? Tools ? Relationships? Everything can be highlighted related to previous sprint. To be honest, i found it very useful. Since usernames are hidden, you really don’t know who is writing what. This allows team mates to put more points during the meeting.
“Take extreme ownership of what you are doing. Your architecture, source code, project, career, mental health and your relationships will make things easier for you and everyone around you.”
2) Azure Repo
Here is the place where we can do version control of our source codes. Developers who are familiar with Git will pickup Azure Repo easily. Not only SAPUI5 codes, we can also push ABAP codes here as well to review what is going on that day. Thanks to Lars, we can use his abaplint for abap checks. Below is a dummy test for the ABAP codes.
Main advantage here coming with SAPUI5. Several developers are working at the same time with same application and it is getting harder to control the codebase. People have their own style of coding which might not be how we want. In Azure Repo, everyone is creating their branches and pushing their developments to that branch. Later on this changes are merged (or rejected) with our master branch which is ready to push to server.
“It’s not my fault that someone wrote a bad code that introduce a bad bug, but it is my responsibility”
Everyone in our team is using Visual Studio code and i can easily tell developing with VS Code is more-like obligatory in our team. We had previous UI5 developers trying to use local WebIDE but somehow they couldn’t keep it up with our team. I still don’t much believe a browser based development tool will be good choice to work with unless there is a strong justification. At least, anyone worked with nodejs, vue, angular or react previously won’t be preferring web-ide based development approach. For small scripts, i think browser can be easier to work with but i personally don’t prefer online ide for project implementation.
Our user guides are prepared in markdown format and pushed Azure Repo as well. Once it is pushed to Repo, Azure Pipelines are helping bundle and push to server automatically. With full text search functionality, it is very convenient for users to find anything they need in the user guide. I had to rename some links due to privacy but it is more-less looks like below. We prepared and automated building of user guides just from markdown files to a nice visual web interface. Comparing to a PDF user guides, a nicely prepared web page is always takes more attention and gives more comfort to business users. User guide module is embedded into the SAPUI5 application which is used for planning. Everything is in place.
3) Azure Pipeline
Azure Pipeline is the place where you can set up your CI/CD pipelines. Here is the place where we prepare our product for deployment and push to server.
Let me quickly explain what is it and why it is important for a software delivery.
Continuous Integration
It is all about pushing the code several times to the repository in a day, validating and listing the errors based on some testing tools. With this approach, a developer practices continuously integrating the source code with the rest of the team. Finally developer creates a pull request from their branch to merge the new changes with the master branch. This makes a parallel development across the team in a very safe mode.
As you can see below, developer never push code to the master branch. Each developer pushes changes to their own branch several times in a day. This makes very convenient from my side as well. Unwanted changes might not be pushed to server immediately but still keep there.
During merging the changes from developer branch to master branch, we have a setup on our pipeline to do some basic checking (i.e ESLint) and see if there is any issue related to coding standards in the source code.
Similar to the ABAP testing i pasted above, this helps us to tidy source code and keep it clean.
Continuous Delivery
Continuous delivery is extension of continuous integration. It is all about deploying latest changes from master branch to development server. For Non-SAP scenarios, you can deploy till production environment after some testing stage and name it “continuous deployment”. Due to internal governance, only thing we can do is deploying to development environment only. Below is the full flow four our environment;
Initially, majority of the steps were manual but now finally we have moved to fully automated CI/CD pipeline and it makes me extremely comfortable right now. Currently we have active 5 slightly huge SAPUI5 application (avg. 30 to 50 views) and 7 user guide fully deployed from Azure DevOps without any human interaction.
