Recent site activity

Bootcamp El Gouna 2010


The bootcamp and workshop was held in El Gouna, Egypt (Arabic: الجونة, the lagoonMay 2010.

Introduction

This page documents the approach which and how software processes using the Scrum framework should be performed when developing software products in our company. The bootcamp builds on the workshop held in Mallorca, Spain in 2008 and the experience gathered using Scrum in the projects developed at bbv Software Services from 2006 to 2010.



Lessons Learned

The initial set of lessons learned was documented in the last workshop under assumptions.

Roles

It is of tremendous importance to clearly state the roles in Scrum and explain them with traditional terms to the company management
  • Product owner is the product manager
    • Make sure the team has a product owner who is empowered, available, committed and qualified
    • Use a vision to describe the goal you are aiming for
    • Collaboratively groom the product backlog and weed out items that are not essential to bring the product to life
    • Focus on building a product with minimum functionality and release product increments early and frequently
    • Carry out release planning to guide the project proactively involving theScrum team and the stakeholders
  • Scrum master is the team leader and the project leader. But it is a servant and coach.
  • The team takes over responsibility and the management control activities.
The product owner is the one and only person responsible for managing the product backlog and ensuring the value of the work the team performs. This person maintains the product backlog and ensures that it is visible to everyone. [Ken Schwaber, Scrum Guide]

Until recently, I viewed this relationship between product management and development as one of many changes in a Scrum adoption. I now view it as the most critical change, the lynchpin of the adoption. If this change is successful, the use of Scrum will persist and benefits will increase. If the change isn't successful, the use of Scrum in your enterprise might well unravel. [Ken Schwaber, The enterprise and Scrum]

Management Support

In order to sustain adaptive planning with Scrum, it becomes important that the culture of the organization understands and respects change. Organizations, where teams go agile but the management thinking does not, run a risk of quickly losing all the benefits from Agile and becoming worse than they were before. Some of the things that managements need to do include

  • Provide long term vision, direction and priorities
  • Trust and motivate their teams
  • Focus on addition of business value
  • Encourage teams to deliver internal quality, act on technical debt, enhance engineering practices
  • Ensure continuous flow of work
  • Minimize non-work related disruptions
  • Facilitate removal of impediments outside the control of teams
  • Support the process of learning, inspecting and adapting
  • Communicate

Scrum Anti-Patterns

  • Scrum master dispatches tasks to members of the team and destroy the self organizing team.
  • External managers disturb the sprint by changing the priorities and dispatching new activities to the team.
  • No review and demonstration meetings are held.
  • No retrospective are held or no impediment list is defined.
  • Daily standup meeting are not held on a daily basis.
  • Product owner has no competence to decide or do not take his job seriously enough.
  • No commitment exists between the team and the product owner
  • The members of the team are not trained  in Scrum and TDD. We believe you can develop software with Scrum only if you are also using test driven development approach.
  • Meetings are not time boxed
  • Stories define activities and not user features with business value
  • Management sends a few people to a Scrum certification and hopes that all projects will be successful.

Scrum Data Model

Scrum artifacts in the area of requirements gathering and management can be modeled as below.


We still believe that a backlog item should have functional and non-functional requirements associated to it. This approach is mandatory for applications developed in regulatory environments such as elevator controls or medicinal devices.

We are convinced that acceptance testing should be fully automated. This approach is the only one supporting full regression testing at the end of each sprint.

The feature concept is currently unclear. Do we map it to themes in Scrum or do we build a bridge to application portfolio management and use their feature classification.

References

[1] Agile Estimating and Planning, Mike Cohn, Prentice Hall 2006 
[2] Scaling Lean & Agile Development, Craig Larman and Bas Vodde, Addison Wesley 2009
[3] Clean Code: A handbook of Agile Software Craftsmanship, Robert C. Martin, Prentice Hall 2009


back to  Agile Methods or Home 
Comments