Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
How can you guarantee success in your Agile projects? You cannot. But, there are a few key ingredients that the most successful Agile projects all share, and this article will focus on those delivery best practices. The Agile methodology was created and should be adopted with three core benefits in mind (among others). They are:
Success with Agile is not hard, but it does require a fresh look at product delivery. There are things that each member of the project team – whether manager, analyst, architect or engineer can do to maximize efficiency, build sustainability, and drive quality into your projects.
Gain more predictable results by applying them all to your delivery projects – you may be surprised at your results1. Engage the “real” customer This may be a challenge in your project. All Agile requirements should come directly from a business representative that will be using the software once it is delivered. This is an important point. The role of Product Owner in Agile is to be filled with someone who has a vested and personal interest in the success of the software. If you are going to ask an actual user to make the time commitment to your project, you should be ready to help by doing the second key step – keep your releases small and the time commitment will be easier to manage. 2. Deliver in small releases When was the last time a full-size project was completed in six months or less? It is not very common. That is why in Agile we talk in “releases”. It may take two years to deliver a complete major project, but valuable software should be delivered to the business in small and manageable chunks. And, we should not deliver the easiest or the simplest things first. We must deliver whatever is most valuable to our customer, first. That is Agile’s RISK focus. We take the risk out of the project by delivering the most valuable and difficult things first, so that even if funding or priorities change, what is in place has real value. Following this logic, each subsequent release should become easier to deliver, and make it easier when requirements change to deliver new challenging functionality on time. Keep your releases to six (6) months (from Feasibility through Realization), then do it again and again. 3. Create a team focus Top-down management of the project participants can hinder or prevent some of the biggest benefits of Agile. Self-dependent, small, cross-functional teams are an essential part of the Agile method. Agile teams must be five (5) to nine (9) individuals who have all the skills to code, test, and deliver working software. Larger teams get bogged down and cannot move swiftly enough for Agile to be fully effective. Each team must work as a single unit. The team must know that they are empowered and trusted to make their own delivery commitments. Managers must support them. In Agile it is the team that sets the scope for each Sprint by selecting all of the priority stories that they can deliver (not more, and not less). Each team member must “own” this commitment. Roles on the team are far less important than getting the work done. Create all tasks for this Sprint as a team and attend all Scrum meetings together. Work together as a team, and never say it was “their job.” Coders can test and testers can complete acceptance criteria. The method is called ‘swarming’. Everyone works together to complete one or two stories at a time. The goal is to get the stories ‘accepted’. Nothing else should matter. The team takes on the commitment and learns together what works and what does not. 4. Learn from every Sprint There is no room for blame in Agile. If a Sprint did not go well, the goal for the whole team is to learn from the past. The final day of each Sprint must include a Sprint Retrospective. The best project teams always have one – and obey the guideline that blame is not the point. As a team, review what went well and what did not. Discuss what should be repeated and reinforced, and then discuss what should be changed. The key is to act on your findings, so make sure the planned change is achievable. Learn from your findings and apply them. Share your findings with your Delivery Manager and ask for their help to make the change. 5. Use information radiators During and after every Sprint, there are tools to show the team how things are going (or went). There are four (4) key information radiators available to all users of VersionOne (see VersionOne details below) that should be shared - some during every Scrum and others at the Retrospective. They are: Daily radiators:
Display your Daily radiators during the Scrum meeting! This meeting is to be as brief as possible, but it should also be a time to recognize minor issues and opportunities as a team. Sprint Burndown - This is a chart of the work hours consumed and remaining by your Scrum team. Using this chart, you can evaluate whether work is proceeding as planned, or if task estimates were too high or too low – such as finding more work to be done than you evaluated during Sprint Planning. Cumulative Flow Diagram - This is also a daily chart that shows the “status” of all User Story Points selected for this Sprint as it moves from In Progress to Accepted. The goal for the entire team is to get Stories to Accepted, but not all the Stories at once. Agile asks the team to “swarm” on a few Stories and get them Accepted, then take a few more. The Cumulative Flow diagram shows our progress and helps us recognize when Stories are blocked or stuck for some other reason. Only choose Stories that you believe you can finish, and finish the Stories that you choose – even if everyone has to stop what they are doing to get over a hurdle on one Story. We also use Sprint radiators to visualize our progress in the Sprint and across the Release project. Velocity Trend - This chart shows how many Story Points we completed (were Accepted) in each completed Sprint. Over time, this shows our team’s Velocity. Typically, we average the total points completed over the past three (3) Sprints to set our Velocity for the next Sprint. By knowing our Velocity, we can better commit the correct number of Stories during Sprint Planning. Release Burn-up - Over time, this is an excellent predictor of our actual finish date for the current Release. This chart shows Story Points completed by Sprint (Sprint end dates). Using total Story Points in the current Release scope, and the accumulative points completed to-date, a Trend line based upon our current Velocity shows when (Sprint end date) we will complete all our scope. Use this chart to support budget or schedule discussions with your customers and teams. 6. Sprint when it is time to Sprint As you can see from above, one of the key indicators of our progress is the team Velocity. To achieve your maximum velocity, teams should be dedicated to the Scrum project, and work that is not required to deliver User Stories in the current Sprint should wait. In other words, work at full speed to deliver the User Stories that you have committed to in the current Sprint and do not let anything distract you. Article SummaryThere are certain aspects of Agile that have a greater impact on project success. While all of Agile is important, you will find the most successful Agile projects successfully dealt with six (6) key factors. Paying attention to these factors helped to drive their project success. Failure to attend them can be a common reason for unsatisfactory results or a demoralized project team.
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 |