Running Agile Scrum projectsOften, when you speak with Agile believers, conversation turns to praising of all of the wonders it will bring you, but how do you cash in on all the promises. Running Agile Scrum for the first time the wonders might seem a bit distant. These notes represent what works for me when starting out new Agile Scrum projects.To understand this article, you may want to know the basics of Agile Scrum.

Prerequisites for successThere are a few practicalities, the Agile Scrum team or teams should have in place before they start building the first potential releasable product.To increase the chances of success, I recommend having the following tools available:

1. Team collaboration tool2. Source code version control system. 3. Code review tool, preferably integrated with the version control system. 4. Tools for managing test and errors.

If the project is just slightly bigger than a small project, it also make sense to look into con-tinuous integration or continuous releasing.

I would like to take the opportunity to remind you of something most teams probably know already: code reviews are the single most efficient way to increase product quality. In addi-tion code reviews increase learning in the team. Also it allows all developers on the Devel-opment team to develop a common set of implementation best practices related to the product.

It is neither complicated, nor expensive to get the mentioned tools in place, so I always recommend self-managing teams to have these tools available for their work if not already provided for them.

Scrum environmentIn many cases, Agile Scrum runs in the scope of an other project model like Prince2 or PMI. Like most project models, Agile Scrum is not intended to run in the scope of other project models, because there is a the risk that the agility and efficiency of Agile Scrum is redu-ced. If you have to run the project in context of another project model, try to minimize the interface.

For large projects (ie. more than 2-3 teams working on the same product) there are a number methodologies for scaling Scrum. I would like to mention the Nexus frame work and SAFe as two common methodologies. It easily becomes very religious when discus-sing pros and cons of these two models. To explain it simply; both frameworks suggest how multiple teams collaborate around a common backlog and the releasing of a potential-ly releasable product at the end of each sprint. For more details look-up relevant resour-ces.

Project planningBefore initiating the first sprint planning session, the business owner often request a plan that show when the product is complete. Planing beyond the next sprint is not described in much detail in Agile Scrum.When discussing long term planing, I like to talk about the Minimum Testable Product (MTP) and the Minimum Viable Product (MVP). The MTP is the product that delivers at least one feature of the final product that can be tested with beta users. The MTP is im-portant for getting the first user feedback. The MVP is the product with the highest return on investment versus risk. Agreeing on the MVP is a balanced discussion between the Product Owner and stakeholders on delivering a holistic product experience and really cut through to the absolute core of the product. Whether planing for the MTP or MVP is up to a discussion with relevant stakeholders. An argument in favor of planing for the MTP, is that the process of getting from the MTP to the MVP is often an iterative process.I recommend to complete at least one sprint before engaging in longer term planning. Ty-pically new teams have no knowledge of their own capability (Average velocity). To make things worse, the velocity is expected increase over time with proper coaching. The same counts to some extend for established teams without Agile Scrum experience.

The best way to satisfy the request for an estimate of when the MTP or MVP is complete is to run a workshop including all Scrum Teams of the project. The purpose of the workshop is to fill the product backlog with all backlog items needed to produce the MTP or MVP. When the backlog is filled, each backlog item can be estimated and the sum of all the estimates give a first shaky estimate on the total development time. The Product Owner will continuously improve the backlog during the sprints and update the product done tar-get after each sprint.

Sprint planingBy now the Product Owner probably has enough information from the stakeholders to cre-ate a sufficient number of backlog items for the first Sprint. Ideally, the backlog items cho-

sen for the first sprint should represent a vertical slice of the product and not a horizontal one. This is often difficult for complex projects. It can be difficult to slice the product verti-cally and at the same time have a potential releasable project by the end of the first sprint. One way of alleviating this situation is to scale with more teams. This will make creating a vertical slice of the product within a single Sprint more viable. Alternatively, the product can be split up into in two or more products, each with a separate backlog. One of these could for example be a platform product. Keep in mind that the platform product must also be sliced vertically, and must also deliver a piece of relevant functionality that potentially could be released. It is worth mentioning that development on a product can be stopped after each Sprint, so when the platform product has sufficient functionality, development can be stopped and be resumed when further functionality is needed.Finally, there are a few, but important items the Agile Scrum team is recommended to di-scuss during the first sprint planing:

1) The expected quality level, as this has significant impact on the amount of new feature the team can produce. Producing military grade products for example might only allow the team to allocate 20% or less of their time producing new features and use the remaining time on various quality measures.

2) The team must ensure coding guidelines are available or create them.3) This is also a god time to discuss the initial product architecture.4) Agree on the definition of done. A process each Sprint Backlog item must ad-

here to for the item to be Done

Running the sprintThere are many good ideas on how to run Sprints in Agile Scrum, my single most important advice when starting out: Get the Sprint Backlog items out of the computer and up on a Scrum Board to make the work carried out as transparent as possible.

Team coachingThe most important key to succeed with Agile Scrum is to have a skilled Scrum Master or Agile coach to help coach the Scrum Team or teams in reaching their maximum potential. This happens mainly at the Daily Stand-up and the Sprint retrospective. This effort is more complicated and take practice to master.

Now you are ready to start cashing in on the great benefits of running Agile Scrum. Re-member projects are people.

Go inspect and adapt,

Jakob JensenAgile coachRedconsult