How a team interacts and progresses on a project is important. How the product is developed is important as well. These two statements are the focus of why Agile project management was created. The creators wanted a new way of thinking that put the customer at the forefront of the thought process as well as how the team progresses throughout the project. I have been discussing in a previous post about scrum as a framework within the agile thinking.
There are many facets and underlying themes to understand in scrum. This is probably why a scrum master role (I will explain this role shortly) is important to any development team. There are a lot of under-utilized or misunderstood facets in this framework style, so it is important clear the air.
This is such a complicated topic that I decided to break apart the discussion into more than one post. Mostly for my own sanity because I am trying to understand it as well as writing about it. This week I will discuss three more parts of scrum development: Roles, team meetings and .
My previous post discussed the roles, so here I will refresh our knowledge of them and add a little detail. In scrum there are three roles within each development team; the product owner, the scrum master and the development team. These are not job roles, rather empirical roles that describe the key responsibilities.
The product owner is the team leader. He/She will set the objectives and value targets for the project. They must balance the customer needs with the business needs and manage the workload for the team. This means they monitor the pace of the project and help problem solve issues that prevent progress. Not necessarily leading every meeting or assigning every task though. A product owner manages the backlog of work and assigns work to the team, but is not the whip, he/she is simply managing the what needs to be done. He/She also works with the stakeholders in order to ensure the team is delivering value on the project or meeting the objective. The final important task for the product owner is to release material for feedback and customer response. There will no always be something to deliver, so that means managing forward and planning for those events.
The scrum master is the expert on all topics related to scrum. They are also like the coach of a sports team. He/She will help lead/facilitate meetings, chip in on work where needed and in general keep the project going by making sure scrum is practiced in a productive manner and the team is happy. The scrum master could have a very big job and need to be everywhere at once. They are the advisor and the worker. A good scrum master will be able to assist, lead and contribute all at once without assuming more than he/she can handle. Some teams assume that the product owner and scrum master are the same role. While both roles share leadership responsibility, both have separate areas of focus. The product owner balances the internal and external needs, while the scrum master maintains the team and project needs.
The final role is the development team. This is the role that does the bulk of the work on the project. After the the product owner sets the scope and goals for the sprint, the team will then decide who and how best to get the work done. The team needs to be self-sufficient and self-starting. While the scrum master and product owner can assist in balancing the workload or ensuring smooth continuity of process, the dev team individuals must be the ones to decide what they can accomplish and how. They utilize daily “scrum” meetings to discuss to talk about wins, roadblocks and any adaptations needed to proceed. They need to provide transparency in their work and methods otherwise the team cannot help provide feedback or support where needed. They work best when the entire team contributes and offers assistance and adaptive methods throughout the sprint.
There are a few different types of meetings that can be held throughout and at the end of project sprints. Each has a different purpose and scope. In Agile lingo a meeting may also be referred to as a “ceremony.” Here is a brief rundown of the predominant scrum ceremonies.
Sprint Planning — This is the big one at the beginning of a sprint. The team discusses what needs to be and what can be accomplished during this sprint. This meeting cannot be successful with the dev team and the product owner. Both are needed to agree on the details of the sprint. There are a few parts to this meeting that sets the tone of how it will progress.
First is the objective of the sprint. The product owner will state what needs to get done in this timeframe. The team then decides how they will accomplish the task. The second part of this is a continuation of the first, how will they accomplish this. The team and product owner will need to decide these details together so that the sprint is a harmonious time of progress. Third states who will be present. In order for this planning to be successful the dev team and product owner need to be present. Fourth is a look at what will be going into the sprint in the form of inputs. What tools, ideas, artifacts are needed to complete the sprint. Last is the expected outputs of the sprint. What is the value or deliverable expected at the end of this. How will they get there and what will be the resulting output are the focus.
Sprint Reviews — This is an end of sprint discussion that celebrates the successes and the team performance during the process. It is primarily a morale boosting meeting. It is best thought of as an end-of-iteration happy hour. Focus on what was done well, what you learned or how the team performed positively and so on.
This should be a positive experience for the team. If not, it can signal some imbalances in the iteration backlog structure or needed improvements on the technical knowledge. This will need to be addressed in the next iteration or project start to avoid the pitfalls experienced before.
Standups — A daily meeting for the entire team to discuss their work. This is like a brief synopsis of what is going on in the team each day. All team roles are invited to this meeting in order to enhance transparency. One by one, team members will standup and inform the team on three items:
1 what they accomplished the previous day.
2 What they will work on this day.
3 What blockers they may experience.
These questions can help the team identify process failures, showcase the progress being made and helps with transparency because everyone sees the contribution made by others.
Retrospectives — This is the meeting that brings to light issues and blockers to progress. One of the tenets of Agile development is adaptation and growth. This means that a team should work to learn from mistakes or shortcomings and improve performance for the next round/iteration. When looking at how to improve, Atlassian recommends the following:
1 Individuals and interactions over processes and tools.
2 Responding to change over following a plan.
These make up the backbone of team meetings within the scrum method. They all help support the tenets of Agile project management by supporting the team in two ways: Encourage a customer-centric project development platform and encourage adaptation and team growth through iteration and multi-disciplinary collaboration. This still leaves the door open to an expansion of meetings and collaborations among the team. Some teams opt to add or edit their meeting styles to be conducive to their organizational style. As long as the core tenets and spirit of Agile remains intact, this can still be beneficial to the development of a product.