Feedback on a small-scale BW project using Scrum - Part 4

[franois_gyngysi]

To get an understanding of Scrum, please refer to part 1 of this blog at Feedback on a small-scale BW project using Scrum - Part 1. To understand the project context & scope, the team structure, how the product backlog was built and the project planned, please refer to part 2 of this blog at Feedback on a small-scale BW project using Scrum - Part 2. To get feedback on the Scrum ceremonies (sprint planning, review, retrospective and daily scrum meetings) please refer to part 3 of this blog at Feedback on a small-scale BW project using Scrum - Part 3.

Introduction

The objective of the SAP BW project was to develop a set of operational and management reports for the Accounts Receivable department in the areas of billing, payment and dunning. It was decided to use Scrum. The whole thing is now in Production and is in use for more than a month.

This blog talks about the impact of Scrum on the way we handled our SAP BW development and provides some feedback on Scrum itself.

Impacts on BW development

Here are the main impacts:

1) Automate and speed up loading of test data
Because the solution is built incrementally, it is often necessary to modify the structure of InfoProviders or/and to modify update rules or transfer rules. Each time, test data must be reloaded into the InfoProviders. It is therefore worth the effort to setup properly InfoPackages and process chains (including drop index, and so on) to save a lot of time. We also optimised performance by, for example, activating number range buffering when necessary (we usually only do that in our Production system).

We have reviewed the notion of "done" accordingly (see part 2 of this blog) to include InfoPackages, process chains and number range buffering.

2) Test automation
Because things are built and modified incrementally, you may end up modifying something that has already been tested. Obviously, this could become costly (and boring) for the team if tests are performed manually each time. We started to work on test automation but didn't push it too far. We certainly have more work to do in this area.

For example, we used transaction RSCRM_BAPI to unload the content of InfoProviders into text files. By simply comparing text files, you can easily spot regressions. There are other means like InfoSpoke or even RS trace tool (see Automatic Query Test with RSTT - Webinar Presentation) but we haven't tried them.

3) System integration
In a typical SAP BW environment, development is completed and unit tested in the Development system. Transport request(s) are then released and imported into the QA system where acceptance testing takes place (after loading test data if needed).

In a classical (waterfall) project, all the transport requests are moved to QA before acceptance testing starts. This was not the case during our project. Several user stories are being worked on in parallel and one story can still be in development while another one is being tested in QA. In theory, this is not a problem if proper unit and acceptance tests are done and tests are automated. However, one must be well organised, especially if tests are not fully automated.

Scrum smorgasbord

There is a lot of literature out there describing the benefits of Scrum (googling "benefits of scrum" returns more than 1 million hits). Therefore, I decided to list (in no particular order) what struck me about Scrum:

• Value: the most valuable features (for the business) are developed first. I have seen the Product Owner drop some stories because he wanted more valuable stories to come first (this is quite effective when the project is time-bound). Obviously the Product Owner must be responsible (you're in trouble if your Product Owner is a madman!).
• Feedback: you get quick feedback (for example, after completing a story or after a sprint review). You learn and adapt quickly.
• Change: I found that change is well managed i.e. stories can be added, removed, etc. from the Product Backlog. At the same time, the list of stories to be completed during a sprint doesn't change once the sprint started.
• Transparency: everything is transparent and this brings tremendous benefits. For example, the cost of developing each user story (and even part of a story) is known to everybody. A conscious decision can be made to remove some of its features or scrap the story altogether based on costs versus benefits.
• Understanding: Scrum makes it easier for the team to have a shared and consistent understanding of the requirements / business needs as well as the solution being developed.
• Very little administration: some examples:
  • I have not prepared one PowerPoint slide after we launched the project! That's pretty cool, although I may loose my skill...
  • No need to write minutes from meetings. Decisions are made by the team who acts accordingly and usually immediately. If you wrote down things or drew diagrams on flip charts, just grab them and display them in the project team area.
  • No need to have elaborated Excel spreadsheet / application and numerous meetings to track bugs during testing as user stories are tested on an ongoing basis.
• Team: I found that the team "jelled" very quickly. After the first sprint retrospective, people realised that they could (and should!) talk to each other to improve things, express freely their ideas, etc. Also, the team delivers working software at the end of each sprint. This is good for the team spirit (sense of achievement).
• Daily meeting: this is a very effective way for the team to get in synch. It really gives rhythm to the project. We made it fun by having a small rugby ball that we passed around when someone wanted to speak!
• Documentation: you still produce documentation with Scrum but only what is needed. In our case, we paid a lot of attention to our architecture document (it basically describes data flows, data models, business rules, rules to build BEx queries, etc.). We also wrote technical documentation for all the data interfaces from external systems.
• Incremental design: knowing that everything is done incrementally i.e. you take one user story, design, develop and test it, I was really curious to see what kind of system design we would end up with at the end of the project. I am personally quite pleased with the result. I feel the design is simple and elegant given the complexity of the data (numerous data sources and business rules). I think this is where a method like Scrum is very powerful. Basically, you divide to conquer, learn from what you've done and adapt if needed using short cycle.
• Light framework: Scrum is a light framework and is very easy to understand. You obviously still need plenty of other skills like data modelling, coding, risks management, etc. to complete your project.
• Post-it: you'll become a Post-it expert...
• Logistic: make sure you have the right office space, a timer, planning poker cards, plenty of Post-its, markers, self-stick flipchart (these huge Post-Its are very useful), etc. Make sure logistic doesn't get in the way.
• Anticipate: don't forget to anticipate (e.g. anticipate the next sprint during the current sprint). It is quite easy to forget as you focus your attention on the current sprint.
• Big picture: working on individual stories, it is very easy to loose sight of the big picture. We simply displayed our global architecture on a wall in the project team area.
• Pace: at one point, we started to include more and more stories in our sprint (after all, the team was delivering). This was not good as people focused on delivering and took less time to talk to each other (for example, we found bugs that could have easily been avoided). So, keep the pace sustainable and give the team a break after a release is completed.
• Why: try to get a deeper understanding of Scrum i.e. understand the WHY and not simply the HOW. I found books like Managing the Design Factory from Donald G. Reinertsen quite useful in this respect. Again, Mike Cohn explains a lot of the "why" in his book Succeeding with Agile.
• Planning poker: used to estimate the size of stories. This is really fun, especially if you buy "real" planning poker cards!
• New light: Scrum introduces a new vocabulary (and therefore new concepts) and new practices. It forces people to think hard to build an understanding of these new concepts and practices. By doing so, people get a better understanding of their current practices.

Conclusion

Obviously, Scrum is not a magic bullet. You still need the right people (Product Owner, ScrumMaster, Team Members, etc.) with the right skills and attitude. Also, you need to have the right context to take advantage of Scrum (see part 1 of this blog at Feedback on a small-scale BW project using Scrum - Part 1 for more details).

In our case, Scrum worked very well. We delivered a good working solution. The end-users are happy about the result and the project was quite fun. We will definitively use it again on our next BW project if the context is right. There is more work to do, especially in the area of test automation. But, like everything in life, it's a journey, and the following words from T. S. Eliot come to my mind: we shall not cease from exploration. And the end of all our exploring will be to arrive where we started and know the place for the first time.

Toodle-oo or, as the French have it, au revoir.

Afterword

Should you have any questions on Agile/Scrum/Lean, do not hesitate to contact the Agile+ community on Google+ at http://plus.google.com/u/0/104017139996657183972/posts. Your questions will be forwared to the community if needed.