Implementing Agile Do's and Don'ts

Anay Narendra KamatPresentSoft Technologies

http://www.presentsoft.co.in

Takeaway

• Learning from mistakes• Confidence from success stories

All the teams and people mentioned in this talk are real and as such, could resemble to the people living or dead and the teams existing in organizations.

The Prime Directive

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Why to be Agile?

What does it take to be Agile?

Agile manifesto:Individuals and interactions over processes and tools

Working software over comprehensive documentationCustomer collaboration over contract negotiation

Responding to change over following a plan

Do perfectly agile teams really exist?

TEAM A

• BA formed the list of stories based on the requirements given by the client only.

• PM managed the team without getting into micro-management.

• Team provided and received updates during stand-ups.• Every member of the team was allowed to communicate

with the client• Dev followed PP, good design pattern, TDD and Continuous

Integration• QAs used automation tools to run tests• Deployment was automated as well

TEAM B

• Product owner had delegated the responsibility of requirements and communication to one of his trusted person

• BA formed the stories based on the requirements given by the client only

• Only PM and BA were allowed to communicate with the client

• Teams shared updates through stand-ups• Team followed PP, good design patterns, TDD and CI• QAs used automation tools• Deployment was automated

TEAM C• Team members had attended SCRUM trainings• Each team managed the leave requests of their members• Requirements/Stories were written by a different team• Estimates were done in ideal days• Duration of sprint was 3 weeks• Long stand-ups• Code reviews were done by members of another team.• Team did not follow TDD, PP, CI• QA members belonged to a different team• Requirements changed frequently• Team never delivered all the stories planned in the sprint.

TEAM D• All the stories were written and updated in project management tool

directly by the client.• Team relied heavily on email communication• Only few senior members were allowed in client call updates• Estimates were done in story points mapped to idea days• Team did not follow TDD, code was completely procedural, CI was not

used• Team members were divided in specialized groups• QA members belonged to a different team• Deployment procedure was separate for production and stage

environments• Only few people were able to handle deployment activities on

production

TEAM E

• Client had no time to give or finalize requirements. BA had to judge most of the requirements on his own.

• Only PM, BA and Architect was allowed to communicate directly with the client

• Long stand-ups. Stand-up was driven by the Project Manager.• Development used to start for the stories which were not

completely defined• Design decisions were taken completely by the architect• No strict code reviews. OO was not followed since

management was of the opinion that it was too advanced for the team members.

Quotes

Quotes

• It’s been 3 months since we started following scrum. We don’t see any improvement, but situation has definitely become worst – A team member

• On estimates done using story points over the scale of 2 - 3 - 5 - 8 (and 13), team of 12 people cannot achieve velocity of more than 10 points – Scrum expert of one organization

• Let’s start with the estimates, 2 point is for the story taking 1.5 days, 3 point for the stories taking 4 days … – A team lead from one organization

• We learnt a great thing. Remember it, and you can implement in your next project . – PM

Do’s and Don’ts

Focus Areas

• Project planning• Project management• Development• Quality analysis• Documentation• Skill enhancements

Project planning

Duration of sprint matters

Try to have high bus number

Have a story wall

Involve entire team in estimation meetings

Follow continuous integration

Design the deployment strategy well in advance.

• And make it scripted

Project management

Do not micro-manage

• Ensure that team understands the goal and the big – picture and is not dependent on stories.

• Be with the team

Encourage innovative ideas

Ensure learning from “Yesterday’s weather” is implemented

Development

Do not design too much in detail

Reuse, Reuse and Reuse

Be responsible

• Ensure you are not breaking existing features• Use automated unit tests. It helps a lot.• Every feature needs to be “Deployable”

Quality analysis

Put efforts to understand real user behavior

Reduce manual work through automation tools

Encourage test automation right from the beginning

Do not use “Number of defects identified” as matrix to measure

QA effectiveness

Documentation

Documentation

• Prefer following over text based documentation/comments:– Automated Unit Tests– Automated Functional Tests– Deployment scripts– Story description and discussions from project

management tool

Example : Using Cucumber

Skill enhancements

Skill enhancements

• Pair programming helps• Encourage training within the team• Encourage and reward implementation of

innovative ideas• Discourage forming of specialized groups

within the team

Questions ……

Thank you

ContactEmail: anay@presentsoft.co.in

Twitter: http://twitter.com/kamatanay