The Agile School

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...

Scrum Log Jeff Sutherland: Story Points: Why are they better than hours? : Time to update this blog item as interesting new research has become available. The Standish Group has updated their findings on project...

I have a simple guideline for this Leave it to the teams - unsynchronized sprints Simple products with single teams working on it If you have a different independent products which rarely or doesn’t communicate with each other. Team will be more creative and it gives more flexibility. Because of all these unsynchronized releases there will be lot of churn so the management & PMO should use a lot of common sense in dealing with such cycles. Use synchronized sprints If you have a big product, with multiple teams working on it  If you a product portfolio of products/applications which communicates with each other  If you want to synchronize the release because of billing, reporting or any other similar reasons    Synchronization helps in large organization where we have to worry about lot of complexities. They will have a common reporting tool which can provide the correct view across all the teams. This helps in billing and other administrative jobs also. In

Generally there are 4 types of Scrum master 1.Technical - Battle hardened IT engineer who are promoted as SM 2.ProjectManager - SM : Traditional Project Manager who transitioned to SM ( really !!! ). This is a very tricky situation. The traditional PM has to do a lot of un-learning before he/she can become an SM. The PM shouldn’t be made an SM of the same team which he/she was managing. 3.Leader SM - The true leaders SM who love people and help them transform, They may or may not have technical or scrum knowledge. They help in the transition or improvement with their influence and leadership qualities. At any day I would like to work with such thought leaders 4.Scrum Process zealot - SM : Someone who has received a lot of SM training, who follows the rules very religiously to an extend that he/she never allows any innovation (Change) around these. We need such SM’s when the team is new or when going through a lot of volatility. I have personally seen one of my managers helpin

http://betterconf.com/alpha/agile2012.in/#myschedule:s7,s12,s24,s27,s30,s36,s48,s50,s51,s54,s64,s77,s81,s90,s93,s108,s123,s126,s139,s142,s146

You had a sprint demo and it failed miserably. A lot of stories were not fully tested. QA team is complaining that they don’t have any work during the first part of the sprint and they are overloaded during the last few days of the sprint. This looks very familiar. For months we will work casually and during the last two months of the release there will be lots of last minute changes and bug fixes. It will be a virtual hell with late night hours. People will be coming early and going late (Many don’t even go home, they stay at office). Now this looks familiar. We have seen this in many projects. Scrum promised that such thing won’t happen again but still we can see such mini waterfall in our sprints. If you are seeing such issues, you should have a retrospective immediately. A scrum team should be cross-functional. I will start with the following questions • Why can’t the developer’s cross verify each other’s work? • If testing is the bottleneck why can’t everyone help by tes

The idea of working in iterations producing potentially shippable software is very powerful. Scrum has some very simple rules to help achieve this. Scrum advocates that team size should be 7 (+/- 2). This works most of cases; almost all the software’s can be developed by teams of this size. One + One = Two Scrum Team = One Big product team What if I have to increase the team size? My project is complex and I need at least 12 people to deliver the product. Now this becomes interesting. In some cases I have seen such one big scrum team. Historical data has shown that productivity decreases as the team size increase from the optimum number of 7. So what should I do? Split the team into two. On what basis can I split the team? You can divide the teams into feature, service or subsystem teams; empower these teams to do their jobs. There could be some additional attributes to PBI to identify this linking. Team can work on such PBI from the common PBI list. So there could be te

Software which doesn’t works or which is full of bugs is of no value, whether you develop your code using waterfall or agile it doesn’t matter. One of the fundamental principles of agile world confirms this “Working software over comprehensive documentation”. Agile follows the principle of satisfying the customer through early and continuous delivery of valuable software. This fundamental guideline/principle itself emphasizes the importance of the quality. If I talk in scrum terms all the stakeholders are responsible of quality. The Product Owner creates the story, gets the necessary feedback from customers and discusses the acceptance criteria with the team. When the team starts working on these stories, all these quality/acceptance criteria are verified within the sprint (and after the sprint by the customer). Any deviation is noted at the earliest and necessary actions taken.