Recently Akrem and Erick presented Consulting 101, an annual presentation delivered at a Source Allies University event. We are publishing a three-part blog series that is a distillation of that presentation; Agile Crash Course, Team Dynamics, and Partner Dynamics.

Motivation

Here at Source Allies, we want to set our teams up for success right out of the gate by providing minimum critical direction that we have found to work successfully with multiple teams and projects over the years. This blog series highlights three aspects we believe hold keys to success on a project; Agile, Team Dynamics and Partner Dynamics. In this series we will explore why each aspect is important and how we envision that aspect working at Source Allies.

It does not matter if you are a new developer, experienced technologist joining a new team, or a consultant collaborating with a new partner, we believe you will find this series useful because this is a collection of what we learned from other teams, projects and partners.

Part 1: Agile

Agile software development methodology is used across all of our teams and projects. In order to better understand agile, let’s look at the world of software development before agile.

Before agile, the world ran on Waterfall!

Waterfall projects took a long time to deliver working software and risk accumulated until delivery. The initial assumptions made while gathering requirements, designing, and developing software are not validated until the testing phase or (worse yet) at the release stage. These assumptions create real risks that could cause a project to take longer if they turn out to be incorrect.

We’re talking about projects that take at least 12 months to complete and it wasn’t uncommon for some projects to run for 3 years or more. So many things can change in that time like market shifts, customer needs change, and the competition adapts.

Assumptions are great at disguising themselves as anything but what they really are. Project deadlines could be the ultimate disguised assumptions that with each passing day are getting closer to their “validation” date.

Agile tries to remedy this by creating mini cycles of delivery that are repeated over and over again, With each mini cycle, we’re delivering a working piece of software iteratively. That software is light on features in the beginning but grows with time. When we combine that with a beta test where we put this “beta” software in the hands of users, we get the chance to validate each assumption.

We call these cycles “sprints”. Each sprint contains most of the software delivery phases like requirements gathering, design, development, testing, and deployment.

The key advantage of short sprints is risk mitigation. As products are incrementally delivered, the assumptions are validated. If an assumption proves incorrect, only a segment of the sprint was wasted. The shorter the sprint, the less time is wasted.

Some other noteworthy tips:

• Try to make the sprint duration as short as possible.
• Stories that involve the biggest and/or riskiest assumptions should be prioritized towards the top of the backlog.
• Deliver working software solution at end of every sprint
• Avoid “big bang” releases
• The first sprint should end with a simple application that is deployed to an environment with a simple welcome page; it need not offer other features.

The Agile Manifesto

While the agile manifesto is pretty short, it’s very powerful. Note the phrasing of “we’re discovering better ways…” – this mindset is crucial to success of agile at Source Allies. We don’t dogmatically follow a recipe. Instead we reflect on our situation frequently and make adjustments as we go.

Some adjustments succeed and others fail, both of which are equally valuable. If it succeeds, awesome: move forward. If it fails, also awesome: now I know what doesn’t work and I know more about my specific circumstances.

Agile Ceremonies

In the following sections we will be talking about the most important agile ceremonies to start with for any team. Of course, teams are encouraged to regularly reflect on these ceremonies and alter them to fit their needs.

Backlog Grooming

Backlog grooming is for breaking down features into small stories that can be completed in a sprint while delivering business value. Stories have acceptance criteria to capture requirements. In Scrum, the backlog grooming session also involves the team estimating each story’s size and complexity via pointing.

Pro Tip: Backlog grooming sessions are a great place to ask questions to confirm one’s understanding of the product, user needs, requirements, etc.

Sprint Planning

This ceremony starts with the product owner (PO) putting forward a list of stories ordered by priority for the team to accomplish. Ideally those stories have already been groomed and have been pointed. Then the team discusses and decides how many of those stories they can deliver by the end of the upcoming sprint.

Using the past sprints as a guidepost, the team can make an educated guess on how many points they can accomplish at this upcoming sprint. Depending on how the planning session is going, the product owner might decide to alter their priority list to better fit what the team is telling them about what’s feasible.

Sprint

When the sprint starts, that’s when the team starts executing on the stories they planned for the sprint. To better visualize progress of stories, a physical/digital board can be used. A basic board can be composed of columns ordered from left to right; TODO, Development, Testing, Demo, and Done. A story would move through those columns as follow:

• When a teammate is available to take on new work, they pick up a story from the top of the TODO column and move it to the Development column.
• The teammate should seek to get answers on any questions they may have about the story before they go too far into implementation.
• After that, development can start using TDD, unit tests, and integrations tests)
• When development is done, the story moves to the Testing column. At this stage the story is tested end-to-end by Quality Assurance (QA) or other teammates.
• After the story passes Testing, the story moves to the Demo column to signal that the team is ready to demo the functionality to the PO.
• If the PO is happy with the demo, then the story moves to the Done column.

At the end of the sprint, the team can then demo all the stories that are in the Done column to external stakeholders.

Stand Ups

Daily stand ups are held every working day. These are short meetings (5-10 minutes) held by and for the team. During stand up, updates about each story are shared by answering the following questions:

• What happened yesterday?
• What is the plan for today?
• Are there any blockers?

Remember, stand ups are for and by the members of the team, not for external stakeholders. External stakeholders should be leveraging other touch points, such as demos and scrum of scrums.

A Note on Digital vs Physical Sprint Boards

Your choice will depend on your team. However experience has shown that physical sprint boards work better for physically co-located teams. Your scrum master or delivery lead can keep a digital board up to date for external stakeholders.

If your team is not co-located, then a digital sprint board would work better.

Demos

Demos are held by the team for external stakeholders. This is the team’s opportunity to validate the work completed in the sprint. It is important that these demos happen on a steady cadence. Ideally, the team would tailor the demo to the audience:

• For the business, provide a demo with the app’s UI: demonstrate features as if you were a user.
• For Tech Leads and Architects, provide a demo of APIs and show architectural diagrams.
• For teams working on the same product/application, feel free to go into implementation details
• For an eclectic group, try to split the demo up into small segments focusing on each group’s interests or schedule separate demos for each group.

Pro Tip: New teams can plan their first sprints with an eye for their first demo. That is, they pick stories so they have something valuable to demo.

Pro Tip: Don’t show sprint statistics (e.g. points completed, velocity, etc.) and instead focus on demonstrable business value that was delivered.

Retrospectives (Retros)

Retros are great opportunities to reflect on how things went and finding ways to improve. New teams should start with a retro at end of every Sprint.

Pro Tip: For production issues, the team can hold a retro on it after resolving the issue (aka a post mortem)

Pro Tip: Explore new retro formats from the Agile Retrospectives book

Ultimate Pro Tip: Kanban

Scrum is not perfect and may not be a good fit for every team. For those situations, we’re big fans of Kanban. This is suitable if you’re tired of being few stories over committed or under committed or you hate the start-stop nature of sprints with scrum.

In kanban, the backlog is continuously prioritized by the product owner; the most important stories are always at the top of the TODO column. The team picks up stories from the top of the TODO column and works on getting them to the Done column.

Kanban avoids the ramp up and slow down at start and end of sprints, respectively. Furthermore, there is no sprint planning meetings nor sprint commitments. We would still keep ceremonies like backlog grooming, demos and retros and each can have its own cadence as the team sees fit. For example, backlog grooming can be held every four weeks, demos are every two weeks while retros are every three weeks.