Agile-based Software Process

Agile–based software process  Prepared by: T. Taha Al-hababi. Overview  Lean overview  Agile teams know that they can always improve the way they work. Team members with a Lean mindset are great at finding where they spend time on things that aren’t helping them deliver value...

Agile–based software process  Prepared by: T. Taha Al-hababi. Overview  Lean overview  Agile teams know that they can always improve the way they work. Team members with a Lean mindset are great at finding where they spend time on things that aren’t helping them deliver value. Then they get rid of the waste that’s slowing them down. Many teams with a Lean mindset use Kanban to set work in progress limits and create pull systems to make sure that people are not getting sidetracked by work that doesn’t amount to much. Get ready to learn how seeing your software development process as a whole system can help you build better software!  Lean is a mindset (not a methodology)  Lean is a mindset based on principles that are all about making sure that the process your team is following is lined up to help you build products that are valuable to your customers.  Lean is different. Unlike Scrum and XP, Lean doesn’t include a set of practices. Lean is a mindset, and just like with the mindset for Scrum or XP, Lean comes with values and principles (which, in Lean terminology, are called “thinking tools”). The mindset of lean is sometimes called lean thinking.  Lean asks you to take a look at the way you’re working today, figure out where you’re running into trouble, and apply Lean principles to correct those problems.  Lean, Scrum, and XP are compatible  You don’t have to have a Product Owner or a Scrum Master on your team to use Lean. You don’t have to hold sprint planning meetings on the first day of your sprint, or retrospectives on the last day to do Lean.  You don’t have to do pair programming, or sit together, or ruthlessly refactor.  But both XP and Scrum were developed with Lean in mind. So if you’ve started using XP or Scrum (or even if you haven’t), you can use Lean to find ways to improve the way your team is working.  Lean principles help you see things differently  Lean is divided into Lean principles and thinking tools that help you use those principles when you build software.  Teams that use Lean even have a name for applying these principles and thinking tools: they call it Lean thinking  Lean Thinking  Eliminate waste › Find the work that you’re doing that doesn’t directly help to create valuable software and remove it from the project.  Amplify learning › Use feedback from your project to improve how you build software.  Decide as late as possible › Make every important decision for your project when you have the most information about it—at the last responsible moment.  Lean Thinking  Deliver as fast as possible › Understand the cost of delay, and minimize it using pull systems and queues.  Empower the team › Establish a focused and effective work environment, and build a whole team of energized people.  Build integrity in › Build software that intuitively makes sense to the users, If the software you’re building is intuitive and does something valuable for your users, it’s a lot more likely to be worth the effort everyone is putting into building it.  Lean Thinking  See the whole › Understand the work that happens on your project—and take the right kind of measurements, so that everyone is exposed to all of the information they need to make good decisions about it. When everyone on the team can see what everyone else is doing (and not just their own contributions), the team can collaborate on the best way to get the work done. › Lean teams work to remove local optimizations and optimize the system together. They look at the system together and remove any activities that are getting in the way of building software fast and with high quality  Seeing Waste  Before you can eliminate waste, you need to see it —but that’s easier said than done  Find the work your team is doing that isn’t helping you build a valuable product, and stop doing it. › Are you spending a ton of time manually doing work that could be automated? › Putting a lot of effort into discussing and estimating features that probably won’t make it into the finished product?  Value stream maps help you see waste  A value stream map is a simple diagram that helps you see exactly how much of your project time is wasted waiting and not working.  To build a value stream map, find the smallest “chunk” of the product that the customers are willing to prioritize on your backlog.  Then think back through all of the steps the team took to build it, from when it was first discussed until it was delivered. Draw a box for every one of these steps, using arrows to connect the boxes.  Next, track the amount of time it took you to perform each of the steps and the amount of time you waited in between each step. The time you spent waiting in between steps is waste.  Draw a line that moves up to show that the project is working, and moves down to show that the project is waiting. Now you’ve got a visual representation of the work and the waste!  Pull Systems  When a team organizes all of its work into a backlog and then has developers pick up a new task as they finish an old one, they’re using a pull system. The backlog is a queue of work.  Instead of having users, managers, or product owners push tasks, features, or requests down to a team, they’ll add those requests to a queue that the team pulls from.  Pull systems are about only working on one thing at a time and pulling work into the next phase of a process as a person frees up to work on it.  That way people get to focus on doing the best work they can for each task they take up, and the product is built with attention to quality and efficiency.  Set up a pull system by establishing WIP limits  Here’s an example. Let’s say a traditional test team is always overloaded trying to keep up with code being generated by a development team. If they moved to a pull system, work wouldn’t begin on development items until the test team requested more work from development. So how would they do this?  One effective way is to limit work in progress (WIP). A Lean team will establish a WIP limit, or a number of work items that can be worked on at any given time for each step in their system.  If a team can only test four features at a time before their system begins to slow down, they can establish a WIP limit in the previous stage so that the development team is never building more than four distinct features at a time.  By establishing a limit, they can define the shortest path through the process, and reduce the total lead time from when the feature is identified until it is released.  Minimally Marketable Features & Minimally Viable Product  One way that Lean helps teams focus on delivering value as early as possible is by asking them to identify the smallest thing of value that they can deliver and then focus the team on delivering it as fast as possible. Lean teams often talk about Minimally Marketable Features (MMFs) as a goal for a release increment.  Similarly, they’ll try to identify the smallest product that they deliver that will be valuable to their customers—the name for that is a Minimally Viable Product (MVP).  By focusing on delivering MMFs and MVPs, Lean teams make sure that they get a valuable products in the hands of their customers as soon as possible.  Categorizing waste can help you see it better  Lean tells us that we need to eliminate waste. But: › what, exactly, does that waste look like? › How do we spot it? One thing that can be really helpful is to think of categories of waste.  Luckily, you don’t need to come up with these categories on your own. Lean practitioners have identified seven wastes of software development:  Seven wastes of software development  Partially done work › When you’re doing iteration, you only deliver work that’s “done done” because if it’s not 100% complete and working, then you haven’t delivered value to your users. Any activity that doesn’t deliver value is waste.  Extra processes › An example of an extra process is the project management antipattern, where the team spends 20% of their time giving status and creating estimates that aren’t used for anything other than updating a status sheet. All that extra effort going through the process of tracking and reporting time doesn’t create any value.  Extra features › When the team builds a feature that nobody has asked for instead of one that the users actually need, that’s waste. Sometimes this happens because someone on the team is very excited about a new technology, and wants an opportunity to learn it. This might be valuable to the person who improved their skillset, and that might even be valuable in the future for the team. But it doesn’t directly help build valuable software, so it’s all waste.  Seven wastes of software development  Task switching › It’s really common for managers to lose track of the number of requests they’ve made to a team, and just assume that there’s no cost to giving the team more work to do without adjusting anyone’s expectations. Couple that with the fact that software developers often want to overcommit in order to impress their bosses and teammates, and you see how people end up switching between three, four, five or more tasks that are all supposed to get done at the same time. That’s why task switching is an extremely useful concept in identifying software project waste. Any time a software developer needs to multitask between two competing priorities, time is wasted.  Waiting › There are so many things that professional software developers have to sit around and wait for: someone needs to finish reviewing a specification, or approve access to some system that the project uses, or fix a computer problem, or obtain a software license... these are all waste.  Motion › Motion When the team doesn’t sit together, people literally have to stand up and walk to their team members in order to have a discussion. This extra motion can actually add days or even weeks to a project if you add up all of the time team members spend walking around.  Seven wastes of software development  Defects › Test-driven development prevents a lot of defects. Every developer who is “test infected” had that “a ha” moment where a unit test caught a bug that would have been very painful to fix later, and realized that it took a lot less time to write all of the tests than it would have to track down that one bug—especially if a user discovers the bug after the software is released. On the other hand, when the team needs to stay late scrambling to fix bugs that could have been prevented, that’s waste.  Under the Hood: Toyota Production System (TPS)  Lean thinking comes from the Toyota Production System (or TPS).  They focused on being able to look at the entire flow of the manufacturing system, and eliminate places where work was not contributing to the end product.  They found that by limiting the amount of work in each step and managing flow through the system, they could get much higher quality products in much less time than they had seen prior to the introduction of TPS.  Under the Hood: Toyota Production System (TPS)  TPS is focused on the idea that there are three sources of waste that slow down the workflow and must be eliminated: › Muda ( 無駄 ), which means “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness”. › Mura ( 斑 ), which means “unevenness; irregularity; lack of uniformity; non uniformity; inequality”. › Muri ( 無理 ), which means “unreasonableness; impossible; beyond one’s power; too difficult; by force; perforce; forcibly; compulsorily; excessiveness; immoderation.” Finding those sources of waste and getting rid of them can help teams to develop smaller increments more frequently. That’s exactly what TPS was trying to do, too.  Under the Hood: Toyota Production System (TPS)  Seven types of manufacturing waste: Another foundational development of TPS was the identification of the seven types of manufacturing waste. › Inventory › Transportation › Waiting › Motion › Defects › Overproduction › Extra Processing  Under the Hood: Toyota Production System (TPS)  Mary and Tom Poppendieck are software engineering experts, trainers, and consultants who adapted Lean thinking to software development.  They started with these concepts from the TPS and applied them to the way teams work together to develop software.  Mary and Tom Poppendieck, who adapted Lean thinking from manufacturing to the software development domain, developed the seven categories of waste that software teams run into from these seven types of manufacturing waste.  Foundational concepts of flow, continuous improvement, and quality  There are several other ideas from TPS that are translated directly into Lean for software development: › Jidoka: creating automated ways to stop production as soon as a problem is detected. In TPS each step in the process has automated checks to make sure that problems are fixed right where they are found and not pushed to the next person on the manufacturing line. › Kanban: signal card. Signal cards were used in the TPS manufacturing system to indicate that a step in the process was ready for more inventory. › Pull Systems: each step in the process indicates to the step before it that it needs more inventory when parts are depleted. In this way, work was pulled through the system at the most efficient pace and never became uneven or backed-up Foundational concepts of flow, continuous improvement, and quality › Root cause analysis: figuring out the “deep” reason that something happened. Taiichi Ohno talked about using the “5 Whys” (or repeating why five times) to figure out what caused a problem. › Kaizen: continuous improvement. Putting in place activities that improve all of the functions every day can only happen when the team pays attention to what’s happening along the flow of work, and suggests ways to make things better.  Key Points  Lean (or lean thinking) is the name for a mindset, and like other agile mindsets it has values to help you understand and adopt it.  Lean is a mindset, not a methodology, which is why it doesn’t have practices that help you run projects.  Teams with a lean mindset work to eliminate waste by finding any activities that don’t directly contribute to building a valuable product and removing them  Key Points  Any activity that doesn’t directly add value to a project is waste, and Lean teams strive to see waste for what it is and eliminate it from their projects wherever possible.  Mary and Tom Poppendieck came up with the Seven Wastes of Sofware Development: partially done work, extra processes, extra features, task switching, waiting, motion, and defects.  A minimal marketable feature (MMF) is the smallest “chunk” of value or functionality that the team can deliver, such as a story or a user request—something that might end up on a Product Owner’s backlog).  A value stream map is a visual tool to help Lean teams see the reality of how their project works by showing the entire lifespan of an MMF, including the working and waiting time at every stage. Any Questions ???  References  “Head First Agile A Brain-Friendly Guide ”  “Learning Agile” : by Andrew Stellman and Jennifer Greene