Archive for June 2015

Simple Things You Can Do to Ease Your Agile Journey…Some Dos, Don’t s & Best Practices from my experience

This article is also published in Scrum Alliance Articles section on 1st July 2015.

I have been enjoying the Agile journey over the last six years, which has taken me through a large-scale organizational transformation. During this time I’ve had the opportunity to coach teams, ScrumMasters, product owners, and management. I would like to summarize some do’s, don’ts, and best practices learned during my journey.

I am not going to go into the details of each point here, because I want to keep it simple. If you have queries, suggestions, or corrections on any of the points, please leave a comment for further discussion.

I hope that this article helps you in your own Agile software development journey.


What is the fifth principle of the Agile Manifesto?

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

To uphold this principle, follow these guidelines:

  • Be patient.
  • Create a vision for transformation.
  • Maintain constant communication.
  • Let the teams form on their own; guide them.
  • Don’t compare teams.
  • Don’t micromanage.
  • Encourage innovative thinking.
  • Rely on trends, not just on single occurrences.
  • Apply the Tuckman ladder model for team building.

Product owner best practices

  • Talk about what the work should do, not how.
  • Challenge the team, but don’t bully them.
  • Don’t focus only on short-term delivery.
  • Practice business value-driven thinking.
  • Understand the change, and cascade it.
  • Always be available to the team.
  • Don’t add changes during the sprint.
  • Create quality user stories.
  • Manage stakeholder expectations.
  • Manage the product backlog effectively. Keep it alive.
  • Track progress periodically.
  • Participate in planning, review, and retrospective meetings.
  • Don’t compare teams; that’s detrimental to team-building.
  • Focus communicating on the whole product.
  • Don’t introduce confusion.

Development team best practices

  • Form as a team on your own, although accepting help is usually smart.
  • Create an identity for your team.
  • Choose your ScrumMaster.
  • Ensure that your team is self-organized, cross-functional, and empowered.
  • Pull the tasks for the sprint. Don’t wait for someone to assign the feature items.
  • Respond positively to change.
  • Create your team space.
  • Ensure that your team is co-located.
  • Ensure that all team members have the same understanding of the sprint goal.
  • Encourage face-to-face communication.
  • Evangelize We over I or you.
  • Care about the whole product.
  • Avoid silo-based thinking.
  • Always deliver quality working software.
  • Inspect and adapt regularly.
  • Clear your level impediments. Don’t look for other impediments.
  • Facilitate team-bonding activities.

ScrumMaster best practices

  • You are the change agent.
  • Be courageous when making decisions.
  • Protect your team and clear their impediments expeditiously.
  • Bridge gaps between team roles.
  • Be a true servant leader.
  • Observe the patterns your team exhibits so you can all learn from them.
  • Give feedback, and be receptive to feedback given.
  • Keep constant communication alive with the team.
  • Be your team’s coach.
  • Manage conflicts swiftly and fairly.
  • Don’t own product decisions; work with the team and the product owner.
  • Don’t estimate for your team or give technical solutions.
  • You are not the team’s manager. Don’t assign them tasks.
  • Facilitate all Scrum events and meetings effectively.
  • Be creative; try new approaches to retrospectives and other recurring events.
  • Motivate your team, from the mico level of writing better stories to the macro level of creating the best product possible.

Scrum events best practices

Sprint planning

The sprint goal is the key to the sprint’s success.

  • Ensure that the planning is timeboxed.
  • Enforce the PO’s attendance at the meeting.
  • Encourage collective participation.
  • Estimate story size through story points.
  • Estimate tasks in effort hours (<6 hours).
  • Pull tasks; do not assign them.
  • Ensure that stories meet the Definition of Ready (DoR).
  • Check whether the Definition of Done (DoD) needs adjusting.
  • Update the task board after planning.
Daily Scrum
  • Keep the meeting to 15 minutes or under.
  • Enforce attendance by all team members; only the ScrumMaster’s attendance is optional.
  • Hold the Daily Scrum at the same time and the same place each day.
  • Focus on the three critical questions: What did you do yesterday?What will you do today?, and Are there any impediments in your way?
  • Avoid extended discussions.
  • Start at the scheduled time.
  • Hold the meeting in front of the task board.
  • Track impediments.
  • Ensure that the team speaks only to other team members.
Sprint review
  • Ensure that the review is timeboxed.
  • Enforce the PO’s attendance at the meeting; invite others who are interested.
  • Show only items that satisfy the DoD.
  • Collect feedback on the sprint items.
  • Demo on an integrated environment.
  • Ensure that the PO manages other stakeholders.
  • Discuss the incomplete items and the actions to resolve them.
  • Identify and discuss the probable items for the next sprint.
Sprint retrospective
  • Ensure that the retrospective is timeboxed.
  • Enforce the Scrum team’s attendance at the meeting.
  • Follow the five stages of the sprint retrospective: Set the stage, gather data, generate insights, decide what to do, and close the retrospective.
  • Don’t always follow the same model in every meeting; be creative.
  • Allow everyone to speak.
  • Discuss problems, not people.
  • Don’t play the blame game.
  • Track action items for improvement.

Scaling Scrum best practices

  • Choose a suitable scaling model based on your organization’s needs: Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), or Disciplined Agile Delivery (DAD).
  • Ensure that you satisfy the following conditions:
    • Coaches are trained and experienced.
    • Joint grooming of product backlog exists among Agile teams.
    • Co-located release planning exists (whenever possible).
    • Established release walls exist for promoting cross-team feedback.
    • Joint sprint planning is conducted with other Agile teams.
    • Common sprint schedules exist for all Agile teams.
  • Use release burn-up.
  • Implement a global impediments board.
  • Conduct joint retrospectives.
  • Participate as ambassadors in the Scrum of Scrums.

Engineering best practices

  • Adapt a value-based engineering culture.
  • Don’t force ideas; get the team’s buy-in.
    • Uphold the following principles in the engineering department:
    • Test-driven development
    • Re-factoring to makes sure the code design is simplified
    • Pair programming
    • Collective code ownership
    • Continuous integration
    • Automated fault-slip-through (FST)
    • Single-trunk development
    • Feature toggles
    • Sonar or any other tool integration
    • B2D tools
    • Visible architecture

Key characteristics of information radiators

Don’t use information radiators as a mechanism to criticize or compare.

Effective information radiators have the following key characteristics:

  • Large, easily visible
  • Understandable at a glance
  • Convey same meaning to casual and interested visitors
  • Can be used as the base media for:
    • Team-level, physical task boards
    • Organization-level impediments by using a Kanban board
    • Root cause analysis on critical items
  • Keeps team progress up to date
  • Simple navigation and auto display change
  • Alarm for build failures

Mechanisms for cultivating a Community of Practice (CoP)

A Community of Practice is important for transforming a traditional plan-driven organization into an Agile one.

A Community of Practice is cultivated by doing the following:

  • Sharing knowledge and best practices
  • Providing a forum to get secure cross-functional support in the organization
  • Applying the same practices across the organization
  • Separating ScrumMaster and architecture CoPs
  • Facilitating problem solving
  • Reusing solutions
  • Learning from others’ failures
  • Keeping the CoP self-sustained

Improving communication

Agile communication is open, transparent, and healthy. Successful communication requires that you perform the following activities:

  • Become an active listener.
  • Use fewer electronics.
  • Implement osmotic communication.
  • Avoid blame games.
  • Create a forum for constructive disagreements and not for conflicts.
  • Invest in tools (whiteboards, Blue Jeans or other videoconferencing, etc.).
  • Talk more; write less.
  • For distributed teams, fly in key people for key events.

Ensuring quality

Ensuring quality is the collective responsibility of the Agile team.

  • Uphold the DoR and the DoD.
  • Ensure continuous informal product reviews.
  • Establish coding standards.
  • Encourage simple and just-in-time (JIT) design.
  • Follow engineering practices.
  • Implement automated testing.
  • Write clear user stories and acceptance tests.
  • Conduct frequent code reviews.
  • Ensure continuous integration.
  • Use retrospectives for continuous improvement.
  • Develop a one-click build process.

Tools for tracking and monitoring

Decide which tools to use based on the organizational working model. Tools provide visibility into the team, the project, the program, and the portfolio. They also keep the data up to date. However, the garbage-in/garbage-out philosophy still applies.

  • Use suitable tools, such as VersionOne and JIRA Agile.
  • Use the same tool for all locations.
  • Complete training on tools for all teams.