Skip to content

7 Tips for Improving the Daily Scrum

February 8, 2008 by Artem Marchenko


Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: "What did you do since the last meeting?", "What are you going to do until the next meeting?", "What impedes you from being more productive?". The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

1. Standup means stand up, no sitting, really.
Standing up on the daily Scrum draws attention to the brevity of the meeting. The purpose of the meeting is synchronization and no lengthy problem solving. Standing helps to remember that problem solving except the smallest one has to be taken offline - nobody likes to stand for an hour while two guys are arguing about the protocol implementation details.

2. Keep it short. 15 minutes max.

Everybody can spend 15 minutes a day on synchronizing with the others. Especially if it happens to be immediately before or right after the lunch time. Spending half an hour is a very different story. In my experience most of the time the 5-6 person teams are usually done in just 7-10 minutes.

3. Stand in front of the visual progress artifact.
Ideally in front of the task board together with the product and sprint backlog. Visuality and tangibility help discussing things. If task board is used, developers often like waving hands towards the card being currently discussed or even move the cards during this meeting

4. Everybody should be present.
One of the main reasons for meeting live is to utilize as wide communication bandwidth as possible - people are known to communicate more effectively, when meeting live. If particular team member is unable to participate, another person should report on behalf of his/her. If it is impossible for some reason, catch up later.

5. No typing.
Holding a laptop and making notes is power. The one who types immediately starts looking as a manager and often subconsciously starts writing what he thinks was meant, not what team members actually said. If you need notes, take micro-notes by hand.

6. Concentrate on the second and third question, not on the first one.
What's done is more of a context for the second and third questions. The real point is to figure out what's blocking the efficient work and who could help it.

7. If team talks too much to ScM, let him not too look at the team.
Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master.

Daily Scrum is a powerful tool, but as any other tool it is good, when you know what it's useful for and have some experience in using it. The above seven simple tips can be good starting points or reminders. However, every team knows best how to adjust its standups to serve them better. The important part is the goal, not the method.

Your experience
What feels important in your daily standup?
(Photo courtesy of improve it @ Flickr)

About the Author: As the Editor-in-Chief for AgileSoftwareDevelopment.com, Artem is charged with overseeing the direction for content, advertising, and the overall management of the site. Nowadays in his day life, Artem is a product manager in a global telecommunication company where he leads the development of a product developed in extremely distributed environment. Artem has been applying Agile and researching Agile since 2005. Contact Artem

Comments

scrum is overrated

February 9, 2008 by Anonymous (not verified), 6 years 25 weeks ago
Comment id: 1449

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

Stand-ups can work

February 9, 2008 by Anonymous (not verified), 6 years 25 weeks ago
Comment id: 1450

I can't speak to an entire scrum process, but we've seen real success from stand-ups. A quick little meeting is worth the minor cost when it gets everyone on the team in sync. Standing up makes the meeting shorter.

A few more tips for success.

February 10, 2008 by Nathan C (not verified), 6 years 24 weeks ago
Comment id: 1451

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!

Haha I like this comment

February 10, 2008 by Anonymous (not verified), 6 years 24 weeks ago
Comment id: 1452

Haha I like this comment :)
Actually you don't understand that you must have some management involved in software development. If I was to choose, I would pick Agile development & Scrum masters, much better than good old commander who talks nothing with you for 1 month and them comes and asks you to finish your work in 2 days.

Daily Stand-up Meetings

February 11, 2008 by Mike Vizdos (not verified), 6 years 24 weeks ago
Comment id: 1454

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

Thanks., same feeling. Scrum

February 29, 2008 by Anonymous (not verified), 6 years 22 weeks ago
Comment id: 1464

Thanks., same feeling. Scrum is for management people who do not have programming experience, not for programmer. Those people also need programmers to divide tasks and estimate time.

Here's a thought...

March 1, 2008 by Anonymous (not verified), 6 years 22 weeks ago
Comment id: 1465

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!

I hear you clearly....

March 1, 2008 by Anonymous (not verified), 6 years 22 weeks ago
Comment id: 1466

... you should leave this job too! Otherwise, you should be fired.

Get on the right "page" man, or go back to your COBOL roots and be part of the past.. You know, we no longer hand-write letters to Grandma, take a week to get across the Atlantic, carry three-pound cell phones or carry much cash. Step up, Man! Turn the page... "learn" how to participate in something that is better than you! Why be an island?

As for "Quality"... it actually takes "practice" = code<->test iterations. And you can't play the game alone anymore 'cause it's a team sport now!

Scrum is for weaklings

March 12, 2008 by Anonymous (not verified), 6 years 20 weeks ago
Comment id: 1484

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

Obviously you are not a team

April 8, 2008 by Anonymous (not verified), 6 years 16 weeks ago
Comment id: 1503

Obviously you are not a team player, or you happened to experience a poor Scrum project. For all your points, I can only agree that Quality takes time.

What you do not understand is, Scrum fixed the date, but it allowed the content/scope to move. As a programmer, we still deliver what we commit. In old days, when we realize we had under estimated the efforts, it normally ends up a project delay. Which make the management very upset. Now with Scrum, when we realize we under estimate the efforts, the scope just reduced. We are human and all of us only have 24 hours a day, which means there is a limit on how much we could deliver. Estimate being estimate, will not be 100% accurate unless we are the best fortune teller.

When I provide estimate, I give my best estimate to what I know at that point of time. Plus good buffer for UT. I will never compromise on quality of my own code, simply because that's where my reputation is tie with.

Scrum works

September 17, 2008 by Eric Kaufman (not verified), 5 years 45 weeks ago
Comment id: 1850

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.

Egos Can Crush Scrum, And Vice Versa

September 30, 2008 by alphadogg (not verified), 5 years 43 weeks ago
Comment id: 1883

@Comment #1449:

Looks like that first poster's "reality" can be summed up as: "Me. Me. Me. My medical condition. My schedule. My slow pace."

**cough** Prima Donna. **cough**

All I can imagine is that the team you left behind is probably better off without you.

When we instituted Scrum and other accountability techniques, we finally lost our local divas and lazy asses, and our ability to deliver value on-time went way up. Divas are a burden and demotivate good-but-humble team members. And, nothing shines a light on lazy roaches than having to stand up day after day and see them repeatedly say they are still trying to get "quality" in their still-unfinished tasks.

I will unabashedly say it: I love Scrum. Simple and cut-like-a-knife effective...

Like my title says: egos can crush Scrum deployments, but if it is held to strongly by the team, the reverse will happen to the betterment for all.

Be goal driven, not process driven

October 20, 2008 by Anonymous (not verified), 5 years 40 weeks ago
Comment id: 1916

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.

Scrum worked for me

October 21, 2008 by Muhammad Abdullah (not verified), 5 years 40 weeks ago
Comment id: 1929

Its a far better approach than any in my 6 years of experience.

Scrum meetings seemed to an overhead in the beginning but as we progressed it really took away a lot of pain from the offshoring model.

We had a Scrum meeting within the team and then I did the meeting with my client on daily basis. 30 minutes daily (sometimes even less) kept everyone on the same page and the product development turned out to be fantastic

We continue to add to our product through 2 week sprints and everyone in my team and at the client's end is happy and sure that there are no unrealistic assumptions being made.

The only challenge we have though is to keep our Sprints change proof. Once we get a handle on that, development will be sweeter!

Scrum overrated?

October 21, 2008 by Jack Milunsky (not verified), 5 years 40 weeks ago
Comment id: 1933

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.

Well discussed post.

November 27, 2008 by Praseo (not verified), 5 years 35 weeks ago
Comment id: 2052

I must say, on the verge of my project moving into Scrum, this post with its comments and reviews gave me a fair bit of idea of the pros and cons of Agile development.

Nice to know that, with a positive mindset, rhythm and transparency can be green flags to progress.

However, I have seen many agile projects failing to take off the way it was meant to, mainly because of ego clashes between employees. As I see, the experienced employees who move in for that extra pay, try to impose their ideas on others, and claim that their peers are sub-standard in terms of quality of coding and the approaches taken. In such cases, stand up meetings are like 'hang-them-up' meetings where the superiority complex of a few members suppress the creative thinking of the others.

This holds true for my team too, and obviously I am a prospective sufferer.
Praying to god, for a reason to come to office.

Scrum really works for us

November 28, 2008 by Sudarsan Srinivasan (not verified), 5 years 35 weeks ago
Comment id: 2061

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.

'hang-them-up' meetings

December 4, 2008 by Ilja Preuss (not verified), 5 years 34 weeks ago
Comment id: 2085

What is your Scrum Master doing about it?

"forcing anything down anyone's throats"

December 4, 2008 by Ilja Preuss (not verified), 5 years 34 weeks ago
Comment id: 2086

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

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

I was going to...but

February 6, 2009 by Anonymous (not verified), 5 years 25 weeks ago
Comment id: 2220

I was going to post a comment about the subject but I had to go to a scrum meeting

Re-think

July 30, 2009 by Abhijeet (not verified), 5 years 3 days ago
Comment id: 2918

I suspect the comment above is with prejudiced mind. I worked in both methods, traditional waterfall and agile, and I am liking working in Agile much better than before. The visibility, team participation and team work etc.

The mgmt which wants to put scrum down your throat does it without understanding complete Agile methodology. They probably takes whatever is best for them, but there should be someone telling them back that Scrum is not the magic wand but it's method to do the things differently and in better way.

It should be sensible balance than baseless decisions from mgmt side. You have to re-think on some of the points in your comment. For ex, Meetings are waste of time, yes that's why Scrums are not recommended for more than 15 min, we dont have want to have people gathering for 30 min, discussing the same but with time spent in getting the coffee or spending time in diverted discussions from the topic. So not all the things are the way you misunderstood.

My earlier comment is reply to first comment -

July 30, 2009 by Abhijeet (not verified), 5 years 3 days ago
Comment id: 2919

My earlier comment is reply to first comment for this post

Why is SCRUM capitalised?

October 7, 2009 by Anon (not verified), 4 years 42 weeks ago
Comment id: 3763

In my experience scrum halves productivity and doubles staff turnover.

Making people stand on the spot for extended periods is clearly a 'stress position' designed to recondition workers into a more submissive mindset.

The bullying, despotism and tyranny I have witnessed in scrum teams is completely unacceptable in the workplace.

I have been verbally and physically assaulted by scrum masters (and headmasters) and I have been slandered, libelled and backstabbed by these people when I try and speak out.

And the idea that scrum leads to better software is clearly a myth. The last scrum project I worked on produced a codebase that resembled a dog's dinner and the performance was so bad we needed about 10 layers of caching to prevent the application from being overloaded by just a handful of concurrent users.

Scrum is akin to bleeding the patient..

Scrum is just another process...but....

December 12, 2009 by Anonymous (not verified), 4 years 33 weeks ago
Comment id: 4347

It is just another software development process if it is followed without understanding its purpose. The practice of scrum applies to the whole organization and not only one team.
So scrum if not followed properly gets the doom on the project faster, else will deliver a software with required features faster. In both cases the stakeholders of the project are benefited as the expenditure is minimized.

Agile. My view....

January 3, 2010 by Anonymous (not verified), 4 years 30 weeks ago
Comment id: 4764

Here’s a thought, if you were on a dev team of friendly team members, and each of the team members were ‘best buddies’ with whom you’d would be happy hang out with after work, or go to lunch with. With each member having the same level of respect for each person, and everyone being helpful in the group; each person wanting to work to the same goal. This team would enjoy the meeting at 09:15 every day for 15-30 mins. Hey they’d probably meet during the course of the day as well, and meet up for lunch to talk coding, and the project.

But this type of Team is hard to find. In reality, some Team members will get on, some will have hidden agendas and motives, and some Team members will even stab each other in the back, and some may even try to sabotage the project. Oh yes and Egos, they seem very BIG in the IT World. This is the real world, and from my experience scrum is used to try to get management and developers to communicate, and for micro management of tasks and nothing more.

I have seen cases of scrum team members who do not comment at the scrums, but moan to the project sponsor, or developers line manager. This leads to team tension, upset, which leads to poor software quality, bad moral and eventually a failed project. Why, because they spend too much time talking or with their heads in the Project Backlog spreadsheet feeling fluffy, and not enough time in the code. Also this idea of Technical Debt, sounds to me like “We did not write it right first time, so need to revisit”.

Don’t get me wrong, I like the concept of Agile, and scrum, and TDD. But in my 18 months experience of agile in Banking and Utilities, it’s just a disguise for Micro management and Task Driven Development, where you need to estimate well or get shot. And watch your back.

Scrum can work, but it HAS to be Scrum!

February 20, 2010 by Broken Spirit (not verified), 4 years 23 weeks ago
Comment id: 5551

My company brought in Scrum and I was actually excited about it. But after a year and a half of it I've grown a bit jadded. Management promised us scrum, they demanded scrum, but they were unwilling to give us scrum.
We provided:
-backlogs
-tasks
-stand up meetings
-planning poker
-etc..

But when it came to management holding up their end of the bargin, they didn't.
-No co-located team, we still had to work with the same weak offshore teams members. That no matter how many times were asked would never grab a 'task', raise a 'impediment', etc..
-Estimates provided by the team were second guessed and rounded down
-Stand up meetings still digressed into 30-45 minute conversations, sometimes with the added bonus of finger pointing and blame laying
-When the velocity of the team became established we were given a finish date that was MONTHS earlier than would be possible given the established velocity. Told 'we can figure out a way'.

Do I still believe in Scrum? Yes!
Do I believe a company who thinks they can demand Scrum, but not support it are kidding themselves? Absolutely.

What about common sense?

March 19, 2010 by Exubery (not verified), 4 years 19 weeks ago
Comment id: 5854

I'm still puzzled about what you can achieve with Scrum, you can't achieve with common sense ... especially in a small to medium size organization.
Even reading through the posts here above, there's a lot of comments about the 15 minute scrum meeting as if that would make a difference.
If you're introducing Scrum doesn't that mean you're already too late, if you didn't make it with common sense, are you going to make it with Scrum?

Leaders are NOT Scrum Masters

May 27, 2010 by Aelaan (not verified), 4 years 9 weeks ago
Comment id: 6834

Most important piece a lot of companies are skipping is the real difference between a Scrum master and the project leader. Ideally the scrum master needs to be part of the development team - the project leader most of the time does NOT have the knowledge (although they sometimes claim they do). The project leader needs to add value to the scrum team by injecting the proper SME's to the project. It is clear that because of cut backs the project leaders are forced to become team members. However the chance for micromanagement is very much there and this is never a desired solution.

I don't think you'll fin

January 20, 2012 by Anonymous (not verified), 2 years 27 weeks ago
Comment id: 20784

I don't think you'll fin another job buddy... Probably you need to spend more time solving your gimmick live.

I'm confused why you think

March 2, 2012 by NOnn (not verified), 2 years 21 weeks ago
Comment id: 21110

I'm confused why you think agile isn't dramatically better given the two graphs you show. Assume just a single bug shows up in each phase (I won't get into why agile won't have phases. let's just take your data at face value). In the waterfall approach it appears you will have a bug during design. code. test. acceptance and production. Roughly looking at your graph it will cost 5 to fix the bug in design. 10 to fix in the one in code. 20 to fix the one in test. 50 to fix the one in acceptance and 100 to fix the one in production for a total of 185 cost units. b and you forfait sans engagement forfait illimite forfait sms illimite forfait mobile internet comparateur forfait bloque rio bouygues rio orange rio sfr rio bouygues rio virgin calcul imc portabilite

great job

March 9, 2012 by redes de proteção (not verified), 2 years 20 weeks ago
Comment id: 21316

The content provided in this blog is really satisfactory.I enjoyed reading this blog .keep doing posting on nice topic . I will look forward for the updates.

great job

March 9, 2012 by redes de proteção (not verified), 2 years 20 weeks ago
Comment id: 21317

really great post thanks for sharing it.

redes de proteção

Most important piece a lot of

March 10, 2012 by anymous (not verified), 2 years 20 weeks ago
Comment id: 21325

Most important piece a lot of companies are skipping is the real difference between a Scrum master and the project leader. Ideally the scrum master needs to be part of the development team - the project leader most of the time does NOT have the knowledge (although they sometimes claim they do). edpvdfisc ku osxhipwjm ea opckiwblm
The project leader needs to add value to the scrum team by injecting the proper SME's to the project. It is clear that because of cut backs the project leaders are forced to become team members. However the chance for micromanagement is very much there and this is never a desired solution.

Islamic Clothing For Women

March 31, 2012 by Samir Khan (not verified), 2 years 17 weeks ago
Comment id: 21553

hi..

I like your Blog,nice posting of relative subject daily standup scrum important of professional life thank for sharing advice i will do it.........i will back on your blog or sites

Textiles have an assortment

March 31, 2012 by santa (not verified), 2 years 17 weeks ago
Comment id: 21555

Textiles have an assortment of uses, the most common of which are for clothing and containers such as bags and baskets. In the household, they are used in carpeting, upholstered furnishings, window shades, towels, covering for tables, beds, and other flat surfaces, and in art. In the workplace, they are used in industrial and scientific processes such as filtering. Thanks.
Regards,
Winfield Estate

Fatastic Post

March 31, 2012 by tratamento para queda de cabelo (not verified), 2 years 17 weeks ago
Comment id: 21556

It's Really awesome post really like it
tratamento para queda de cabelo

Precise and to the point

May 9, 2012 by Agile Master (not verified), 2 years 12 weeks ago
Comment id: 21897

We have found these rules really useful and productive for our standup meetings. Its always easy to get into meetings for hours and get nothing but minutes out of it. Standup meetings are truly for developer and productivity. Keep the crap out of it.

Thanks for nice article.

I'm confused why you think

May 21, 2012 by JennyH (not verified), 2 years 10 weeks ago
Comment id: 22264

I'm confused why you think agile isn't dramatically better given the two graphs you show. Assume just a single bug shows up in each phase (I won't get into why agile won't have phases. let's just take your data at face value). In the waterfall approach it appears you will have a bug during design. code. test. acceptance and production. Roughly looking at your graph it will cost 5 to fix the bug in design. 10 to fix in the one in code. 20 to fix the one in test. 50 to fix the one in acceptance and 100 to fix the one in production for a total of 185 cost units. rio b and you

Nice Blog

May 24, 2012 by janefonda (not verified), 2 years 9 weeks ago
Comment id: 22515

I ran into this page mistakenly, surprisingly, this is a great website. Porterville Auction

Re:scrum is overrated

May 24, 2012 by Kishore (not verified), 2 years 9 weeks ago
Comment id: 22517

Weaklings like this anonymous coward prima dona are the first one to get fired when scrum is introduced in a company.

Nice Blog

May 26, 2012 by shahidkapoor (not verified), 2 years 9 weeks ago
Comment id: 22546

This is really a fascinating blog, lots of stuff that I can get into. One thing I just want to say is that your design is so perfect. beer keg prices

Nice post! This is a very

May 27, 2012 by Anonymous (not verified), 2 years 9 weeks ago
Comment id: 22568

Nice post! This is a very nice blog that I will definitively come back to more times this year! Thanks for informative post.
theo edge

rigidness

May 28, 2012 by Anonymouss (not verified), 2 years 9 weeks ago
Comment id: 22590

The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems. john detitta

rock

May 29, 2012 by UK SEO (not verified), 2 years 9 weeks ago
Comment id: 22610

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

Wow what a Great Information

May 30, 2012 by Anonymous (not verified), 2 years 9 weeks ago
Comment id: 22638

Wow what a Great Information about World Day its very nice informative post. thanks for the post. bad credit loans

great

May 31, 2012 by Anonymous2k (not verified), 2 years 8 weeks ago
Comment id: 22676

This is really a fascinating blog, lots of stuff that I can get into. One thing I just want to say is that your design is so perfect. building computer

good

May 31, 2012 by Anonymous2k (not verified), 2 years 8 weeks ago
Comment id: 22677

Maybe this can be a bit off subject but in any situation I've been surfing about your weblog and it appears truly neat. impassioned about your creating. I'm making a brand new weblog and hard-pressed to create it seem excellent and provide exceptional posts. I've found a great deal in your website and I appear forward to extra updates and can be back. Plumber Aurora CO

article

May 31, 2012 by Anonymous2k (not verified), 2 years 8 weeks ago
Comment id: 22678

Thanks for such a great post i will be listing this in my monthly newsletter. Many thanks and i hope to help spread the word freight factoring company

The purpose of this rigidness

May 31, 2012 by Anonymous2k (not verified), 2 years 8 weeks ago
Comment id: 22679

The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems Garden Ideas on a Budget

weak

May 31, 2012 by Anonymous2k (not verified), 2 years 8 weeks ago
Comment id: 22680

Weaklings like this anonymous coward prima dona are the first one to get fired when scrum is introduced in a company. commercial skylights

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com