Use Agile Correctly (Part 2) – Team and Process

  • October 19, 2016

    Use Agile Correctly (Part 2) - Team and Process

    Perfect Agile Team—does it really exist?

    Success of any project depends on Team. I.e. it’s critical to have an awesome team to have rocking results. But in reality this doesn’t happen as team consists of individuals with their own attitude, aptitude, work style, ethics, behavior and issues etc.

    Bruce Tuckman’s team development model is a perfect example how team can come together and start functioning.

    Agile team’s Success heavily depends upon “self-Organized” team.

    Scrum Process

    Sprint Length and Team Size

    Sprint is to Run at full speed over a short distance. Ideal Sprint length is 2 weeks. My recommendation is as following and I have experienced that it really works well.

    • Ideal Agile teams must be 7 to 9 +/-2 members.
    • If you have more candidates in a team, then divide teams and have separate agile teams.
    • A representative of each team might want to attend other team’s standup for critical issues, follow-up and announcements etc.

    Most wanted thing in Agile – Velocity

    Velocity is the account of work team completes and delivers in each sprint. Ideal sprint duration is 2 weeks and highly recommend this to any team.

    I have seen better results when team works towards a pre-defined code complete date for instance, today is Tuesday and sprint is for two weeks, team can agree upon a code complete date of Wednesday of 2nd week. I.e. team will try to complete all the work by that day and have it ready for QA.

    This just gives a deadline to accomplish the work, however there will be situations where work couldn’t get complete or even rolled over to next sprint and that is fine in some cases.

    Here are some of my recommendations:

    Give as much time as possible to Developers, SDETs and QA to fulfill their commitment. I.e. less meetings and hindrance.

    Have at-least 2-3 sprints worth work well-groomed and available for the team as “ready for development”. Two reasons:

    1. At times for unforeseen reasons or instances a user story may be pulled out of current sprint. In such situations you lose story points you committed to. In such scenarios other US can be delivered.
    2. Sometimes team or an individual is able to complete the work early and available to pick more work, in such situation well-groomed loaded backlog can come very handy.

    For a sneak peek at the full series, see Vidya’s blog. Or, Follow Us on LinkedIn to follow along.