Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
SCRUM Agile maximizes the power of teamsIn Scrum Agile you see that the ‘team’ is the core of any project. This article discusses the steps, principles and skills required by the members of the Scrum team as they enter the iterative or "Sprint" phases of the project. I will assume you have some knowledge of Scrum Agile practices, so many details will be left out, but I do repeat some of the basics below, so please be patient if you already know this. This article is focused on Scrum team members. If you are a project manager, delivery manager, etc., this may not answer all the questions from your point of view, so feel free to peruse my other articles, but you should read this, too. Scrum Agile is a team-based approach to project development, and it agrees with the saying that if we do not pull together, we will most certainly pull apart. You will find that Scrum methodology works best when the team follows all practices fully and honestly. Agile is a self-correcting process when it is followed faithfully. If you understand Scrum, respect the team, and commit yourself to your role in it, you will help to deliver the best IT experience for you and your team and make it more likely that you meet or exceed your customers' expectations. So, I am on a SCRUM team. Now what?Success as a Scrum team member will come from understanding your role, contributing fully to planning and retrospective exercises, communicating openly, and committing to the success of the entire team. To have this success, you must be committed, and not just involved. Although this is not always the case, the Scrum team begins their work usually after requirements have been prepared to the point that they are ready for a team to build, test and deliver them. Sprint planning Your first responsibility as a member of a Scrum team during the Sprint phase(s) is to understand the deliverables in general, and to understand the User Stories proposed for the next Sprint, specifically. Every team member must actively take part in Sprint Planning. This meeting is held on the first day of each Sprint (every 2 weeks, usually). At times this can be a long meeting, so your commitment, patience, and support are essential. You will meet with the Product Owner to fully understand any stories or new priorities proposed for this Sprint. Then, the team will meet alone to discuss the solution, estimate the size of any new stories (story points), and then add all tasks and hour estimates. NOTE: Scrum uses a technique for story sizing called Planning Poker, so please get familiar with this. Once the team has chosen a set of stories for the next Sprint, they are fully committed (see above about pigs & chickens). Each team member has responsibility for Sprint success. Story size Each User Story that the BA and Product Owner have created needs to be small enough to be completed in just one Sprint, including analysis, development, QA and acceptance testing. That means it is all done in as little as two weeks. Again, smaller is better. In fact, Agile Down-to-Earth calls for stories to be delivered in only one day. Small stories are easy to understand and complete. If the story you are reviewing is too large, you must ask for it to be broken down into multiple, smaller stories. That is the team's responsibility. Sprint Zero? A note about a concept called Sprint Zero. Commonly, there is a slight variation of the Sprint plan for the first Sprint in a release. If there are technical activities that must be performed before the Scrum team can execute their usual Sprints, these tasks are done as Sprint Zero and these efforts are not recorded toward the team velocity or toward reduction of User Stories. Note: There is no time box for Sprint Zero - you are done when you are ready to begin Sprinting. Teamwork There is almost no way to over-emphasize the importance of teamwork in Agile development. The BAs, developers, QA, Product Owner, all need to work as a unit, or identify what is holding the team back and address it. Your full commitment to the health of every member of the team is one key ingredient in Agile success. This can go as far as possible - if your teammate is over-worked and you are able to help… then do it. In our opinion this goes across role boundaries. Developers can and should help QA, BA's should help the ScrumMaster. Everyone needs to pull on the same rope if they are available. Daily Scrum Scrum Agile is named for the rugby pile-on that starts the ball moving. Everyone is connected, and they move as a team. This is the spirit of the Daily Scrum meeting. This stand-up meeting lasts for no more than 15 minutes (that is why we call it a stand-up meeting - there is no need to sit if the meeting is held swiftly, as is desired) and is attended by the entire Sprint team. It is how you get the ball moving every day. The Product Owner should also join (but they are asked not to comment) to answer questions that come from the team. Each team member answers these three Daily Scrum Questions:
Demonstration The output of your Sprint is supposed to be one or more potentially shippable products (PSPs), also known as potentially shippable increments (PSIs). You may not actually push this increment to production, but you should be able to, if you want to. You must be able to complete all development and testing in as little as 2 weeks. And, at the end of that time, you show the Product Owner and other key stakeholders what you have built, and use this as a key means to get feedback, priority, and re-direction of the project. Retrospectives Another important meeting is held at the other end of the Sprint. It is called the Sprint Retrospective, and it can be the most valuable meeting to your team's success. It is attended by the team with the Product Owner and other key stakeholders. Retrospectives are for reviewing successes as well as mistakes or inefficiencies and 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:
Speak up So, in addition to teamwork, it is essential that you talk, listen, and talk some more. The team needs your feedback and opinions. Communication works when we all share our ideas, opinions, concerns, and plans openly. What's your Velocity?As you complete a few Sprints, you will begin to discover how many story points your team can complete in one Sprint. This is your team Velocity. It is the benchmark you will use going forward for deciding how many stories to commit to for the next Sprint. Technical stories?? One more note directed especially at the development members of your Scrum team. You will find from time to time that you need to do work that is purely technical - like set up a new database - that seems not to belong to any one User Story, so you will be tempted to create your own "story" for this work. In general, our guidance is "Do not do it." A user story is just that - created by a user for their benefit. Technical work is created by IT for the benefit of IT. First, we should be able to anticipate most technical work before the Sprint phase is begun. That is what we use Sprint Zero for. Later, we can use a "Synchronization Sprint" to do technical work that needs to be completed before more sprinting is possible. Article SummaryTo succeed as a team member in Scrum Agile you must make a simple commitment to teamwork and following the Scrum life cycle. Everyone pulls together if the team is to succeed, so look at your own job, but also the work of others and help wherever you can. Be open and honest in your daily status and other communications and let others hear your opinion. Use the Sprint Retrospective to continuously improve but never use blame as an excuse for failure. If one fails, the team fails. So, always focus on what can be done better next time. Ask questions the moment you do not fully understand a Story or Task, because you are fully committing yourself to every Story that is included in the Sprint, so do not let the team move forward if you do not understand how to get to your destination.
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 |