I learnt Scrum as a model to be applied to software development with all its features and behaviors to deliver product or services. But I also learnt that project management models may be applied to lots of other scenario. So it is for Scrum model I thought. So it would be needed a better, easier and faster way to explain this wonderful model. I came up with a metaphor about me as a product to show you Scrum model can be applied to scenario different from software development.
Why not, I thought! Each of us is a product. I don't want to write about philosophy but only something about how me as a product may be improved with lots of new modern features and behaviors, from better open mindset approach to physical mass improvements to new learnings, a better haircut and so on... Lots of items to deal with, so why don't call someone to manage all these items down in a list?
Well, up until now I've been wearing the Business role, the one dealing with the daily business and that requires some new features to be improved for a new product or service and in this scenario, me as a product.
But who can do this job to manage a list of items and who has so a deep knowledge to manage and set priorities to so many items? Here it comes the Product Owner, the one with the most experience and knowledge about the product.
So, let me undress the Business role and wear the Product Owner one.
This role is one of the three key roles in a Scrum model. The Product Owner, someone from the business or someone with lots of knowledge about that business, who manages all the items requested by the business, the one who creates and sets priority of a product backlog that is the list of all the items that will lead the whole product delivery life cycle.
Now we know what are the business needs and who manage and has a deep knowledge of those needs. But one more question. Who helps the Product Owner to identify all the requirements from the business? Well, there is an important figure from the Development Team. But what is the Development Team?!?!
Ok! Ok! Scrum model states if you want to implement anything you need a group of at least three to nine skilled members with different competencies. One of those members is the Business Analyst, the one that is able to elicit and gather all the requirements from the business. This figure works strictly with the Product Owner to understand priorities and business requirements and finally transfer the domain expertise acquired to the rest of the team. So its output is the team input to help them determining considerations of time and costs about what they are going to develop for the final product.
So the Development Team is (there's not an ordered list) the second key role in the Scrum model.
But as everyone knows, there are lots of tasks to do all around a project and lots of impediments that may lead a project to failure. As I would bring to success my product improvements and get me with a new brand haircut, a better body built and other features, I need someone that would help me shield my project from outside.
Well, Scrum model named this key role as Scrum Master, the third key role of the model.
This figure is just like a guru, someone enabled to guide the Team but without any authority, just a servant leader. Someone might guide also the Product Owner to better manage the product backlog.
This role is really important and a very delicate role. It must guide the meetings and the stakeholders involved in the project.
Scrum defines this role as the most hard to master. But a successful project requires such a role with a skilled Scrum Master and I want my product improved.
So far, so good!
Now that we defined all the roles in our project, we need to define some meetings. There are not so many meetings to organize in Scrum but there are some that are essential. But before defining meetings it's important to define some essential rules.
First, as you can imagine, business want to see how the product is going to meet the stakeholders expectations. And to accomplish that, Scrum defines the Sprints. These are lapse time boxes. These help define how long it does take to develop a piece of product before to show a partial result to all the stakeholders.
Scrum states that a sprint must be at least one week long up to four weeks. The time boxe must be choosen by the Development team and it should fit their needs and be comfortable with their best way of work and how much feedback they need by the business. On this, the Scrum Master may help identify the best time boxes.
Anyway, let's say a team may start with a time boxes of 1 week with lots of feedback at the beginning to get quickly on the right page and adjusting to two or three weeks Sprints after at least three sprints used to understand deeply the business needs and how they are comfortable with the sprint itself. This is useful when the team is new to Scrum model.
I really want the team works knowing what each member of the team is accomplishing and how the work is going on. And I want this to happen daily in order to be aligned on what each member is going to work on for that day. This is called Daily Scrum Meeting. This usually happens at the beginning of every day and last for only 15 minutes. This meeting is only for Development Team but discretionary the Scrum Master may join to facilitate the meeting and be sure the meeting does not take more than 15 minutes.
Well, now let's schedule some more important meetings. I want my product to be improved quickly. I want to be better than yesterday! So, what are we waiting for?, go on!
Scrum is easy to understand grossly but what it's generally hard to understand may be roles and meetings behaviors.
We talked about roles so now let's talk about meetings. But before every thing else, you must know that Scrum want you to define with your team the definition of done (DoD). This means simply that you and the team must agree of what Done means. Said that, let go ahead!
Three of the most important meeting are Sprint Planning, Sprint Review and Sprint Retrospective meetings.
The first one is the one used to plan the what and the how requirements may fit the next sprint and must be attended for one hour for the what and one hour for the how. Mainly the time is based on how long are the sprints but usually 2 hours for this meeting are good enough for every kind of sprint time boxes.
Every one may participate but mostly Product Owner, Development Team and Scrum Master are the essentials.
During this meeting the Team goes throughout the product backlog and try to understand all items with the help of the Product Owner that will try to answer to all team questions. Then, a set of items will be chosen for the sprint the team is going to start. This is the What.
During the How, the team tries to realize the way they can complete those items and start developing an high level design of the product.
The output of this meeting is a Sprint Backlog.
Wow! So let's finally start this Sprint! We also know now which items we will develop for the rest of the sprint!
Once the sprint is completing, another meeting before completion is needed and is called Sprint Review. All stakeholders, the Development team, the Product Owner and the Scrum Master will attend this meeting. During this meeting, The team will show a product demo to all stakeholders, getting feedback from the business. This meeting must be facilitate by the Scrum Master to avoid misunderstanding from the Business and the Development Team. The meeting would last from 30 minutes up to 1 hour.
After this meeting another one must be attended but only for the Development Team and the Scrum Master. This meeting is very important and is called Sprint Retrospective. It helps to understand what is gone well and what is gone wrong. The input for this meeting is the output from the Sprint Review where all the feedbacks have been gathered from the business.
During this meeting the team must try to asses the items they have done well and those they haven't been able to complete or completed in a way the business didn't accept and the focus must be on the why thing went wrong. The discussion must be facilitate by the Scrum Master and must take from three hours to 1 hour long.
The output from this meeting must be the input for the Sprint Planning where a Sprint backlog get assessed and any items not completed or any new items added by the business must be taken into account for the next sprint.
Good! Now the Team knows what is going well and what's must be redefined, which are the next sprint backlog or items that must be accomplished during the next sprint.
But how the business, the stakeholders may know if the project is going in the right direction during the sprints? Well, Scrum does not provide lots of documentation for the business. All the documentation output from the team is only for development team purposes and they are called artifacts. They are Product Backlog, Sprint Backlog and improvements (Sprint Burn down chart). So how the stakeholders may know and act to address the project if any risk is in the air?
For this, Scrum model provides an important documentation that must be released for the business. This is the Burn up Chart, a chart with all the product backlog items with the information of what item has been “done” or completed and accepted, and which items must still be developed to satisfy the project goals.
Super! Now let me wear the stakeholder hat! I, as a stakeholder, am quite confident that things I requested may be improved shortly and before any release deployment I know I will have the opportunity to see something live and I may ask new improvements that will be handled by Product Owner and the Team in the next sprints.
So I feel peaceful about the fact something is going on and my product will be released as expected.
In fact, project success is not only a matter of doing things properly as any kind model or project management process state, but it's more something about management of skills and competencies. It's a matter of how well the requirements will be understood by the BAs and how well will be elicited from the business.
The most important focus on which project management usually focus are initiating and planning where most of the work get done with elicitation and analysis of the requirements.
In a Scrum model, the process of initiating and planning is iterative and must be something can get repeated in every cycle or sprint so it's really important to understand requirements for the next sprints.
So finally what I understand from this example is that a good business analysis is one of the most important key role in any project management model and that Scrum is one of most agile way to manage a project where feedback are needed frequently.
For most deeper understanding I would suggest one of the best Scrum guide I ever read, Do better Scrum, written by Peter Hundermark in version 3, totally revised and updated with lots of suggests and tips. Don't miss it!
www.scrumalliance.org/community/profile/phundermar
http://www.infoq.com/minibooks/do-better-scrum