7 Tips for Improving the Daily Scrum

here's how i would handle this daily standup meeting nonsense

- sit; the standing up is a gimmick, and beside i have a medical condition
- what did i do? tried to avoid stupid managemnt gimmicks
- what will i do? continue to resist stupid managemnt gimicks
- what gets in the way? stupid managmeant gimmicks

scrum is just a new name for stupid micromanagemnt hurry up bs that leads to bad software; if i need to coordiante with team members, i'll do so, without all this nonsense

here's reality:
people have different schedules
not everybody is present every day for a lot of reasons
sometimes people are busy and dont want to break flow for some artifical manament gimmick meeting
meetings are a waste of time

the 'backlog', sprints', etc are all stupid managment gimmicks

managers hear about scrum and agile and they hear only one thing: quicker schedules

heres' the truth about reality:
quality takes time
quality cant be faked by stupid managment gimmicks

i quit my last job because they were forcing srcum down peoples' throats

1. Scrum meetings wait for no one.
This mean that if the scrum starts at 10am, it starts at 10am, not 10:02.
2. Standing helps facilitate a short meeting. I've heard of team even using a medicine ball. But really, that all standing really does for the meeting. We sit, mainly because we must speak into a speaker phone, to be heard clearly by offsite devs.
3. In our team, each member is responsible for his own daily scrum notes. Many times the notes are done before the scrum meetings. Have the notes ready for the meeting cuts down on the "duh, let me remember".

Good article!

Hi,

These are some great tips, and I am sorry to see one of the people commenting on this "left" their company because Scrum was, "Being shoved down their throats."

I see this happening a lot and wrote about the different ways of introducing Scrum -- the series starts at the following URL:

http://www.implementingscrum.com/blog/2007/09/30/bond-chicken-bond-in-a-...

I did a blog posting about the daily standup here:

http://www.implementingscrum.com/blog/2007/04/02/work-naked/

Hope these are some good references to start conversations on your teams!

Thank you.

- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com

The old-style programming environments (where Military Specs are not being used) provide way too much opportunity for developers to get lost in their own "techncial solution" only to find out that we missed the "busienss solution" (i.e. they elegently solved a problem that was not actually being asked of them to be solved!). So called "Managers" (Production, Requirments and Designers, etc) don't "know it all" all either. They tend to to speak in obtuse concepts and ideas that are often not grounded by clear communication. However, each party knows what the other does not!

Some of us know the businesss problem needing to be solved, and some of can technically solve any problem... Those who know the buinsess problem, do not "know it all", nor know it "all at once", nor are able to "communicate" it in an effective and "timely" manner to those who are charged wiht solving it. Those who can solve it, can only do so once they "understand" the problem. Since those who do understand the problem (some of the Managers and co-developers who "get it") "do not know it all / know it all at once / can communicate it", those who can solve the problem actually "can't" because they really do not understand. Understand?

This is part of the reason that we all went to school as kids for more than one day! We can't absorb enough information without iterative effort (communication, trial and error) to truly understand any degree of complexity. So, we meet regularly, together for short periods of time, to "iterate" around our understanding of the problem and the solution to the problem. Yes, it is an inconvenience (so are taxes and unemployment!) but if we pick a time to do so, then it minimizes the negative impact for everyone. The "silly management" things egg-timers and balls and standing up, are simply meant to keep the process moving forward (iteratively) without negatively impacting on productivity (personal and group) and really allowing the gurus to spin-ther-propelers on solving the "business problem" through their "technical skills". Knowing what everyone is doing ensures that we do not waste valuable "intellect" and "time" on doing the wrong thing, or worse, something that was already done by one of your colleages (like a Login or loggin function/routine/module....).

So, stretch your legs, get to the Scrum meeting on-time (I don't want to go either, BUT, I want to win too!), be prepared (have your notes and "coffee" with you), participate appropriately, the get back to work. Let's finish this damn project, 'cuase I've got some really interesting things to brong to you for the next Sprint!

Cheers!

Who have no background..... The previous response is more rah rah bs...."it's a group thing now!"

More of a circle jerk group thing methinks

We've had great success with Scrum in our environment.

I take offense at the idea that the only managers that are putting in Scrum are those with no technical experience looking for a marketing gimmick of sorts. I've been writing enterprise class software for a while now, and my overall experience (including data modeling and production dba work) goes back over a decade now.

I implemented Scrum with my team before I was the manager, because it was a great way for us to self organize. I still feel the same way, and our entire team reports that it's a successful way to manage our time.

The idea of it being a micromanagement tool only speaks to the complete lack of knowledge someone must have of Scrum. As the department manager, I stay out of the daily scrums and only coordinate resources that the team needs. I look for benchmarks and clear obstacles for the team; I wouldn't dream of asking for daily status updates.

All in all, I find Scrum to be an excellent methodology. It's flexible and promotes great teamwork. Also, it's not going to be as good on the first day as it will be a year later. Anytime you make a big shift in your development process, it's going to feel a little weird. But the akwardness of a paradigm shift is common no matter what changes you make, so it shouldn't be used as a judgement call against the particular paradigm.

Interesting article and interesting comments. I think to say that agile is a gimmick is shows a complete lack of understanding and indeed respect for the roles and accountabilities of those outside then immediate development team. Management try to understand and measure progress because they responsibility is to manage risk and budget. Agile is one solution to better manage risk and budget within a changing environment. It is not about the manager, it is not about the developer. It is about the business, stupid. IT systems are complex. Not because of the technology (that's the easy bit) but because of the people element. Agile is one solution to better manage complexity.

With all methodologies the important thing is to understanding the purpose of each technique. Stand-up can help the team understand dependencies and how to prioritise tasks in a better way than MS project can. But it take practice to get the information flowing and to avoid it being a status update. Burndown is about show progress to the team to help motivation. Sprints is about committing to delivering locked down scope earlier than if we had to wait 1 year for a specification to be delivered.

My recommendation to all is don't get hung up on Agile, SCRUM, XP, Waterfall etc. Think about what is not working well in your dev methodology and draw upon the raft of techniques to help solve these problem. Learn and adapt.

I have heard of folks leaving their jobs because they hated XP but never before have I heard someone speaking about leaving their jobs because of Scrum. XP pair programming day in and day out can be a real bind. I know I hated it.

My sense is that his company failed in the way his company adopted and implemented Scrum. I have found Scrum to be the most invigorating process if implemented correctly and creates a winning atmosphere and culture in the organization. Scrum is not about forcing anything down anyone's throats. Rather it's about a shared commitment where teams are left empowered to figure out the right way to do things.

A comment about "Quality takes time" ... No where does Scrum or Agile make any suggestion about cutting corners when it comes to quality. In fact it's quite the opposite. Agile best practices suggest that if you're not writing unit tests, not checking code in regularly and not documenting and peer reviewing your code then you need to start thinking about it.

Happy to debate this anytime!
Jack

My team includes in our estimates time for unit tests and we achieve close on 100% unit test coverage. These unit tests are executed automatically every time new code is checked in - and this happens frequently each day. This does not guarantee bug free code but I can assure you, our code is solid! I also highly recommend pairing dev's and qa. It's a great way to build quality in from the getgo! Pair programming is great but not all of the time like XP expects.

Scrum in my opinion offers real PRACTICAL way's to manage software projects in a way that builds trust between the development teams and business. Trust me I know what it's like to be on projects that don't go smoothly.

Two reasons I like Scrum

1. Rythm - I know we're producing an increment of value every two weeks
2. Transparency - I get to see exactly where my teams are ever minute of everyday

My teams love it. And we're building great software with more quality quicker than we ever did before.

Yea. Even we have a daily scrum meet and it has proved to be really effective now a days. It may not be a standup meet, but rest of the points mentioned are followed. Especially the sharp timing, 3 main questions to be answered, keeping the meet as short as possible, filling the sprint backlogs (done by the one who conducts it), ... We also extend our meeting if any of us has really a stopping issue --don't know whether we are rite in this. Thanks for the nice post. Came to know how others perform their scrum meets.

"Scrum is not about forcing anything down anyone's throats"

As is no other Agile approach. You know, this "People over Process" thing.