Agile Comes To You
•Descargar como PPTX, PDF•
1 recomendación•555 vistas
Agile Comes To You - The Benefits of Agile and How to Avoid Common Pitfalls. By Justin Bell.
Recomendados
Recomendados
Más contenido relacionado
Similar a Agile Comes To You
Similar a Agile Comes To You (20)
Más de Credera
Más de Credera (14)
Último
Último (20)
Agile Comes To You
- 1. Agile Comes to You Justin Bell presents The Benefits of Agile and How to Avoid Common Pitfalls September 27th, 2011
- 2. Phases of Agile Adoption … Today we’ll talk about the benefits & common pitfalls companies face as they move through the phases of Agile Development adoption braveheart on Flickr bashed on Flickr tallkev on Flickr Just learning … Dipping toe … Trying (HARD) … Enjoying it …
- 3. Benefits of Agile … There are many benefits of Agile development – but it is often confused with just removing the planning and documentation from other methodologies.
- 4. Benefits of Agile … Improved Visibility & Tracking … We’ve all seen something like this before: The project appears right on track, with no indication of issue until … gamp on Flickr Month 1 Month 2 Month 3 Month 4
- 5. Benefits of Agile … Improved Visibility & Tracking … With Agile it’s easier to get a true status and avoid the late project surprise.
- 6. Benefits of Agile … Task Management & Tracking … In traditional development models the PM is often lost and stuck with few options other than “management-by-walking-around.”
- 7. Benefits of Agile … Task Management & Tracking … Well-organized agile teams utilize a task board or online tool to manage task assignments, issues, and progress.
- 8. Benefits of Agile … Estimation & Planning … Project estimation & planning is one of the biggest failures in traditional software development. Agile can help. © Scott Adams, Inc./Dist by UFS, Inc.
- 9. Benefits of Agile … Estimation & Planning … Team estimation can be very time consuming and is often corrupted by “anchoring” when one team member heavily influences estimates. 1 3 Jon thinks he knows exactly what to The Project Manager or Product Owner kicks do, so he says “3 days!”, making Bob and off the Sprint Planning Session. Mary doubt their initial estimates. How 3! ? ! ! long? Michelle Jon Sarah Bob Mary 2 The team thinks about the backlog item being discussed. 4 Sarah then asks for the remaining (and now skewed) estimates. 3 ? 1 8 3! ?3 13 85 Jon Sarah Bob Mary Jon Sarah Bob Mary
- 10. Benefits of Agile … Estimation & Planning … Planning poker is an iterative approach to estimating items in the product backlog intended to reduce anchoring and wasted time. kraemer on Flickr
- 11. Benefits of Agile … Estimation & Planning … Planning poker is an iterative approach to estimating items in the product backlog intended to reduce anchoring and wasted time. 1 3 Michelle then asks everyone to flip the The Project Manager or Product Owner kicks card representing their estimate. off the Sprint Planning Session. How 3 ? 1 8 long? Michelle Jon Sarah Bob Mary 2 The team thinks about the backlog item being discussed. 4 Now the team can have an unbiased discussion regarding the differences. 3 ? 1 8 3 ? 1 8 Jon Sarah Bob Mary Jon Sarah Bob Mary
- 12. Common Pitfalls … Agile is great, but there are some very common pitfalls that many teams fall into as they adopt agile. yanivG on Flickr
- 13. Common Pitfalls … Agile isn’t necessarily “faster” development, but it does make development more predictable and minimize wasted effort. kraemer on Flickr
- 14. Common Pitfalls … There are still many times that dates and scope are determined outside of an Agile process – and the team is left to deliver the project kraemer on Flickr
- 15. Common Pitfalls … Good communication is critical to good agile. Don’t let the product owner, QA, and the development team work in silos. lu6fpj on Flickr
- 16. Common Pitfalls … Be careful not to fool yourself kraemer on Flickr
- 17. Common Pitfalls … For agile teams to be effective, the product owner must be heavily involved in the day-to-day activities and be empowered to make decisions. loop_oh on Flickr
Notas del editor
- Thank you. I’m excited to be here today with a chance to talk with you about Agile and learn about some tools later on that help make our lives easier. I’ve been doing software development for about 12 years and learned about Agile by name about 7 years ago. I got very interested in it, starting reading about it and incorporating some of the concepts into our projects when I could. I’ve been fortunate to get to witness and be a part of many different Agile projects over the last 7 years and look forward to sharing some of my experiences – both good and bad.
- So you’re all here because you and your organization are in some way interested in Agile and improving your software development processes. You each probably fit into one of the four buckets I’ve got up here on the screen and all of my clients have over the years. Each stage has its own benefits, challenges and pitfalls. By a show of hands, how many of you are in the “just learning” phase? Dipping toe and maybe trying it on a small project? Trying Hard – usually meaning your whole department / organization is saying you are doing Agile, but the kinks aren’t worked out yet? And how many are doing it and feel like it is a well-oiled machine?
- This is obviously an exaggeration, but not all that uncommon. I’ve seen many organizations that “go Agile” just by no longer producing requirements documents and project plans and calling the PM a scrummaster instead of a PM. That’s clearly not the intent for Agile and is really just a reckless and unpredictable way to do software development.What are the reasons you are “going Agile” or went Agile if you did it long ago? What benefits are you after?
- One of the problems I’ve seen many times with a traditional SDLC is a project status that shows green all the way through. At the ¼ mark of the project, based on duration, you can be sure the project status report will show 25%. At the ½ mark of the project, 50% and at the ¾ mark, 75% - but then, when you are truly into development and running into the real issues that have existing all along projects have a tendency to stall and you see that getting that last 25% of the project done takes 75% of the overall time. The project goes over-schedule and over-budget and worse yet, it is a surprise to executives.
- With Agile, you start completing the actual work, end-to-end very early in the project and so encounter and resolve issues as they come up instead of postponing those risks. You can then use visual tools like a burn down chart to show your true progress and indicate that there may be a problem while there is still time to resolve it.
- Another common problem I’ve seen in more traditional development organizations is that the project managers, while dutifully trying to update their project plans and status reports have to make the rounds, asking each developer what they are working on, if it is done and what else needs to be done to complete something in their project plan that is called “Develop the Checkout Flow”. I’ve been on both ends of this role before and they are both frustrating. As a developer, you feel like you are being micro-managed by someone that doesn’t understand what you are doing. As a PM, you’re just doing your job and trying to keep up with the status of the project and don’t have any other way to understand task-level status and how that relates to larger items in a project plan.
- So, you see a lot of Agile teams implementing task boards, kanban boards or some online Agile management tool to help with this. This team used note cards to represent each task, which was broken down from each user story in that iteration. It is easy to see exactly what each person is working on, the current status of all tasks / user stories and in a glance get a feel for how we are doing for this iteration. For example, if you look at the board when you are ¾ through a sprint and see most tasks are still over to the left in TO BE DONE or IN PROGRESS – you know you’re in trouble.
- Another very common problem in software development is estimation and planning. There was a large survey done recently that studied thousands of IT projects and over 70% either never completed at all or were completed significantly over schedule and budget. Part of that problem is caused by the scenario depicted above – but not all of it. Even when teams are given proper time to estimate they often miss it big. Agile gives you a couple of tools for this. First, something we haven’t talked about. Because you track velocity in Agile and you get regular feedback on your actual velocity compared to your estimates – you should have a much better idea what your true velocity is and whether or not you typically over or under estimate certain types of tasks. Another problem depicted here is one person (usually PM or lead developer) giving the entire estimate for the work the team will do. Think about asking someone how long it would take to run a mile. Wouldn’t it be much better to ask the actual person who will be running it and get feedback from others on weather conditions, uphill / downhill, etc. There is a great process called Planning Poker that is popular among Agile teams.
- Planning poker is a collaborative estimation technique that helps to minimize the impact of anchoring or group think.
- With planning poker, you use a physical set of cards – typically labeled with the Fibonochi sequence up to 13 and then on big increments after that (because you don’t want to be debating the difference between 10 and 12 days for an estimate. Instead forcing things to be 8 or 13, 21, etc.).
- With planning poker, each team member “votes” at the same time – eliminating the anchoring effect. Significant differences can then be discussed.
- So far, we’ve talked about some things Agile does well and really helps us with. Now lets shift focus to some common problems I’ve seen in different organizations as they try to be Agile.
- The first pitfall is an organizations understanding of Agile. Just like in traditional project management, proper expectation setting is very important up front. It is important to educate your teams, peers and supervisors what Agile is and what it isn’t. The best way I’ve found is through piloting Agile on a small initiative and then beginning to roll it out to other projects and departments.
- Even though you’re using Agile – there are many times you still get backed into a date and scope. There isn’t much that can help with this, but I have seen organizations that do a good job with Agile seem to develop a more trusting relationship between management and development teams, so when dev says “we can’t do that” management listens and doesn’t just try to steamroll them.
- Communication is important in traditional software development also, but the documentation and processes do help you even if your team isn’t communicating perfectly. With Agile – great communication and collaboration are a must. I recently witnessed a QA team that stopped coming to the daily scrum and participating in the weekly demos and then at the end of the sprint said “What requirements are we supposed to test?”. The team then had to try and document a month’s worth of conversations and feedback between the developers and product owner so QA could know what to test – this was not Agile. The full team needs to be involved throughout. Now this doesn’t mean that your daily scrum needs to involve 40 people, including every QA analyst, lead and manager – but it does need to involve the key players from dev, QA and product management.
- We talked earlier about how Agile can give you improved visibility and sense of true status. This only works if you provide an honest assessment of where you really stand – without any smoke and mirrors. If you are calling something “Done” it needs to be able to be run without a bunch of caveats, fully test or at least testable and be vetted by the product owner to make sure it generally meets expectations.
- One of the benefits of Agile is that is gives you great flexibility to make adjustments based on actually seeing software work and knowing the true status of a project. For that to be effective, the product owner needs to be heavily involved in the project so that they know the status of items, can field questions and can give feedback. They also must be empowered to actually make decisions on usability, requirements and scope. It can’t always be a “well – let me check with so and so”. It can’t be someone that struggles with making timely decisions and you shouldn’t use flexibility as an excuse to continually change your mind and never really make progress.