Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
What, you may ask, is a ScrumMaster? Does the thought of becoming one sound good to you? Does it sound like it is not for you? Are you not sure? Aside from the role of Product Owner, this may be the most important responsibility in the Scrum team. But, unlike the name sounds, you do not need to be a 'Master' of Scrum to be a good ScrumMaster. In the opinion of ADTE, any team member can (and we feel should) become a ScrumMaster. The role can be a part-time one, so any team member can do it and still retain their skills and responsibilities. You will learn from the 'inside' what it means to try to keep an Agile team running at peak efficiency. You will gain exposure to the kinds of impediments we all face, plus gain experience with new ways to overcome them. A ScrumMaster, in our model, is a member of the team - not a separate role. Success of the team is their success and of course, failure is theirs to share, too. In this role you will not 'tell' the team what to do. You are not a 'boss'. But, you will be in a great position to show the team the impact of their work progress, help them make choices when the path forward is not clear, and be the team champion for Scrum and Agile. Each team must have a ScrumMaster. Agile guidelines suggest a team size of 5 to 9 individuals. That means most companies need many, trained ScrumMasters. That means that YOU should be a ScrumMaster! Also, try rotating this role across your project or platform team. Others will benefit, too. So, What does a ScrumMaster do, really?The ScrumMaster will be the one to be sure that all essential Agile steps are followed and that the Scrum tools are set up and used correctly. All team meetings, Storyboards, and Information Radiators, etc. are usually the responsibility of the ScrumMaster. But, none of these tasks is 'hard'. They are all important to the success of the team - and a few of the skills take a little practice. Set the Release Scope This may be done by the Project/Delivery Manager, Product Owner, and Business Analyst, together, but you should understand the importance and value of this step and be able to do it for your project, if needed. Once your project has completed the Feasibility phase, you should have a backlog of Stories which have been prioritized and estimated - some marked as higher technical risk - from which to select the work that will make up your first Sprint phase (the Risk phase). You may or may not have an idea of your team's Velocity, and if you are about to start Sprinting for the first time, it will be hard to estimate, but you must do so anyway. You will need to calculate the number of Sprints you expect that you can reasonably complete. If your release is time-boxed, you will set the release scope based upon a date. If the scope is fixed, you will set the date target for completing this release based upon your assumed Velocity times the number of Sprints to complete the total scope. This will allow you to assemble a target burn-up chart and as your Velocity stabilizes you will have a good indication of whether you will meet your dates (more on this later). Set a Sprint schedule The Project/Delivery Manager may have input into this decision, too, but the ScrumMaster should fully support this choice as the burden of enforcement falls squarely on your shoulders. The Sprint schedule is simple - it is the number of weeks allotted for each iteration (or Sprint) of your release and it determines the timing for all other team activities. SPE recommends small Sprint cycles (2 weeks) to allow for a more rapid response to change. Remember that this means that your User Stories must also be very small. SPE guidelines call for Stories that can be delivered in just one day. Schedule meetings All Scrum meetings are to be set up by the ScrumMaster… Backlog grooming Backlog grooming brings the Product Owner, BA, etc. together to re-evaluate and refine the backlog - always looking about two Sprints ahead. When the Feasibility phase was complete, all or most of the Stories for this next release were estimated. But, are they detailed enough and small enough for Sprint efficiency? Have new Stories been added? As the Product Owner and BA are working to finalize the definition and clarity of each User Story, you are looking to be sure that all these Stories are fully defined, estimated, fully broken down, and prioritized, so you have no doubt where to look when choosing Stories for your next Sprint. Be sure these meetings are being held regularly - often three or four days before the start of the next Sprint, to be sure you have the latest word on priority and acceptance criteria. Also, you will need to pull the Scrum team together in the next day for planning poker (or the like) if grooming has uncovered new priority Stories that must now be estimated. Sprint planning At the start of each Sprint, you must also set up the Sprint planning meeting which occurs in two parts… Requirements Workshop 1. The first part is attended by the full team, Product Owner and the Product Manager – this is when the Product Owner presents the highest priority backlog items to the team – there is a Q&A to ensure that requirements are understood. The team and Product Owner then agree on the Sprint goals/objectives. Sprint Planning 2. The second part of the session is usually only attended by the core team (no Product Owner, but ask them to remain close and available for questions). In this session the team will discuss the requirements, break the Stories into tasks, and finalize and commit to the Sprint scope. Story point estimation, if needed, is also done now. As a ScrumMaster, you should become very familiar with Planning Poker and Fist-of-Five facilitation. These tools can make planning a much smoother process. The Daily Scrum This "stand-up" meeting should lass for no more than 15 minutes and is attended by the entire Sprint team i.e. anyone that is directly involved in delivering the Sprint commitment. The Product Owner is there, but they are asked not to speak, except to answer questions that come from the rest of the Scrum team. As the ScrumMaster, you must be sure that each team member answers the three Daily Scrum questions: 1. What have I done since the last Scrum, 2. What am I going to do today (does this impact anyone else?) 3. Is there anything blocking me (or likely to block me) from delivering to plan? Any conversations deviating from the above three questions should be held until after the Scrum. It is your job to keep it moving. You also now own the impediments list that the team has reported and you will need to get the right people to address the blockage(s). If there are multiple teams on your project, you may attend a Scrum of Scrums each day or a few times a week to share progress and resolve impediments that come from other teams. Sprint review, etc. The Sprint Showcase (aka Demonstration) This meeting is attended by the entire team, the Product Manager and the Product Owner and (IMPORTANT) any key stakeholders with whom you would like to share your progress. The point of this session is to demonstrate the Sprint deliverables and to assess the product against the pre-agreed Sprint goals and commitments, plus get feedback from your key stakeholders on the direction of the project (actually - it is the Product Owner who 'owns' the relationship with the key stakeholders and who should be answering to them. Ideally, due to the level of collaboration and consultation already taking place between the Product Owner and Team during the course of the Sprint, this is not an ‘unveiling ceremony’ – there should be no big surprises. This is just a 'demonstration' to gain feedback from the larger audience. Please note: only 'accepted' User Stories are counted towards the team Velocity for that Sprint. The Sprint Retrospective The Retrospective meeting is attended by the team with the Product Owner. Retrospectives are for reviewing successes and share issues - agreeing upon ways to make things better or keep them going well in the next Sprint. Similar to the daily Scrum, they are based around three (main) questions: 1. What went well last Sprint? 2. What didn’t go so well last Sprint? 3. What are we going to do differently next Sprint? Hopefully you will use these sessions to be always more clear as a team about what you are working on, how you are doing, and where the product is going. Embrace change and the lessons learned each Sprint. Be a team player! It may seem self-evident, but the ScrumMaster must truly represent the "team" mindset. They must foster an environment where creativity and empowerment can flourish, setting an example for others by their cooperation and supportive approach. The key to success in Scrum is communication (over documentation). We want our entire Scrum team to work together, sharing the work, and never pointing to others to do "their" job. It is central to Scrum that every job is "my" job. You can help to facilitate that spirit in the team. Article SummaryBeing the ScrumMaster for your Scrum development team is not as hard as it may seem, at first, and it becomes easier the more you do it. Everyone on a Scrum team should consider taking a turn as the ScrumMaster. The ScrumMaster sets up and holds all meetings in the Scrum schedule and leads the team by example. They do not "lead" the team, though, and they are definitely a part of the group. They provide the structure and stability a team needs and take responsibility for daily impediments, Scrum reporting, and enforcing the methodology. Being a ScrumMaster is a great way to discover more about how we work and what it takes for a project to succeed. You are an ally to the customer (Product Owner and BA) and a member of the team, so you are in a unique position to see the project from both sides. The key is to communicate, which you can help to facilitate, and to build a supportive environment where each member of the team feels empowered, heard, and is able to contribute directly to the project's success.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorPaul Berryman is a passionate application development leader who has earned the title of champion of Agile and DevOps methods and tools for enterprise development teams Archives
September 2014
Categories
All
(c) 2016 - Agile Down-to-Earth All rights reserved |