Research and Refine Research Topic

Agile_SAP_Introducing_Flexibility_Transparency_and..._----_Chapter_3_Project_Preparation.pdf

Home >Business & Finance homework help >Operations Management homework help >Research and Refine Research Topic

CHAPTER 3: PROJECT PREPARATION

Project preparation in an Agile project has only a few differences from the waterfall approach.

An initial attempt is made at identifying the Business Process Map, master data and organizational data, reports, interfaces, conversions, enhancements, forms and workflows (RICEFW).

Key differences arise in the following deliverables: infrastructure, knowledge transfer, work environment and task tracking. In addition, the project charter needs to clarify these differences to ensure understanding between customer and project.

Infrastructure On a typical SAP project, a sandbox is prepared for the start of blueprint, a development box is prepared for the start of realization, and a quality environment is delivered part way through realization (of course depending on project complexity, there can be parallel landscapes, Adobe® document servers, business intelligence, etc). In an Agile project, it is critical that the development instance and Solution Manager environment be ready at the start of the blueprint phase. During blueprint, you will need to demo to the client the standard SAP functionality. Many vendors have remote instances they can use to demo, however, most projects will need to configure a minimal, client based solution to help clarify requirements. Rather than lose this work in a sandbox environment, it makes sense to retain it in development and leverage it going forward. In addition,

Robson, Sean. Agile SAP : Introducing Flexibility, Transparency and Speed to SAP Implementations, IT Governance Ltd, 2013. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=1186297. Created from harrisburg-ebooks on 2020-11-11 04:38:29.

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Project Preparation

if Solution Manager is being used to store documentation, then it will need to be fully defined and ready by the start of blueprint.

Knowledge transfer Clients often ask to have some of their own resources placed on the project for knowledge transfer. The project will need to train these resources, so that they can become productive in the Agile project. If using Scrum, you’ll find it difficult to make them productive during a sprint. Scrum is crossfunctional, in that each team member is expected to be able to perform all tasks required in the sprint. This is an obvious challenge in configuration based projects, where someone requires years of experience to learn a module. Without formal SAP training, the best that can be achieved from a configuration, learning perspective is to identify Implementation Guide (IMG) activities that are low complexity, and assign those to the client, so that they gain a minimal productivity later in the project.

An Agile technique that is valuable for clients serious about configuration knowledge transfer is that of peer configuration. Mentor/apprentice relationships can be defined where an experienced configurator is paired with an inexperienced team member. Other combinations can be formed and unformed throughout the project, as required. These can include crossfunctional structures where a configurator, analyst and developer are paired to build end to end solutions that require a combination of configuration, functional specification and development. Another useful pairing is that of expert/expert pairings for members, either from the same module or different modules. Expert/expert pairings are useful when a solution is particularly complex,

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Project Preparation

or requires expertise from more than one module. Pairing is particularly useful when a team member is tired or stuck.

In planning the first few project iterations, the experience level of the team members must be factored in to the expected velocity. Non SAP team members will require a minimal time before becoming productive. A team’s performance will depend on the ratio of experienced to inexperienced team members.

Work environment Whether using Scrum or Kanban, it is critical to have an open, work environment. Koch refers to this as the “XP Facilities Strategy” and provides a sample layout for a project team room (Agile Software Development: Evaluating the Methods for Your Organization). Schwaber and Beedle provide more information on how to define the work environment (Agile Software Development with Scrum). On one project, I first set out to convince the client to restructure eight cubicles, by removing the interior, cubicle walls. I had emphasized that once we entered into integration testing, we would need an open environment to improve communication between testers. The client moved quickly and had our open space set up two months before the start of integration testing. It was the time spent in this open space that made me realize the true benefit of open, working environments. The positive and collaborative communication in this open space contrasted dramatically to that found in the neighboring cubicle, project space.

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Project Preparation

FEWER INTERRUPTIONS

At the same time that you want to have an open, work environment, we need to acknowledge that team members will sometimes need to get focused time, away from interruptions. Separate project rooms, or cubicles, can be defined and reserved for this purpose. I have also found that having team members block off agreed on time slots in their calendars, helps to control the interruptions of meetings.

Task tracking Not all Agile projects plan down to the task level. Scrum sprints plan to the task level, but the tasks are only known at the start of the sprint, and therefore are not practical for entry into a time, controlled system. Agile project plans focus on tracking deliverables (often referred to as features, or stories). It is acknowledged in Agile that finer plans often go awry due to task slippage, and resource leveling efforts at the granular task level fail when these predecessor tasks are late. To recover from slippage, you reassign team members, or shift around tasks, and the next thing you know you are back in MS Project replanning and redoing your resource leveling. Agile projects, therefore, are initially planned at high level, with details reaching out in shorter horizons. That is, the further out you plan, the less detailed your plan should be. This has implications to time control, in that resources will post time to higher level tasks.

One of the reasons you do not want time posted and planned at a detailed level in an Agile project, is that you want to build in flexibility that allows team members to work on a larger variety of tasks. Agile projects are about team members helping each other get work completed. If one team member is overloaded, then you want to have the

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Project Preparation

flexibility for other team members to help get that work package unstuck. Assigning and monitoring performance at the detailed task level, works to discourage collaboration, because it sends the message that each team member should worry only about getting their own work completed. It is also difficult for them to post time to another’s task if they are not assigned to it.

Another reason to not assign tasks at a detailed level is that such detailed plans often change. Agile projects refer to this management overhead as waste. Our goal is to deliver software, and not build in low value overhead. Spending hours doing resource leveling at the granular task level has little value to the client.

C op

yr ig

ht ©

2 01

3. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .