Agile Myths
 

Myth 1. Stand-up is a status meeting
Reality – The Daily standup is a Planning Meeting. It promotes Collaboration, Self-Organization, Enables inspection and Adaptation, Focus on achieving the outcome.

Myth 2. Pair programming decreases the productivity
Reality – The pair programming increases the productivity in majority of the cases if done in right way.

Myth 3. Agile doesn’t need project manager
Reality – The Scrum Master plays a role of a project manager.

Myth 4. Agile is another word for Scrum.
Reality – The Scrum is one of the Agile framework. There are many more like Kanban, XP, FDD etc.

Myth 5. Agile is faster than Waterfall
Agile is less about delivering software faster, and more about delivering value faster.

Myth 6. Agile means no documentation
Agile doesn’t do documentation for documentation’s sake. Documentation is like any other deliverable on an Agile project. It gets estimated, and prioritized like any other user story.

Myth 7. We’re a self-organizing Agile team, so we can do anything we want
Reality – The core principles are not allowed to be tailored. It is a lightweight process while the core practices are expected to be followed.

Myth 8. Agile is a silver bullet
Reality – The projects done in Agile do fail. It cannot be an excuse to stop thinking. Agile promotes fail faster philosophy so that one can learn from it.

Myth 9. The story points can be exactly translated to hours.
Reality – When the team gets mature, you can translate it to approx but not exact hours.

Myth 10. The product owners, developers and scrum masters get to do what they like.
Reality – The Agile is very disciplined framework. Every role has set of responsibilities. The core responsibilities should not be switched.

Myth 11. There is always a right size for a user story.
Reality – Every team is different hence there is no right size of the user story. The team producing 30 story points can be more productive than the team doing 45 story points.

Myth 12. Agile means no planning, no design
Reality – Agile typically needs more planning and design than waterfall. Both of these activities happen throughout the development.

Agile Abuse – Scenario 7
 

Neha – Developer 1, Bob – Product Owner, Peter – Agile Coach

Neha – We are always missing acceptance criteria and functional details in a story. It is really tough to commit a story with little or no clarity.

Bob – The Agile lets you to evolve the requirements as you move. This is perfectly alright.  I am within the boundary. I will write acceptance criteria when I get the time.

Peter- The requirements can evolve and that’s advantage for a customer while stories cannot keep evolving during the sprint.  You have an opportunity to refine the acceptance criteria. If the functional requirements are not clear or acceptance criteria cannot be determined during planning/grooming, the story shouldn’t be committed. It should be moved for a later sprint.

Bob – Can I write the acceptance criteria and later change it altogether during sprint as we progress?

Peter – No for sure. The change in a story once committed is a “scope creep”. You must move that to next sprint of post re-estimation, you might have to remove some other stories out of a sprint. Ideally, you are not allowed to change anything during a sprint. Adding more details to acceptance criteria to to make it more clear as you move should be fine, though.

Bob – Fair! I will take out the stories where I don’t have clarity.

Challenge – Writing one liner description for a story should be fine and we will keep looking at it while working in progress during the sprint. 

Agile Abuse – Scenario 6
 

Sumant – Developer 1, Veena – Scrum Master

Veena – Sumant, we are almost at last day of sprint and your 3 pointers are not yet done. Do you see a risk? What is the tentative time you think you would take?

Sumant – I can’t tell you. Agile says that you cannot convert story points to time hence 3 pointers can take 3 days or 3 months. All valid in agile.

Veena – Why do you estimate your stories?

Sumant  – So that we know whether we can do that in our sprint or not.

Veena – And a sprint duration can be 3 months too?

Sumant – Oops, I got it.  My bad!

Challenge – Story point is not about time, not even a range.

Agile Abuse – Scenario 5
 

Ron – Developer 1, Amy – Scrum Master

Amy – How come we committed 45 story points and we accomplished 51 though I have not added any extra work to sprint.

Ron – The performance improvement story was little complicated hence I have added 6 additional points to it.

Amy – Once an estimate is done, it is not supposed to change in any case. If so, the whole point of estimation has no value.

Ron – Sorry, I will change that back to original and add the challenges encountered with that story to our process asset library.

Challenge – It is perfectly alright to play with estimation at any point in time.  

Agile Abuse – Scenario 4
 

Paula – Customer, Amy – Manager

Paula – Amy, you mentioned that Agile is supposed to be faster. Why don’t you speed up the work with the same team? Sprint velocity is supposed to be must faster sprint after sprint and the speed of work should constantly increase.

Amy – Too much of speed can affect the quality of work. Agile promotes sustainable development. In a long run, the overall benefit with respect to quantity or quality is going to be more in most circumstances while the sprint can run with a pace and all you can expect is little improvement sprint after sprint.

Paula – OK. Got it.

Challenge – ‘Sprinting’ means running super-fast.

Agile Abuse – Scenario 3
 

Ron – Manager, Amy – Scrum Master

Ron – Amy, why the heck stand-ups are going for an hour every day.

Amy – The team prefers to talk and sort out open items. Although there is some unwanted discussions as well but that is just to keep morale up. It is truly helping us to sort out open items every day.

Ron – There is something wrong here. Are the questions being asked or clarification expected common to all?

Amy – Not really. Once in a while, it is general but typically it’s between two people.  It helps everyone to get the perspective.

Ron – You really need to take those discussions offline. The standup is supposed to end in less than 10 minutes (Worst case 15 minutes) for 10 member team.  You can do planning or grooming once or twice a week but that must have to be separate meeting and not a standup.

Challenge – A standup cannot be a meeting.

Agile Abuse – Scenario 2
 

Steve – Developer 1, Jeff – Developer 2

Steve (Evening) – Jeff, Can I pair with you on your story?

Jeff – Sure, but I am almost done with my story and moreover I would leave in another hour or so. If you are still interested, please join me.

Next day – Morning standup

Steve – I worked on adding comments field to our customer UI and further added that to database.

Jeff – I paired with Steve. Status – Ditto!!!

Message – I didn’t do anything hence pairing was a saver although it was knowledge transition.

Agile Abuse – Scenario 1
 

Kent – Scrum Master, Chris – Sr. Developer

Kent – Why do you work less than half a day?

Chris – I finish all my sprint work, I don’t need to look at time!

Kent – (During Sprint Planning) – I think we can pick more work. Chris, you being a senior developer, what do you say?

Chris – This is all we have been completing consistently in the past. That’s all we can do in given time hence we should not add more points.

Challenge – I leave very early because I finish my work and I pick very less because this is all I can do.