Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Agile processes and scrum

Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My team has been using agile processes in bits and pieces. xplanner, scrum, sprints. Most of my team members consider daily scrum a headache and make up points to report. This is clearly wrong, but management wants this to keep themselves updated on the status of the project. I know this sounds like a Dear Lovedoctor question, but does your book cover how not to go overboard with agile and customize it to the project and organization ?
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't speak for the book, but I still want to comment.

To me, this doesn't sound like "Agile going overboard", but like an Agile practice being *misused* for "non-Agile" purposes.

The purpose of the Daily Scrum (aka Stand Up Meeting) is *not* to provide status reports to the managers. It is to allow the team to *self-organize* and to raise *problems* that they need managements help for to solve.
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ravi,

Our book focuses on how to decide what will be valuable to customers and then deliver that value as rapidly as possible. This is done by complete teams that understand what is really important to customers and deliver value in minimum useful feature sets, as rapidly as possible.

All of the tools and practices that you hear about are not - necessarily - agile. What makes them agile is the repeated, reliable delivery of value by an engaged team. I suggest you look into Chapter 6 of our book, the chapter on people. It talks about what makes a team and how to think about engaging the team.

Think about a sporting team that plays enthusiastically after work or on weekends. How to you engage everyone on the team to want to play and do their best to win the game? Certainly not with status reports! You get the team in a huddle and have members give each other a pep talk on how the game is going and how to work together to win, and then everyone breaks from the huddle and gets on with the game. If that's now how the daily meetings work, then you may as well not hold them.

Mary Poppendieck
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic