The Agile School

Daily stand up meeting serves a very important role in agile teams. In a way they are the risk mitigation meeting. Team members talk about the risk for the iteration and overall product delivery. The need of a daily stand up for a new team and a matured team is different and hence the need for different rules for different teams. Teams who are starting the agile/scrum journey needs a lot of help. They might be new to agile or might be working together with each other for the first time. A structured well-defined set of rules will help them grow. For such teams the following rules are more than enough Daily Scrum Meeting Rules - http://www.theagileschool.com/2012/03/daily-scrum-meeting-rules.html   Daily scrum misconception, scrum meeting objectives and different stages of meeting http://www.theagileschool.com/2012/03/daily-scrum-misconception-scrum-meeting.html Only team members are “allowed” to speak and scrum master should be present to help the team. This rule im...

This is a good place to be. But if this happens a lot then you may have to look into commitments you are making. You may be committing less. Work on the next priority items in the backlog. Inform the Product owner. He/she may have some ideas also. You don't have to complete the additional "stories" you pull into the sprint  but if there are stories which you can complete then do it. Work on those Technical debts which you were pushing out- bug fixes, automation, performance enhancement, CI,CD etc. If needed , based on the input from Product owner, do some backlog refinement for upcoming sprints. Maybe its a good idea to learn something new which you might use in upcoming sprints. Do some cross team learning or work on some "new ideas". If there are multiple teams working on same product go and help other teams. They might do the same for your team in future when you need help and when you are behind in your schedule. 

I have seen this conflict in many organizations which are new to Scrum/Agile. Most of them are transitioning to agile methodologies from the traditional methods. It’s very difficult for that management to let go the power hierarchy. They still want one single neck to catch. They never believed in collective thinking. Rather than motivation , their believe in pressure to get the work done. Such dysfunctions exists in most of the organizations, scrum just exposes it. ScrumMaster doesn’t run the scrum. He/She should help build a team, bring out the leaders in every member of your team. ScrumMaster helps the team to self-organize so that they can move forward without the classic “delay” of waiting for decisions. ScrumMaster is not a person who can be used as a single neck to catch or blame. Scrum is a collective team approach. If it succeeds everyone succeeds if it fails everyone fails. ScrumMasters in such an environment have to do a critical job in the transition. You will have ...

Personally I feel that all in the team should understand all the stories which are going into the sprint. As soon as one task is finished he/she should take the next task in the backlog rather working on the “pet” or “my” areas. I usually hire developers who are willing to test also. If someone cannot understand the work done by the team even after repeated training then it is the job of HR and other functional managers to weed out such people. Testers are intelligent people.  It doesn’t helps if they are doing monkey testing of application or writing long test cases which even they don’t refer. IMHO they should be the business domain experts. They should provide value to the customers and business with their domain knowledge. Many times I have seen testers asking the developers about the requirements.  They limit their testing to the knowledge acquired in such a way. More than just ensuring that the features developed is bug free the team should strive for excellence by...

Scrum Log Jeff Sutherland: SCRUM: Keep Team Size Under 7! : Today, I wrote up an experience report on using SCRUM in large development teams for a new book that Craig Larman is writing. I described...