Discipline versus dogma rond Scrum projecten

      No Comments on Discipline versus dogma rond Scrum projecten

In mijn verkenningen van projecten leiden en uitvoeren met Agile Scrum als reactie op de starre watervalaanpak hadden we al een waarschuwing van Ken Schwaber te pakken:

Scrum is like your mother-in-law. It’s constantly pointing out your shortcomings. The trick is that you’re supposed to learn from that feedback and fix your problems.

Discpline, vaardigheden en begrip

Jim Highsmith maakt in zijn boek Agile Project Management, aangehaald door Kevin Aguanno in Managing Agile Projects, First Edition (de boekbespreking zelf krijg je binnenkort van me) helder, dat er verschil is tussen discipline en formaliteit, vaardigheden en proces, begrip en documentatie:

Discipline is an internal quality of behavior; formality is an externally visible result. Many of the best developers are very disciplined in their actions without using formal methods or documents.

Skill is an internal quality of action, typically of a single person, while process is an externally declared agreement, usually between several people. Individuals operating at high levels of skill often cannot say what process they follow. Processes are most useful in coordinating the flow of work between people.

Understanding is an internal realization; documentation is external. Only a small part of what people know can be put into external documentation, and that small part takes a lot of time.

Process designers often forget these differences, thinking that enough formality will impart discipline, enough process will impart skill, and enough documentation will impart understanding. An agile project manager relies on discipline, skill, and understanding, while requiring less formality, process, and documentation. This allows the team to move and change directions faster.

Het gevaar door te schieten in dogma is groot. Bij een petje-op-petje-af spel in 2011 bij de presentatie van RUP op Maat werd gepolst naar de toepassing van Scrum door de aanwezigen. Het prioriteren van user stories was niet voldoende, pas bij prioriteren op basis van gekwantificeerde business value mocht je blijven staan.

De dood in de pot

Check ook onderstaande bijdragen van Capgemini collega Sander Hoogendoorn:

[slideshare id=12849698&doc=20120419-gidsagileanti-patterns-120508094644-phpapp01]

Scrum is namelijk niet perfect – don’t loose your head

Ja, Scrum strikt volgens het boekje heeft zo z’n tekortkomingen. Robert Cecel Martin, voor intimi Uncle Bob schreef er zelfs 7 stellingen over op. Volgens Mark Levison zul je maatwerk moeten toepassen om de volgende problemen te lijf te gaan.

  1. No Technical Practices: Scrum is a project management framework and doesn’t make any technical recommendations. Bob suggests that teams “need to borrow technical practices from some other method like XP. The suite of technical practices that should be added probably include: TDD, Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.”
  2. 30 Day Sprints are too long – most trainers now recommend 1-2 week sprints and the majority of teams settle at 2 weeks.
  3. Scrum Master sometimes turns into Project Manager: Some Scrum Masters use Scrum as a form of micro management and control. “This is not a problem with Scrum out of the box so much as it is a problem with the way scrum sometimes evolves. Perhaps it is related to the unfortunate use of the word “master”.”
  4. Certification in CSM: The Certificate that a Scrum Master, a trained CSM, holds means that on many teams only that person plays the role. Bob prefers the XP approach of rotating the Coach among members of the team.
  5. Insufficient Guidance Regarding the Product Backlog: “We’ve learned, over the years, that backlogs are hierarchical entities consisting of epics, themes, stories, etc. We’ve learned how to estimate them statistically. We’ve learned how and when to break the higher level entities down into lower level entities. Epics->Themes->Stories->Tasks.”
  6. Scrum carries an anti-management undercurrent: “Scrum over-emphasizes the role of the team as self-managing. Self-organizing and self-managing teams are a good thing. But there is a limit … Scrum does not describe this with enough balance.”
  7. Automated Testing: without high quality automated tests it is difficult to work in short cycles and know that stories are really done.
  8. Multiple Teams: Scrum and generic Agile have little to say about how to scale, many practitioners have ideas but there doesn’t seem to be broad consensus yet.

In de komende paar weken zal ik regelmatig boeken en denkbeelden over het benodigde maatwerk bij groter wordende projecten en toenemende complexiteit in de (organisatie) omgeving met je delen. Stay tuned.

Related articles