The Agile School

We all know about definition of done. It defines a set of conditions which should be satisfied by the feature team during the sprint execution for each Product Backlog Item worked by them. Unless all the conditions are met, the Product Backlog Item (PBI) or User Story cannot be marked as done. This can be called as the exit criteria for each PBI or user story. Usually apart from the team & Product Owner, the organization and other stakeholders also play a big part in creating them. A well-defined Definition of Done ensures that all the PBI delivered meets the standards. As team maturity improves this definition also evolves. For every exit criteria there should be an entry criteria. I have seen many lazy Product Owners (& scrum Teams) who don’t do a proper job of backlog grooming.  Because of this there will be lot of ambiguity about the upcoming PBI’s. There will be constant churn producing a lot of waste.  Sprint planning will end up in failure. A poorly pl...

Over a period of time retrospectives because a mundane task and teams starts skipping this, some of the patterns I have observed. Do a retrospective for 2-3 sprints Repeat the pattern of retrospectives without any value addition to the team  Not doing the retrospectives at all.  Before the question of skipping retrospectives (or not doing altogether) arises we have to understand what we are trying to accomplish with retrospectives. Agile methodology thrives on inspect and adapt process. We continuously observe and make changes in our process for continuous improvement. Retrospective is the key event which facilitates this. There is no benefit in doing retrospectives without understanding this core principle. There is no value in forcing this down the team if they don’t understand the core benefits. They should see some value for time they spend on this. It shouldn't be because the process dictates or because the scrum master wants it. If this is not happening then do a...

My agile coach forwarded this picture to me. This one of the best picture which explains the agile principles  We believe that we are delivering great software. and we don’t have to change because Our coding standards are great  We don’t have to improve our process  We don’t have to talk to other teams or people  Scrum Masters believe that they don't have to challenge the teams because they are delivering  and they don't have to improve anything We don’t have to  bring issues to management  We don’t have to suggest improvement ideas to others because it doesn't affect us. Some of these dialogues happen because we think that the equilibrium we see today will remain like that forever. Even if we don’t change anything inside  the outside  environment will change  and it will affect us badly. When such change comes we will be like dinosaurs, it will wipe us out. The beauty of agile is continuous improvement, if we bec...

this is a thought provoking article by   James Grenning Boy Scout Rule Applied to Every Day Coding http://www.renaissancesoftware.net/blog/archives/90

A story of Agile transformation @ salesforce.com 94 % Increase in feature requests delivered - 2007 v. 2006 38 % Increase in feature requests delivered per developer - 2007 v. 2006 Read the following slide for some more staggering data!!! http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation