First of all, Scrum is just a methodology and not a magic word that would erase all the problems during your development lifecycle. Rather than invent a new definition of Scrum, look at the wikipedia definition:

Scrum is an iterative incremental process of software development commonly used with agile software development.

The significant word here is iterative.

I have sometimes lack of motivation, sure, you sometimes have too, so let’s begin with a too classic Developper Story :

Your project manager arrive with a really really really important project from the business with a f***** high top priority. The release date is tomorrow and you have half a post-it as specifications.

After crying, screaming, “black outing”, think about a resignation, you will begin to feel overwhelmed by the whole project.

At this point, take a break and learn Scrum.

Scrum splits an entire project in little comprehensive action. It helps us to focus on what is important now and not what you will do in one week. Sure, do not forget to think before programming but do not believe the user specification as the holy grail cause there is 95 % that it will change.

Overview from Mountaingoatsoftware

Let’s play : the roles in Scrum

Two groups : the pigs and the chickens, based on a joke.

Here is the joke :

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

From wikipedia :  The “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken” – interested in the project but really indifferent because if it fails they’re not the pigs – that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project.

PO (product owner) :  The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes user stories, prioritizes them and then places them in the product backlog

Generally, it is you manager or you project leader. The point here is to convinced you manager to play that game. Explain him that Scrum will help to have a better view on what the team is doing. Do not forget to show him the product backlog and the sprint backlog with the little graphics (we will see that later). I am sure he will be happy. If he is still not convinced, try a strike or organize a strategy with your colleagues to find out how you could transform you boss as a product owner. There are plenty of arguments on the net and in your head.

ScrumMaster (or Facilitator) :

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand.

He acts like a shield for the team. Avoid the word “self-organizing” near you boss, he will be scared to lose the control. Another tip, use the word Facilitator instead of Scrummaster, the scrum master is not a manager or a leader so avoid the full of meaning word “master”. If you want, you can change your facilitator at the end of the sprint. It brings fresh air for the facilitator himselft and the developer who will take the place for a sprint. Sure, you facilitator can act as a developer or you have a strange team (Yeah, I know It happens).

The Team
The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (designer, developer, tester, technical communicator, etc.).

I know, sometimes you are only 3 or 4. I do not know if there is a minimum number. I used to develop in a 3 people team with SCRUM and I can say that It is make sense.

Try to find a funny name for you team, it can bring fun and jokes…

The Team, the ScrumMaster and the PO are pigs.

The User :

The software is being built for someone

Stakeholders (customers, vendors) :

These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.

Sometimes Stakeholders are Users, prepare to have a lot of changes in your specifications.

Managers :

People who will set up the environment for the product development organizations.

The important thing : communication

- The Daily Scrum

Each morning (8:00 am for us), the scrumaster (see below) organize a little meeting (about 15 minutes) next the cofee machine and ask three questions to all the team members:

• What did you do yesterday ?

• What will you do today?

• Are there any impediments in your way?

The daily scrum is not a place for debating technical problems and personal life, it is just a quick overview which helps everyone to know what you are doing, what you finished and what you will do.  You have to answer quickly like “I need some help for …” or “I am strugling with …” At the end of the meeting, if the SCRUM master cannot help you directly, he will take the point and decide who can help you or what you have to do.

- Sprint Planning Meeting (PO + ScrumMaster + Team + others significant manager or custormers)

At the beginning of the sprint cycle (every 15–30 days)

The Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives. During that meeting, you define which tasks will move from the product backlog to the sprint back log. Team members ask questions to know more about specifications and together you define the priority of the tasks. The PO and the ScrumMaster define the goals for the sprint. After the sprint planning meeting, the team discuss if the goals are realistic and negotiate with the PO if there is some change to do.

Please, PO and ScrumMaster, involve your team in the sprint planning meeting, it is very important that the team feels the issues and the context of the projects they are working on.

- Sprint Review Meeting (PO + ScrumMaster + Team + others significant manager or custormers)

During that meeting you will discuss on what is completed and not completed. The limit of time is 4 hours. I encourage the team to make a demo of the new features. It is more visual than a powerpoint. The most important for the team is that the general aims are achieved. If not, it is normal in the beginning cause you need more experience to evaluate correctly the sprint backlog.

- Sprint Retrospective (PO + ScrumMaster + Team)

Discuss on what it works and did not work.  Two main questions during that meeting : What went well during the sprint? What could be improved in the next sprint? Do not hesitate to improve you process.

The artifacts :

The product backlog :

From Mountain Goat Software : The Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or requirements. Typically, a project writes down everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.

Here is the example of a product backlog : simpleproductbacklog

The Sprint backlog (wikipedia):

This is a greatly detailed document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and 16 hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. The sprint backlog is property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

Example of a sprint backlog template_sprint_backlog

You can find others sprint backlog and product backlog after a quick search on google…

Conclusion

Like I said before, Scrum is not magic and does not resolve lack of communication, programming errors and environment difficulties. It is just a methodology. I choose Scrum because you do not need 100 hours to understand it and to setting up the environment. You only need your team and some post-it. Managers and customers can easily understand how it works and this is not necessary the case in an IT department. Scrum helps also to avoid an overwhelmed feeling and brings democracy in a team (which is a good thing in my point of view). This is the team who is responsible and not a particular member. It brings also cohesion and team spirit.  I advise you to try it and see if it can fit to your team.

I hope I give you a good overview.

If you have questions, do not hesitate to ask me by comments.

Bookmark It

Hide Sites