The Secret Sauce of Delivering Scrum Projects

Jesus Mendez, @chuzzete, Seedbox Technologies, www.jesusmendez.ca

A typical project life cycle is composed of different phases. From the original idea, until the project is released and then supported, there are many things to consider ensuring it gets done within the scope, budget, time, and quality standards you aspire to reach. All of this, while keeping risks under control and customers delighted.

One successful way to deliver a project that reduces risk, increases customer satisfaction, and provides a reliable ROI is through Scrum, one of the most popular Agile frameworks of building products, generally software, iteratively.

But, what elements shall we consider when delivering Scrum projects so it can be done consistently and successfully?

First of all, the original idea might need to be discussed and lightly evaluated before putting effort into it. In order to do that in sprints, I really like the Disciplined Agile Delivery [1] approach, which envisions a project to be delivered in agile lifecycles through three stages:

1. Inception (Envision and Plan)

2. Construction (Incrementally build a consumable solution)

3. Transition (Release solution)

Let's define how the Scrum framework will be used to deliver projects consistently, from the original idea to the release of the final product:

Inception

Assuming that the Scrum team is already formed and it is comprised of the three typical roles: A Scrum Master, a Product Owner, and a Development team. In this stage, the first couple of sprints will be dedicated to shaping the idea/hypothesis into a real project. Some elements that need to be considered in this phase are The Project Charter creation - a session facilitated by the Scrum Master where the Product Owner and Stakeholder collaborate to shape a light version of what the project is about.

Within this one hour meeting, normally the team will find answers to the following questions:

• What do we want to achieve? (Product Owner)
• Why do we need to do it now? (Product Owner)
• What are the high-level acceptance criteria to consider the project a success? (Product Owner with Stakeholder(s) input)
• What is the minimum viable product that could be delivered to test our idea/hypothesis? (Optional and dependent on how the organization wants to release its products)

Once the project charter is created, the Scrum Master prepares and then facilitates a meeting, to help all parties collaborate on the project and create a shared understanding of it. I have called this meeting ‘Let’s collaborate’ (a session facilitated by the Scrum Master to help Stakeholder(s) share/validate the idea/hypothesis with the Scrum Team). The goal of this meeting is to get everyone involved in the project on the same page (common and shared understanding) and will have a time limit of two to four hours. Normally within this session, the team will answer the following questions:

• Is the idea/hypothesis technically viable with the resources available at the moment? (Development Team)
• Depending on the approach in terms of product development (MVP or not MVP), what kind of framework is required to support the product vision?
• What are the high-level pieces that compose the MVP (To be released in a maximum of 2 weeks)? (Development Team) (Optional)
• How long will it take to get the project done? (High-level estimate in terms of sprints).
• Shall we continue with it or not? (Stakeholder(s) to answer)

Once the meeting is done, the Scrum Master helps the Product Owner to create the plan for the upcoming iterations, based on the meeting outcome and then suggests that the Product Owner communicates the plan to the team, for final validation and approval.

Project Approval

By the end of this meeting, I encourage stakeholders to make the decision and approve or reject the project. This will ease the process and reduce the amount of time wasted on unnecessary validations.

Construction

If the project has been approved, now is the time for the team to start building a Proof of Concept or even the first consumable. In order to succeed in the construction phase, I strongly recommend planning and running at least one product backlog grooming session per sprint; focusing on the product backlog items written during the Inception phase. Doing this will guarantee the team staying focused on the project recently discussed, which will have a direct impact on the quality of what will be delivered by the end of the sprint.

Another element to consider if we are going to make a great ‘secret sauce’ of delivering Scrum projects, is to set sprint goals and track how the sprint backlog is being eliminated through the sprint. In addition to setting sprint goals, I also teach the team the importance of staying in sync daily. Every Scrum Master will tend to apply their favorite technique to help the team make daily stand-ups fun, simple, and interesting. What really matters here is to help them share where the sprint is, in terms of the sprint goal, how to keep the sprint status visible and easy to understand in one view. For this purpose, I strongly recommend using a physical scrum board, where the team can display all the information necessary to be in sync and coordinated for the duration of the sprint.

Once the sprint has been planned, and the Scrum team has started eliminating product backlog items from the sprint backlog, it is the responsibility of the Scrum Master and the Product Owner to help the team stay focused during the sprint, when completing the sprint backlog.

By the end of the sprint, it is time to demonstrate what the development team has completed. At the sprint review, the most important event of the sprint is to increase collaboration and give/get feedback about the product and its evolution. The secret here is for the Scrum Master to create the conditions to make people feel that the meeting is fun, organized, and it is worthwhile coming to every single sprint. It is very important for the Product Owner to keep the stakeholders informed and interested about the project progression by leading the team accordingly.

At this point of the construction cycle, it is time to recognize what worked, what didn’t, and what requires improvement by analyzing in a retrospective what the Scrum team has done. Again the Scrum Master is a key factor to help the team create self-awareness about what happened during the sprint and provide the team with some tools and techniques to master continuous improvement. The sprint retrospective will be considered helpful by the team if it brings value to them or at least if they feel like it is something that is not an easy task. But with good preparation, a good Scrum Master will use their facilitation skills to create a container for the team to help them grow by learning from their mistakes and celebrating every single time just for giving it a try.

But remember, you need the right people working together, so then everything that I have mentioned so far can happen. So please, pay attention to people’s selection process and don’t forget to include the Scrum team and empower them to be part of the decision-making process. Keep in mind that for Scrum to work, every role matters.

Transition

The Scrum teams that I have worked with are responsible for releasing the final product into production without further assistance. If that’s the case, then I would suggest helping them with creating a definition of done per user story, in common agreement with the product owner. Also, to work on a software release strategy, which involves a combination of conditions that have to be met when releasing a product into a production environment. Given that we are operating in iterations, helping the team to find a way to ensure that every single time that a consumable product is released, the customer is aware and delighted with the final result because that is what really matters in determining if the Scrum project is a successful one.

Conclusion

There is no magic or secret sauce to delivering a Scrum project that will work every time, but I think if you are structured, consistent, patient, and passionate about continuous improvement and there is a good understanding of the what and why of the project and you have the right people motivated towards building products to delight customers, then you are guiding your team through the right path. Continue trying and experimenting, and all the learning experience will give you exactly what you need.

References

1. Scott Ambler, http://www.disciplinedagiledelivery.com/lifecycle/

---

Agile and Scrum Articles

Planning Teams Agile Transformation Process

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

Process improvement, The Agile Way!

Agile and Scrum Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Winter 2016 issue of Methods & Tools