no script

Some months ago I received a message from one of the listeners of my podcasts. He had a question: How do you organize 35 students working on the same project if you want to use Scrum? As an answer Sune from Cobraid, Johannes from Alfanova and myself came up with these three pieces of advise:

  1. Use Full Stack Teams
  2. Tasks must be broken down to avoid having only User Stories
  3. Use deadlines and milestones

So, this is what we came up with.

Project Giraffe

Project Giraffe has been going for 7 years. It’s a software project that the students work on in their last semester. The primary objective,  is that the students learn how to work on larger projects. If they also produce any kind of useful software, it’s really just considered a bonus. 

The students wanted to use Scrum in their project. They had been taught a bit about it and understood that it was “the new black” in IT projects. They read about it, and organized themselves into smaller groups according to what they thought was appropriate and referencing to to the study books on Scrum. However, it didn’t turn out as they had planned. That’s why, Anton contacted us to ask what kind of advice we had.

If you happen to speak Danish and want to hear more, you kind listen to our podcast here.

About the author

Birte Laursen is a process consultant and agile coach.

She owns Birte Laursen Cunsultations. On her Retrospectives.dk she posts blog posts, podcasts and more about Scrum and agility. 

 

Full Stack Teams

When setting a Scrum team, it’s important to make sure the teams have what it takes to solve a task from A to Z. The team should never be dependent on someone outside of the team in order to get on with the task. That sets large, and sometimes unrealistic, demands for the members of the team. You will not necessarily have an expert on UX or database on each team.

Even though this is the optimal way to do it, it is possible to finish the project… as long as someone in the team has this as their responsibility. If the database expert on the team has problems, he or she can always ask for help from database experts on other teams. To enable this, you might even start up guilds, as a knowledge network across teams, where it’s possible to share experiences in the exact field that you have been assigned to in your own team.

Break down the tasks

A task must never be too large. A large task must always be broken down into smaller tasks, and the team must always do this together. When the team breaks down a user story into smaller tasks, a lot of knowledge sharing takes place. There will be a lot of specific ideas and suggestions of how to solve the task and not just assumptions that later turn out to be impossible or too complex. When it’s definite, it’s easier to relate to and think about. 

However, i’s a balancing act, because the task should not be resolved in the large team – just outlined. Too many chefs, spoil the broth! In the same way, too many programmers spoil the code. That’s why you should never code all together. It should be kept on an outlining level where ideas, suggestions and challenges are discussed. 

Deadlines and milestones

It’s a misunderstanding that agile projects don’t contain deadlines and milestones – because they do. A lot actually! It’s more about who sets them, and on what level they should be set. A Product Owner sets the milestones of when different parts of the product is finished, in corporation with the customer. 

If anything happens during the project, causing the customer to want to change direction, the milestones are adapted with the customer. When a Product Owner has prioritized the tasks, and the team has valued how much can be taken into the next sprint there will be a deadline for when the task are done – and that’s at the end of the sprint. 

What is not used in agile projects is a detailed description of when all the functions are expected to be done many months into the future. The rule is that anything might change, and therefore milestones and deadlines must be changed and adjusted.