I had experience working with a few Large Scale organizational Agile transformations. During this time I’ve had the opportunity to coach teams, Scrum Masters, 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.

Management

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, instead make them self-organize and empower them
  • Encourage innovative thinking.
  • Rely on trends, not just on single occurrences.

Product owner best practices

  • Be a “Product mindset” Product owner instead of “Project Mindset”
  • Begin with the end in the mind (Vision).
  • Do not spoon feed your teams.
  • 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 high quality user stories.
  • Manage stakeholder expectations.
  • Manage the product backlog effectively. Keep it alive.
  • Track progress periodically and make scope Vs time trade-off decisions.
  • Participate in planning, review, and retrospective meetings.
  • Don’t compare teams; that’s detrimental to team-building.
  • Conduct periodic Product backlog refinement sessions.
  • Focus communicating on the whole product.
  • Don’t introduce confusion.
  • Focus on the “Outcome” not the “Output”

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 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 and also working.
  • Always deliver quality working software.
  • Inspect and adapt regularly.
  • Act on the impediments wherever you have Power/Ability/Knowledge.
  • Stop starting – Start finishing.

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, not a consultant.
  • Manage conflicts swiftly and fairly.
  • Don’t own product decisions; instead, be a decision enabler.
  • Do not give solutions, instead teach them how to find solutions on their own.
  • 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 and appreciate your team whenever needed.
  • Resolve global/systemic impediments as your high priority.
  • Create a “Safe to fail” environment.

Scrum events best practices

Sprint planning
  • Craft a Sprint goal that is SMART.
  • Ensure that the planning is timeboxed.
  • Enforce the Product owner attendance at the meeting.
  • Encourage collective participation.
  • Break the tasks into smaller ones.
  • Pull tasks; do not assign them..
  • Let the team decide how much work they can pull into the Sprint.
  • Check for your team’s commitment levels to meet the Sprint Goal.
Daily Scrum
  • Keep the meeting to 15 minutes or under.
  • Ensure 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 or finding resolutions for the impediments.
  • Start at the scheduled time.
  • Hold the meeting in front of the Sprint backlog.
  • Track impediments effectively (I suggest creating a visible impediments board).
  • Do not make it a status meeting, Daily Scrum is an inspect and adapt opportunity.
Sprint review
  • Ensure that the review is timeboxed.
  • Ensure stakeholders attend this meeting. If required share the invite ahead of time.
  • Show only items that satisfy the Definition of Done.
  • Collect feedback on the sprint backlog items.
  • Demo on an integrated environment.
  • Make sure the Product owner updates the feedback into the Product backlog before next Sprint planning.
  • Identify and discuss the probable items for the next sprint.
Sprint retrospective
  • Ensure that the retrospective is timeboxed.
  • Ensure 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.
  • Help the team to come up with an actionable improvement plan by the end of the Retrospective.
  • Do not skip the Retrospective.
  • Based on the need, conduct Release/Project/Surprise Retrospectives.

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 refinement of product backlog happens 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
    • Refactoring 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 Definition of Done.
  • Follow continuous integration practices.
  • 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.

  • Do not use multiple tools, they reduce transparency and increase complexity.
  • Use suitable tools, such as VersionOne and JIRA Agile.
  • Use the same tool for all locations.
  • Train the teams on how to use the tools.