franois.gyngysi

    4 Posts

    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.

    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.

    Our third sprint (iteration) started two weeks ago. We now have been several times through the scrum ceremonies: sprint planning, sprint review, sprint retrospective and daily scrum meetings. Part 3 of this blog provides feedback on these meetings and discusses team synchronisation and specifications by example.

     

    Sprint planning meeting
    The sprint planning meeting takes place just before starting a new sprint. The objective of the meeting is to define in details the work to be done during the sprint. This is basically done by identifying the tasks required to complete each story (if needed, some tasks that are not linked to specific stories can be added).

    After reminding the whole team of the start and end date for the sprint, it is useful to review people's availability. This is important in our case because some team members are working part-time on the project and others are not available for a few days during monthly financial closing.

    During the meeting, we take each story in turn and identify all the tasks needed to complete the story and estimate the effort in "ideal" hours to complete each task. Each task is written on a Post-It and placed on a wall next to the story. Our first sprint planning meeting took more than 3 hours instead of the 90 minutes planned... There were two main reasons for that:

    • There was a lot of discussion about what the tasks should be and how to estimate the effort to complete them (for instance, how do you handle a task on which several people will work? Do you split it into several tasks and estimate each of those? Etc). It was a learning process and I must say that our second and especially our third sprint planning meetings went very smoothly. Typical tasks on our BW project are to write specifications by example, design, develop, move development to QA and load test data, do acceptance test, develop query, update architecture document, etc. We are actually more precise when describing tasks. For example, we explain what is being developed e.g. build the new sales InfoCube or load the client master data from the sales system.
    • We didn't prepare the meeting well enough. For instance, we had too much discussion during the meeting about what stories were about. We even did some planning poker to estimate some of the stories. We now anticipate a lot more during the current sprint by having team meetings where we discussed upcoming stories and groom the product backlog (new stories may be added and estimated, priorities may have changed, etc.).

     

    After defining and estimating the tasks for each story, I ask the team if they feel comfortable handling the next one in the coming sprint. We stop adding stories when the team says no. That's why it is important to know people's availability to be realistic about what the team can deliver. You also need to make sure that you have a buffer to handle extra work during the sprint (you need to anticipate the next sprint during the current sprint and this generates work), to cover for uncertainty in estimates (tasks), etc. There are various techniques to estimate the size of this buffer. Following Claude Aubry's recommendation, I make sure we have at least a 30% buffer.

    Last but not least, you need to define a goal for the sprint. In our case, the goal of the first sprint was to harmonise cash and credit customers (not very sexy or understandable but it made sense to the team).

    As usual, these topics are well covered by Mike Cohn in his book Agile Estimating and Planning and, for French speaking people, by Claude Aubry in his book Scrum (I swear I do not get any royalties from these people).

     

    Team synchronisation
    Other team(s) involved in the project may not use Scrum (for instance, we have a dedicated team in charge of ETL, EAI, etc.). It is therefore important to synchronise their work. In such cases, you may need to write specifications (as complete as possible because iterating may not be an easily accepted option), ask for a delivery date and plan accordingly. All of that needs to be anticipated.

     

    Specifications by example
    In terms of acceptance testing, we decided to write specifications by example for each story (see Bridging the communication gap by Gojko Adzic at http://www.acceptancetesting.info/the-book/). These specifications by example must be available before the development starts and act as specifications for the developer.

    For a report, the specification by example includes the list of information and calculations needed on the report (e.g. customer code and name, turnover, ageing, etc.) and the expected results based on the data available in our QA environments (where the reports are developed). We found this to be quite effective because it forces end-users & business analysts to really think things through instead of building theoretical examples. This is also a very good communication tool between the team members. And last but not least, the examples (or a subset) can be used by the developer to unit test his/her work.

     

    Daily Scrum
    Every morning, the team stands up in front of the "task board" where the tasks for each story are shown. Each team member answers three questions: what did you do yesterday, what will you do today and are you encountering any obstacle. Accordingly, tasks (Post-Its) are moved around the task board and the remaining effort (in hours) to complete each task is adjusted. The meeting lasts 15 minutes. Obviously, discussion will take place between team members. The ScrumMaster must make sure that people do not start lengthy discussions (if needed, these discussions should take place after the daily scrum). I must say that I let sometimes the meeting run a bit longer to let people share information but I keep it under control.

     

    image

    Task board at the end of sprint 2 (most tasks are completed). The first column contains the stories (green Post-Its). The next three columns contain tasks depending on their status (To Do, In Progress, Done).

    At the end of each daily scrum, the sprint burn-down chart (remaining effort in hours) is updated.

    image

    Sprint 2 burn-down chart (end of sprint)

     

    The whole team must attend the daily scrum meeting in order to properly synchronise the work of the team. The presence of the Product Owner is crucial because he gives direction and answers questions (during and after the daily scrum if needed). Hopefully, we have a very dedicated Product Owner (I think he hasn't missed one daily scrum except a few days ago when it snowed like hell!).

     

    Sprint review
    The objective of the sprint review is to present to the world what the team has accomplished during the sprint. We remind everybody of the goal of the sprint, the stories included in the sprint (planned versus actually completed and explain any discrepancy), explain the system architecture (data flows, InfoCubes, important business rules, etc.) and demo the system (basically, we show the various reports that have been developed). We also answer questions and explain what the team plans to do in the next sprints. It takes us one hour to cover these topics.

     

    Sprint retrospective
    The objective of the sprint retrospective is to reflect and talk about what happened during the sprint in order to improve, to avoid doing the same mistakes again and to share different points of view. The meeting lasts one hour. We take roughly half an hour to review what happened during the sprint, what went well, obstacles encountered, etc. A very useful way to do this is to draw a timeline and start talking about the first story handled by the team. This will kick-start the conversation and everything will flow. Problems and solutions will surface during the conversation.

    The next step is to ask everybody to jot down their ideas for improvements on Post-Its (ask for 4 or 5 ideas per person). In turn, each team member goes to the board where ideas are grouped together. After the meeting, we add the improvements into the product backlog to keep track of them.

     

    image

    Sprint 1 retrospective – Timeline at the top. Ideas for improvements are grouped together.

     

    This is a very important meeting because it really gives the team the opportunity to improve on a regular basis while the project is going on. For me, this is a very good innovation brought by Scrum (we do something similar today but usually at the end of a project which is a bit late when you think about it).

    Improvements can be really simple things like, during the daily scrum, writing down the name of the person in charge of a task on the associated Post-It to more important improvements like anticipating the next sprint.

     

    In the next blog I will provide feedback on Scrum's benefits, challenges, impacts on BW developments, etc.

     

    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.

    This blog provides feedback on an agile methodology called Scrum applied to a SAP BW project. Part 2 of the blog explains the project context & scope, the team structure, how we built the product backlog and planned the project. This blog assumes that you have a basic understanding of Scrum. If needed, please refer to part 1 of this blog at Feedback on a small-scale BW project using Scrum - Part 1.

     

    Project context and scope
    The objective of the SAP BW project was to develop a set of operational and management reports for the Accounts Receivable (A/R) department in the areas of billing, payment and dunning. The reporting is quite complex because data comes from SAP ECC but also from several operational systems where some of the customer billing is done.

    Because of this complexity, the A/R department has historically developed several MS Access databases to load and harmonise the data from these various sources. For various reasons (strategic and operational), it was decided to use SAP BW instead.

    More than a year ago, the business analysts group within our accounting department wrote detailed specifications for all the reports needed by the A/R department. However, the project was delayed as priorities changed. It was now time to start again but using Scrum.

     

    The team
    The team included the manager of the A/R department acting as the product owner (he's the one with the vision of the product to be developed), one ScrumMaster (myself), two BW analysts and one business analyst (part-time). It was also decided that two accountants would join the project team (part-time) before the first sprint started and would act as key users once the project went live (key users train end-users, provide first level support, etc.).

     

    The product backlog
    The first step was to build the product backlog as user stories. Stories are simple descriptions of the product features from the product owner's perspective and are generally written using the following template: As a <user role> I want <goal> so that <reason>.  More information on user stories can be found at:

    http://www.mountaingoatsoftware.com/topics/user-stories

    http://www.mountaingoatsoftware.com/books/2-user-stories-applied-for-agile-software-development

     

    We initially populated the product backlog by creating one story per report based on the specifications already written. For example, we created a story called individual cash customer dunning report with the following description: as an A/R accountant I want to list all the bookings that are not totally paid by the customers and whose departure date are in the past so that I can send them payment reminders.

    We held several workshops with the team over a two weeks period to review and get an understanding of the various stories. We also identified all the interfaces needed to bring external data into SAP BW and created one story for each of those.

    Stories are written on index card or post-it. However, we quickly found that we couldn't remember, from one workshop to another, what was exactly behind each story (at the beginning, you really need to view the existing report or a mock-up to remember). Therefore, we decided to move the product backlog in electronic format (a simple Excel spreadsheet) and added hyperlinks toward existing reports or mock-ups (usually Excel files). We also added notes and comments captured during the workshops. In this way, we could quickly open the existing report and remember what was on it, review notes, etc.

     

    What "done" means
    Before estimating & planning, the team must define what "done" means. For instance, we decided that a story was done (completed) when the following conditions were met:

    • Unit tests completed
    • Development moved to QA
    • Test data loaded in QA (needed for acceptance test)
    • Acceptance test completed
    • Technical documentation updated (if relevant for the story)

     

    We did the same for sprint and release. For example, we decided that our architecture document should be up-to-date at the end of each sprint.   Defining the meaning of "done" is important for two reasons. First of all, you make sure that everything is transparent i.e. everybody knows what you mean when you say a story is done. You also ensure that you won't forget anything when estimating the size of each story. For example, loading test data in the QA environment could be time-consuming for the team.

     

    Estimating
    Once the product backlog is ready and stories are sorted by priority (i.e. the most important stories come first in the product backlog) you can estimate the size of each story in points i.e. the effort it takes to complete the story. This is done through a session of planning poker. See http://www.mountaingoatsoftware.com/topics/planning-poker.

    Basically, we chose an average story and gave it 5 points. That was our reference. We then handled each story in turn starting at the top of the product backlog. For each story, we took up to 2 minutes to discuss it (I bought a very simple and inexpensive cooking timer from my local supermarket to keep things under control or at least try to, because this was not always easy!).

    Each participant had a set of planning poker cards and chose the one representing his/her estimate (all cards must be revealed at the same time). If there were differences between estimates, we took another 2 minutes to discuss these differences (again, sometimes this took longer).

    At this stage, the team was already doing some high-level design. For example, we had discussions about creating new InfoCube or how we would bring data from ECC or other external system. Also, don't forget about what "done" means. As said earlier, it could take time for the team to bring test data into the QA environment. This should be taken into account when estimating the size of a story.

    It is very important to have the whole team in the room (including the product owner) because questions & answers flow between the participants. Most of the time, we found that we didn't need more than 2 rounds of planning poker to reach an agreement.

    A word of warning: don't make each planning session too long (we made that mistake) because exhausted people don't pay attention anymore (you start loosing people after 90 minutes).

     

    Story points versus man-days
    *At the beginning of our first planning session, we had discussions about using story points versus man-days to estimate the size of our stories. Some team members, especially those with a technical background, were initially reluctant to use story points.

    However, there are several good reasons for using points rather than man-days (this topic is very well covered by Mike Cohn in his book Agile Estimating and Planning). For me, the most important reason is that it is faster and easier to have an agreement between team members. For example, two developers may provide different man-days estimates for the same story (e.g. a report) because one is more familiar than the other with the tool being used (e.g. the BEx Query Designer). With points, you avoid this kind of potentially endless discussions.

    I found that all the team members became comfortable with points after the first planning session.

     

    Release planning
    *To build the project plan, you need to know the length of each sprint and the velocity of the team i.e. the number of story points the team can handle during one sprint.   

    We choose a sprint length of 3 weeks for two main reasons. First, we had some part-time team members and we thought that the fixed cost of iterating (e.g. time spent in recurring meetings) was too high compared to the time people would be available during the sprint. The second reason is that we needed to juggle around monthly financial closing (some team members wouldn't be available for several days).  

    We then had to determine the team velocity. This can be estimated but we decided to start the first sprint and see how many points the team would be able to deal with. We made that decision because the project was time-bound (the BW resources were only available for a few months) and the team would deliver whatever it could. This is obviously not a very satisfactory answer from a planning perspective; however, we knew more or less what we would deliver based on our experience.   

    Here is our initial plan with a buffer (Claude Aubry in his book Scrum recommends a 25% buffer i.e. 15% to handle additional feature / stories / bugs and 10% to reflect uncertainty in estimates):

     

    release2.png

    Again, all these topics are well covered by Mike Cohn in his book Agile Estimating and Planning.


    In the next blogs, I will cover our first iteration, including sprint planning, daily scrum, sprint review and retrospective and various topics like specifications by example and the impacts of Scrum on the way we handled BW development.

     

    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.

    Introduction
    A few months ago I got slightly frustrated with the way we handled an ECC / BW project for our Credit Control & Accounts Receivable departments. Although we delivered the goods, I felt the process was protracted. Several groups were involved: the end-users from two departments, the business analysts' team (in charge of capturing the business requirements), the ECC team, the ABAP development team and the BW team (I am in charge of the latter).

    Basically, there were a lot of documentation and long formal exchanges between the various teams. Even with plenty of meetings, this led to misunderstandings that were only discovered very late in the process. I decided to see if there was a way of improving the process and ended up looking at agile methodologies and more particularly at Scrum.

     

    Manifesto for Agile Software Development
    In order to really understand what agile practitioners mean by agile, it is worth reading the Agile Manifesto below (available at http://agilemanifesto.org/):

    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

     

    That is, while there is value in the items on the right, we value the items on the left more.

     

    Principles behind the Agile Manifesto
    We follow these principles:

    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    • Business people and developers must work together daily throughout the project.
    • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    • Working software is the primary measure of progress.
    • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    • Continuous attention to technical excellence and good design enhances agility.
    • Simplicity--the art of maximizing the amount of work not done--is essential.
    • The best architectures, requirements, and designs emerge from self-organizing teams.
    • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

     

    What is Scrum?
    If you want a really quick overview, go to http://www.scrumalliance.org/pages/what_is_scrum. A good Introduction to Scrum is available at http://www.mountaingoatsoftware.com/system/asset/file/58/RedistributableIntroToScrum.ppt (the document is available in various languages at http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum). If you want a very detailed explanation (more than one hundred pages!), please read http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf.

    I read a lot of stuff on the Internet but still had plenty of questions. Just to name a few: how to plan the overall project? How to manage the user requirements? How to apply Scrum to a SAP BW project? Would Scrum work with a data warehouse project? How to manage a team with part-time people? How to move forward? How to choose a project? Etc.

    I found the following three books very useful to answer my questions:

    • Cohn, Mike Succeeding with Agile
    • Cohn, Mike Agile Estimating and Planning
    • Aubry, Claude Scrum (this book is in French)

     

    Moving forward
    Convinced that Scrum was worth trying, I put a few PowerPoint slides together (I am a manager after all ;-)) to explain the value of Scrum. On the first slide, I explained agile software development and listed the values and principles of the Agile Manifesto. I then added and repackaged the slides from the Introduction to Scrum presentation listed above (not forgetting due credits!). I also added slides on release planning as I felt this was important.

    I exchanged a lot with my fellow IT managers to get feedback and criticisms about my presentation and Scrum itself. This led to very interesting and constructive discussions and forced me to further investigate some points.

     

    Choosing the right project
    I also thought that our next SAP BW project was the right candidate to use Scrum. As shown by Claude Aubry in his book Scrum, I prepared the graph below to prove the point. The closer to the centre, the easier it is to apply Scrum (or the more relevant Scrum is).

    Project small.PNG

     

    Here is a quick explanation of each dimension:

    • Team Size: the best size for a Scrum team is 7 +/- 2 people (Scrum can scale by having multiple Scrum teams). We were pretty good here because I estimated our team would be made of 5 people.
    • Engineering Capability: although our BW team is experienced and pretty good at its job, I considered that we had little experience with software engineering practices like test-driven development or test automation. I actually didn't know how we could implement these practices with SAP BW!
    • Geographical Dispersion: I thought it would not be difficult to have our business analyst and end-users in the same office as the BW team. So we were pretty good here.
    • Level of change: Scrum is very good at handling changing requirements and shifting priorities. As I didn't expect a lot of changes I scored "low" on this dimension (it doesn't mean that Scrum is not useful if the level of change is low).
    • Criticality (in case of failure): although important to our business people, our BW project was not critical (i.e. we are not talking about building software for a nuclear power plant). If the project is critical, you may have to provide a lot more documentation and be a lot more formal and you will therefore benefit less from Scrum.
    • Deployment: we only have one instance of SAP BW so this is less risky than making an application available for download to millions of Internet users.
    • System Age: the older the system, the more difficult (or impossible) it is to use software engineering practices like test-driven development or test automation.
    • Architecture Stability: our BW architecture is stable so we were good on this dimension (no risk).
    • Economic Model: we scored low on this dimension because I knew we would only use internal resources on our SAP BW project. On the other hand, it could be more difficult if you have to negotiate a fixed price Scrum contract with a supplier and you've never done that before (there are actually some ways of doing it).
    • Governance: I scored complex on this dimension because we typically have steering committees, core team meetings, and so on, to manage our projects and my experience was that each team could be defensive about its prerogatives.


    Coming out
    I gave the presentation to senior management on the IT and business sides and got very positive response. I found the values and principles of the Agile Manifesto to be of real interest to senior management. Also, everybody felt safe about applying Scrum to the chosen SAP BW project.

    I then presented Scrum to the BW team. We got into really interesting and sometimes intense discussions! For instance, what amount of design should we do up front. As Mike Cohn says "the difference on a Scrum project is not that intentional design is thrown out, but that it's done incrementally". Was this going to work on SAP BW project? Another interesting discussion took place regarding user stories (the index cards or Post-It used to capture business requirements). Would that be enough to drive the development?

    Finally, I presented Scrum to more stakeholders (managers, business analysts, etc.). Everybody was ready to give it a go. We decided to launch the project. This will be covered in my next blog.

     

    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.