Secrets of Agile

Editor's Notes

• #2: A lot of people only focus on the big visible parts of agile. Daily standups and post-it notes. There’s a lot more beneath the surface!
• #3: Agile should be thought of as more of a mindset or culture than a process. A lot of people get lost in the process aspects of transitioning to agile and they lose sight of the goal. Moving to agile requires a major shift in thinking for most people. The goal isn’t to follow an agile process, but to consistently deliver value to your customers and users.
• #4: Agile is hard. Agile will not solve all of your problems. If anything, it only makes them more visible and obvious. We are not perfect at Agile. The beauty is that there is great value without being perfect at it.
• #5: Need to understand everything before starting. No feedback from customers beyond initial research. Information flows one way. No easy mechanism for changes. They are expensive. Software systems tend to evolve.
• #6: We used to think that we had to specify everything up front before we even wrote the first line of code.
• #7: Traditional software was built by teams working in silos. They only really care about getting the work in their “silo” completed and passing it on the the next team. Some teams actually work in separate locations.
• #8: Releases were big, only happened once or twice a year, and someone usually got hurt.
• #9: That works well if you are manufacturing parts. It assumes that you understand the customer’s needs and know the exact solution.
• #10: Studies in the late 90’s early 2000’s show that anywhere from 70% - 80% of projects fail under waterfall.Canceled, Delayed, Over budget...
• #11: In February 2001, 17 software developers met at a ski resort in Snowbird, Utah, to discuss lightweight development methods. 2 things came out of that weekend: Agile Manifesto 12 principles
• #12: We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value the things on the left over the things on the right. That is, while there is value in the items on the right, we value the items on the left more. When there is conflict, the values on the left win.
• #13: Agile methods prefer to define themselves in terms of "values, principles and best practices," rather than as "processes and procedures." The following are some of the most important principles
• #14: The most important principle of Agile Software Development. Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (think weeks rather than months)
• #15: We embrace the notion that requirements change, unexpected requirements appear, priorities shift and development practices must enable quick, accurate adaptation to these changes. How many times have you heard someone say, “That is cool - but... what if it also did X?”
• #16: Agile methods attempt to establish a high level of collaboration among developers and project stakeholders. We need to understand what we are building, who we are building it for, and why?
• #17: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Those doing the work make decisions about how to do it. Drive tactical decisions down to the team. Dan Pink - Drive (Autonomy, Mastery, and Purpose) Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity. -Patton
• #18: Collaboration amongst team members is vital. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Builds a shared understanding!
• #19: The “working software” should be demonstrated regularly to team members and stakeholders. Collect feedback “early and often”. Be suspect of teams that are not willing to demonstrate their progress. If you aren’t building software then, you should deliver something of value to customers.
• #20: Teams should work at a pace that they can sustain indefinitely Teams are more effective and productive if they work at a sustainable pace. Many studies done around teams that work more than 50 hours a week.
• #21: Continuous attention to technical excellence and good design enhances agility. Promote solid design principles, developer testing (TDD), peer review, refactoring, etc. Work to reduce technical debt.
• #22: Simplicity--the art of maximizing the amount of work not done--is essential. Ask the question of whether or not you really need something? Do we need big up-front design? Work to optimize the teams workflow and eliminate unnecessary activities and deliverables. Foster a culture where it is OK to question the value of a particular process or activity.
• #23: Teams should be empowered to focus on doing whatever is necessary to deliver the features. Encourage teams to swarm on tasks that need to be completed even if it puts them out of their comfort zone.
• #24: Break things down into small pieces that can be worked on iteratively. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Iteration length is fixed. Every Iteration is a mini increment of the functionality and is build on top of previous iteration.
• #25: Always strive to improve. Constantly look at how we are doing and ask “What could we do to be better?” At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile is not a destination - you have to keep working at it.
• #26: This is often referred to as the “waterfall” software development process.
• #27: The new way is iterative.
• #28: We build “potentially shippable” features every iteration.
• #29: We work in iterations called “Sprints”. We have a prioritized backlog that we pull from to build new features each sprint.
• #30: Instead of silos, team members work closely together
• #31: Releases are smaller and more frequent
• #32: Customers are happy and no one gets hurt!
• #33: How common is agile? Are big companies using it? YES
• #34: 75% of all agile teams are using Scrum or a Scrum hybrid process Word cloud based on the Version One “State of Agile” survey for 2013.
• #35: The name comes from the sport of rugby, where a scrum is the mechanism for getting the ball moving after it has gone out of play. Rather than a full process or methodology, Scrum is a framework. Scrum is not very prescriptive. Scrum, in a nutshell, is a very light framework for delivering real products early, often and consistently. The products can be anything: new processes, software, physical products, or running an operation (like a business).  It’s a “thing” that teams within corporations “do” — a new and better way of working.  And it’s a great environment for helping teams move toward high performance, for real. Scrum actually calls teams forth into high performance and it calls the organization around teams to get aligned around the most important, highest business value items to create — one after the other.  And those items get created within a short period of time and with high quality.  It’s a way of aligning expectations with outcomes.  In short, it helps teams deliver to a delighted customer. Every time.
• #37: The Product Owner Team represents the business, customers or users and guides the team toward building the right product. Maximizing the value of the work the scrum team does
• #38: The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. Responsible for ensuring that the process is understood and followed. Watches for stress points!
• #39: Designed to optimize flexibility and productivity. Typically 5-9 people. Team picks picks the work to do each sprint. Decides on what and how much.
• #40: Agile requirements. User Stories are high level descriptions of what the user would like to do with the system. Just enough info to estimate the relative size; Drives conversation around the feature at dev time. Shifts focus from writing to talking. Often captured on index cards or sticky notes to emphasize their “placeholder for conversation” nature.
• #41: Product owner creates a backlog of features and captures them as “User Stories” User Stories are high level descriptions of what the user would like to do with the system. Just enough info to estimate the relative size; Drives conversation around the feature at dev time. Shifts focus from writing to talking. Epic, Theme, User Story Often captured on index cards or sticky notes to emphasize their “placeholder for conversation” nature.
• #42: Work in short iterations called “sprints” Most common is 2 weeks Sprint PlanningBreak things down into smaller pieces Definition of “Done” Stories completed are “potentially shippable”.
• #44: Ceremonies of Scrum: ~15 minutes - same time every day. Synchronization meeting. Not for solving problemsNot a status for Scrummaster! Commitment to peers. This is so each person has a clear understanding of what is going on. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus.
• #45: Ceremonies of Scrum: ~15 minutes - same time every day. Synchronization meeting. Not for solving problemsNot a status for Scrummaster! Commitment to peers.This is so each person has a clear understanding of what is going on. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus.
• #46: Look at real software. The purpose is to demonstrate progress and gather feedback
• #47: Look at real software. The purpose is to demonstrate progress and gather feedback Anyone can attend.
• #48: Used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable. Look at both what is and is not working. 30-60 minutes. Whole team participates (ScrumMaster, Product Owner, Team)
• #49: Used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable. Look at both what is and is not working. 30-60 minutes. Whole team participates (ScrumMaster, Product Owner, Team) Start, Stop, Continue
• #50: Sailboat Retrospective Exercise Winds= Propel us forward Anchors= Hold us back Icebergs= Obstacles to look out for and avoid
• #52: Humans are horrible at estimating how long it will take to do something. Ask my wife! How tall is the Empire State building? Most people can agree that it is twice as tall as the building next to it, but I bet their estimates in feet would be all over the place. Story points are a form of relative sizing. Scale is different for each team Only used for planning purposes.
• #53: We measure the velocity (avg. points completed each sprint) as an empirical tool to help us plan for how much we can accomplish in the future. Should NEVER be used as a measure of productivity. Teams will game it and it will become useless.
• #54: This is how we do release planning for a team with a velocity of 14 story points.
• #55: Some charts for measuring progress during the sprint.
• #56: Velocity is 13 points for this team.
• #58: This is the rate they need to close stories in order to hit their goal of 13 points.
• #59: Points are tracked for each work day. Completed 3 story points on 2/20
• #60: 0 points completed for the next two days
• #61: 6 points were completed on 2/25
• #62: Above the line is good
• #63: Below the line means the team is behind. It’s not uncommon to be below the line early in the sprint.
• #64: Cycle time is used to track the average number of days to complete a story. Lower numbers are better. This is useful for many reasons. One is that is encourages you to break stories down into smaller chunks and deliver value more frequently.
• #65: We use a Product Owner Team board to track user story discovery, planning, and estimation activities.
• #66: We survey the team periodically to gauge their satisfaction with how the team is functioning.
• #69: Agile is being used in a lot of different industries outside of software. The following are all articles on how it is being used in different companies.
• #70: Agile as a parenting tool
• #71: Eric Nuzum from NPR says programs using Agile have been developed for 1/3 of the usual costs.
• #72: Jonathon Colman from REI is using it for marketing
• #73: Agile as a tool for families
• #74: I use it at home myself. Here are my two oldest helping me with our weekly retrospective. We talk about what went well the past week, what didn’t go as well, and what we want to try next week. They feel more engaged and invested in these things if we let them participate.
• #75: The People Team at my company is using Agile to help them plan and track projects.
• #77: Big tasks are intimidating. It’s also harder to show progress when you are working on a huge project or task.
• #78: Focus on doing the things that matter. Delivering a feature is output. Delighting a customer is outcome.
• #79: We naturally tend think of our work mostly in terms of effort or output. How many new features are in the release? How many story points did we complete in the sprint? We talk about our work in the ways that are easy to quantify and measure.
• #80: The outcome of our work isn't as easy to measure, but it's what really matters. We all intuitively know that our goal isn't to release 10 new features this year, but to improve the lives of our customers and their members as best we possibly can. To do that, we must always focus on the outcome or impact our work will have on the users of our products. We should try and maximize outcomes while at the same time, minimizing output. This applies to everything you do. Always think about what action you can take to have the biggest impact to our customers.
• #81: Task board: The key benefits are that the work can be seen at any moment, the work that people are doing is not hidden behind some 'long-range' goal, and what features/items get worked on can change drastically and very quickly in response to changing needs.    There are a LOT of visual indicators on this task board. The stickies colors have significance, the columns indicate progress, check marks on stories show acceptance, lego avatars show who is working on which tasks, the tasks are prioritized top-down, remaining hours are written on the stickies, magnetic darts indicate a review is needed, wavy blue line shows the team’s commitment goal. You can’t easily get that level of info from a tool such as Excel. You can walk up to the board and within seconds know how things are going.
• #82: Track the team’s progress so that everyone knows how they are doing. Set goals, make them visible, and track your progress.
• #83: Plans are useless, but planning is essential. Don’t get too committed to your plan. A lot of times we make plans, then we need to change our plans when we learn new info. Don’t be afraid to act on what you learn.
• #84: These meetings are to coordinate efforts, communicate progress, and raise obstacles or issues.
• #85: Ask the question of whether or not you really need something? Work to optimize the teams workflow and eliminate unnecessary activities and deliverables. Outcomes over Output!
• #86: Get out of your comfort zone! Teams should be empowered to focus on doing whatever is necessary to deliver results. Encourage teams to swarm on tasks that need to be completed even if it puts them out of their comfort zone.
• #87: Inspect & Adapt! Constantly look at how we are doing and ask “What could we do to be better?” Sailboat Retrospective Exercise Winds= Propel us forward Anchors= Hold us back Icebergs= Obstacles to look out for and avoid
• #88: Make sure you are having fun. There’s no right or wrong way to do these things. Make them work for you and your team.