3 Veelgehoorde Misvattingen over Lean en Scrum

Krijg jij met regelmaat aantal vragen over de relatie tussen Lean en Scrum?, Hier wordt in dit blog aandacht aan besteed door de Agile Scrum Group. Deze vragen zijn bestempeld als in de volgende misvattingen:

  • Lean is voor processen en Scrum is voor projecten
  • Lean is voor bestaande zaken en Scrum is voor innovatie
  • We hadden eerst Lean, nu gaan we scrummen
  • Lean en Scrum moeten bottom-up ontstaan
  • Na een theorie training bén je Scrum Master of Yellow/ Green/ Orange Belt
  • Je moet kiezen als organisatie tussen de Lean en agile filosofie

Lees het volledige artikel hier: https://agilescrumgroup.nl/misvattingen-lean-scrum/

Six Agile Product Development Myths – Busted

In this article Mike Cohn busts six agile product development myths:

  • Myth #1: Isn’t Agile Just for Software Development?
  • Myth #2: Is It True That Managers Have No Role in Agile?
  • Myth #3: Can’t Stakeholders Introduce Change Whenever They Want?
  • Myth #4: Doesn’t Everyone Need to Be a Generalist on an Agile Team?
  • Myth #5: I’ve Heard that Agile Teams Don’t (or Can’t) Plan.
  • Myth #6: Don’t Agile Teams Create Products with No Architectural Plan?

Find the complete article here: https://www.mountaingoatsoftware.com/blog/six-agile-product-development-myths-busted

Working with Stakeholders Who Won’t Take No for an Answer

Sign up to receive weekly tips like the one below from Mike Cohn to Help You Succeed with Agile here: https://www.mountaingoatsoftware.com/email-tips

Do your stakeholders have a hard time accepting a “no” from the team? Or put another way, does your team have a hard time telling the stakeholders that what they want is impossible? If the answer to either of those questions is yes, you are not alone.

I’ve found two techniques useful in communicating a “no” so that stakeholders listen and understand.

First, the team should establish a track record of planning projects accurately and meeting most commitments.

You don’t need to be perfect, but if a team meets most of its commitments, the business is more likely to listen when the team says something is impossible.

Second, when telling a stakeholder that a proposed date cannot be achieved, offer alternatives. For example,

  • By what date could the functionality be delivered?
  • Are there especially challenging requirements that could be relaxed to meet the deadline?
  • What could be done to make the date feasible? More people? Stop using the team for second-level support?

Stakeholders often want more than can be delivered by some date. This shouldn’t be the team’s problem alone.

Wanting more than can be delivered must be viewed as a shared problem. A solution can only be found by the business and team working together.

When stakeholders trust the team’s commitment and work together with team members to find solutions, they all succeed with agile.