Tag: Lean

Jidoka and Captured Knowledge

In manufacturing, you likely know the problems to look for; broken threads, misshapen parts, etc.. In software, you may have no idea what kinds of problems you may create by changing code. In this way, practicing jidoka is invaluable. It’s how later developers know what can break, what is broken, and offers wisdom about how to fix bugs without breaking something else. How? Captured Knowledge. Each automated test represents knowledge captured from previous engineers about how the system was expected to operate in various scenarios. This is actionable knowledge that all future engineers can make use of. It lets future engineers test their changes and immediately learn what (if anything) has been broken without first needing to learn all the nuisances of the software. It is the period when learning how the software operates that greatly extends engineer ramp up, because too often even simple debugging requires direct use of the application and guessing through which scenarios may invoke the altered code. Without that captured knowledge, the future engineer has to re-learn everything that was known in the past because the raw code does not capture the nuances of what is expected or required. In this way, the knowledge in the tests acts as a safety net. It’s also knowledge the engineer does not need to fill her brain with by memorizing, because he test can be relied upon to act as an institutional memory. Actionable Knowledge This is not documentation for documentations sake. It’s a used and actionable part of the process that cannot be ignored. If you fail a test, the build should fail and block your progress. Unlike an external document, which simply becomes out of date. In some ways, that build break acts as an andon call, alerting you to having missed a standard step (documenting the behavior of your code). Flexibility Creates Choices (and agility) By offering the wisdom of all engineers who previously worked on the application, we greatly reduce the learning curve needed for an engineer to become a productive team member. This means that we have much more flexibility in terms of how many add to (or take from) an application. If we add engineers, the drain on those already on the app will be more modest. The tests provide a safety net which can enable a bit more autonomy win confidence. We can also add more than just a few since the bank of knowledge from which they can draw isn’t limited to the brains and mouths of the senior engineer on the team. If we remove engineers, we shouldn’t need to lose too much sleep over having them forget their current application. The test bank should go a long way in preserving the most critical information. By making this investment in our code today, we gain flexibility around where to invest our effort for the biggest wins tomorrow. That is the heart of agility. Pursing our greatest opportunities today in a way that won’t stop us from pursuing better opportunities tomorrow. Foreshadowing There is still more to say about how they enable speed. We will look at that next time.

Jidoka (automation with a human touch)

The two pillars of lean are just-in-time, and jidoka. Today we’ll look for jidoka in software development. What is jidoka Often translated as “automation with a human touch”, some people also use the word autonomation. The principle is rather simple. When designing a process, find opportunities for the process to self identify errors and stop so that the problems can be fixed at the source. With this in place, human attention can be focused on either finding and eliminating root cause for the error or improving the task itself. This means we’re investing the human mind where it will do the most good. Example Perhaps the most common example of jidoka is the looms made by Sakichi Toyoda. These had the ability to detect thread breakages and stop. This meant that humans could then intervene to fix the issue and let the loom resume. Until there was a break, the advanced looms could be monitored, with many looms sharing one operator. This was a vast departure for it’s time, when any one loom required a great deal of energy from a single dedicated operator, whom may fail to notice thread breakages due to the many other aspects of weaving that required their attention. Software & Agile The parallel in software delivery is hopefully rather obvious; automated testing. This can be in the form of unit tests, integration tests, or most anything else that will allow human creativity to be applied to novel situations and the automation can be left to handle the monotonous work of simple testing. If our QA team members automate a common test, they can now spend their time looking for more subtle errors, problematic interfaces for humans, or other validation. Just like the loom operator, that test gives them the ability to use their human mind on more valuable things that a machine cannot so easily do (like building more automated tests).

Muri, Kaizen & Retros

When do you most need a retro? When you feel as though you don’t have the time for it. Muri In lean, the feeling of stress (or the impossibility of your task) is called “Muri”. It should serve as a powerful indicator that something is terribly wrong. If you feel this as a member of the team, it is your duty to stop what you’re doing (pull the metaphorical andon cord) and have a serious conversation. In common agile parlance, that is a retro, but it could just as easily be called kaizen. There may be many reasons for such a feeling. Perhaps your deadline is unreasonable with the current scope. Perhaps you are trying to centralize something on a small team that cannot support the load being put upon them. Perhaps you feel like you’ve nearly solved a problem, but have felt the same way for days and the solution continues to be elusive. Problems Just as your problems don’t nicely conform to a script such as “what went well” and “what didn’t”, your retro does not need to be so narrow. Be willing to reflect on what you’re doing, how you’re doing it, how you feel, and “why”. Be willing to have an open conversation about all these topics whenever necessary. Problems may not always arise on a two-week schedule and if they can be solved sooner then everyone is better off. Remember that the retro is also about finding solutions (or starting toward them). If you consistently talk about the same issues but take no action, that can be a source of muri! Beware of Justification Metrics and intrinsic motivation can deceive you. Your desire to “just finish it” can undermine your long term success. Your drive to do things “this way” despite lacking the time or team can make you sound like a victim. Don’t allow these justifications to enable muri. Listen to how you feel. If you feel that something is wrong, you may be telling yourself something your brain cannot yet comprehend. When tackling problems, be careful of “solutions” that justify your stress or avoid unpleasant conversations. You must be willing to accept the possibility that your perspective may be ill suited to this specific context. You must be comfortable being uncomfortable so that you can engage in the conversations that must be had. A great many problems can be solved by merely achieving a common understanding. Conversations, especially those that are unpleasant, can be the best tools in achieving this. Mirages & Solutions The solution may not be to bring in more people help the project get back on track. That can make things worse. You may be better off having the hard conversation about scope or dates. At the least, this can help you understand the relative costs of delay between the deliverables so that wise trade offs can be made. The solution may not be to expand the centralized team substantially so that they can manage all deployments for an enterprise. You may not want to staff a team of release engineers like a call center so that every deployment request can be handled quickly. You may be better off having the centralized team act as consultants to the de-centralized doers rather than doing the work themselves. This can empower the team and accelerate the progress they were aspiring to. The solution may not be to hire a consultant to solve the problem for you. Rather, all the talent you need is probably already there and you simply need to discover how to find it. This does not inspire confidence quite like rented credentials, but it gives you a chance to better learn about the team, it gives someone a chance to showcase their ability, and it gives someone within your team a growing and learning opportunity that you had been giving to the consultant. When do you most need a retro? When you feel a pit in your stomach whenever you think about it. When you cannot find the time due to the amount of work that needs to be done. When you’re dreading the conversation and just want to avoid it. When you’ve tried a dozen quick fixes and none of them have fixed it. These aren’t signs to delay. These are signs at you’ve delayed too long.

Takt Time & Waste Elimination

How does the use of sprints (takt) eliminate waste? By reducing Mura & Muri. Mura – Variability Imagine a lean auto plant with a 60 second takt. Expectations for everyone are clear. You will be done in 60 seconds. If you cannot consistently do your job in less than that, there is a problem. In 60 seconds, the next car will be ready for you. Imagine if my job takes 60 seconds, but the next car arrives at random. Sometimes it arrives in 20 seconds. Sometimes 300 seconds. I will need to worry about this. My attention will be split between doing the job and tracking incoming cars. I may even build special tools or modify the line to include staging areas. Doing this will help me manage the work, but this is an infrastructure I’m putting in place to help me manage the variability. It isn’t adding any client value. Unfortunately, I need to do this because I cannot be assured that I have enough time to do my job. If the next car is coming quickly, I may need to cut corners and just move on to be ready for it. It’s similar for creative teams. If we simply take work as it comes with no process to control it, we will invest a lot of energy into knowing and tracking the various due dates, conflicts, and needs. We may build waiting queues and layers of vetting to “speed things up” once we’re ready to start the work (if you think this will work, look at the system optimization that is lost in a production cell). A lot of mind power will be invested into just keeping everything in motion so that nothing appears to be failing. When deadlines conflict, we sacrifice testing, unit tests, or code reviews (or worse) to keep up. If we create a predictable pattern to enable delivery, people can start investing their mental energy into client problems rather than tracking the variations in our planning processes. There will be more about this tracking (managing work variation) in other articles. However, this takes a great deal of discipline. Not only must you respect your takt, but you must balance the work so that you are able to consistently deliver to your quality standards (testing, unit testing, etc.). There will be more about this balancing (managing skill variation) in another article. Muri – Stress It is that propensity to take on too much work, which creates so much stress for white collar workers. In manufacturing, the line controls flow. You can’t physically have two cars in your work station. For software engineers, you can have the entire backlog in a “doing” state and nothing will stop you. Juggling between what’s “on deck”, “getting started”, “wrapping up”, and “being supported” can spread your attention thin. The context switching alone can wear you down, let alone the greatly reduced ability to get things done due to the sheer volume of things you’re trying to do. Sprints offer a way to overcome this. At the sprint’s beginning, we plan. We plan as much as we can reasonably complete and focus on the most valuable things we can do in our limited time. This protects us from having the entire backlog in process. It focuses us onto a body of work we can achieve. This can greatly reduce the stress on team members while ironically increasing throughput by eliminating much of the context switching. In software development, the formal spring planning limits the “in process” work so it can’t overwhelm the team. If that seems overly simple, it is. That’s also why it’s powerful. Sprint plans help protect white collar workers from themselves. It makes sure their commitments are reasonable targets for completion, and this gives them both focus and satisfaction every sprint. Challenge Does your sprint process control variability in a way that enables focus? Does the team limit he work in each sprint to that which can be completed?

Takt Time & Sprints

Takt is a German word that has been adopted by lean. The original meeting is “beat” or “rhythm”. In an auto plant we may see a one minute takt. This means that every minute a finished car rolls off the assembly line, a dashboard is installed, a car is painted, etc.. Software development cannot possibly resemble his repetitive highly orchestrated pattern, or can it? We’re not a factory It is exactly this image that most creative and white-collar professionals abhor, and for good reason. Each request in their environment is unique and will require an unknown mix of skills to get it done. It is not like building the 109,345th Camry. The reality of what it will take will also not match our initial estimates. Toyota knows exactly how long it takes to make a Camry. How can we create a repetitive process if our work is inherently not repetitive? Rather easily if we accept that the work itself is unique, but our process for handling it doesn’t need to be. Timeboxes, Planning, & PDCA Although being agile doesn’t require “sprints”, it does require planning, frequent delivery, quick feedback and reflection. If you simply put consistent timeboxes around those things, you get sprints. A sprint is a PDCA cycle. We get an idea for how we can deliver the most value in the timebox. We execute, get feedback, reflect, make changes for how we’ll execute the next cycle based on our learnings and repeat. We use sprints to accept that the work itself is unique and cannot be standardized like an assembly line, while saying that the way we plan, execute, track, and reflect on that work can be standardized. In this way, we improve the way we do the work and establish our takt. Sprints as Takt Takt sets the cadence in lean – people need to fit within it and improve. Agile sprints do the same. You know the duration, every time. You improve how you execute within them, regardless of the type of work it is.  The need to juggle multiple competing priorities is greatly reduced. The priorities for the sprint were made clear in planning. In lean manufacturing, there is only one line. Which car do I work on? The one in my station. When will the next car arrive? In one minute. When is this one due? In one minute. Does this ever change? No. Your sprint process should offer similar confidence to team members. We should be able to feel the takt and all our activities should align to it. In agile, there is only one sprint. Which request do I work on? Those committed in sprint planning. When will the next request begin? At sprint planning. When is this one due? When the sprint ends. Does this ever change? No. Challenge What is your takt? Do you respect your takt? Does everything fit within the cadence? Is your takt the heartbeat of your team, or that of the organization?

The Why of Lean

Conventional lean tools include timing a process and tagging each action as value added or waste. That may work in a factory, but not in software development; or can it? The same precision and clarity is not possible in a knowledge industry. You cannot apply a stop watch to mental problem solving. Sometimes getting away from the keyboard for an hour is the most valuable thing you can do. Few (if any) six sigma black belts will put that in the value added column, but maybe they should. There are a few problems with this technique, but they stem from confusing a lean tool with the purpose of lean. Client Value In lean, being able to categorize tasks as value added or not relies on a value stream. We know what the end client wants, so we can see if each second along the way is contributing to that want. The purpose is to make sure we’re only investing energy into what is adding value. The stopwatches are just a tool to support that goal. At a basic level, this “knowing what is valuable” is what software teams are establishing when they start with why. Once they know that, they can evaluate each deliverable (or task) as helping that cause or not (adding value or not). Again, this is to ensure that the energy they’re investing is delivering value. That may seem much fuzzier than lean manufacturing, but it’s actually the same. The difference is what you’re not seeing in lean and what is ignored by many software delivery teams. The Why of Lean In lean manufacturing, we see and talk about assembly lines, plants, and other artifacts as being what lean is. We see the lean experts and plant tours as representing lean. True, lean principles are made quite visible there, but this is not where lean starts. The best lean organizations aren’t just lean for lean’s sake. They have a purpose that transcends what they do. They have a why. Take the example of Toyota North America’s purpose: 1. As an American company, contribute to the economic growth of the community and the United States. 2. As an independent company, contribute to the stability and well-being of team members. 3. As a Toyota group company, contribute to the overall growth of Toyota by adding value to our customers. Notice that it says nothing about designing, making, or selling cars. Cars are somewhat irrelevant for fulfilling Toyota’s purpose. Cars are a great way to support the Anerican economy, communities, team members, and the parent company. Toyota has a purpose that has nothing to do with “what” they do. Now being lean in manufacturing is less about saving money, it’s about making sure that the purpose is fulfilled and not wasting time waiting and not wasting money on inventory is a good way to better fulfill that purpose. With that clarity, all of the decisions and activities that precede and support the plants are also improved. It is this part of a wholly lean operation that is oft ignored. Clarity of purpose helps ensure decisions are aligned to supporting the cause Should we lay people off and save money? That would be harmful to community, and destabilize team members (even those retained). Unless absolutely necessary to survive, no, we won’t lay them off. Should we open this plant? Maybe. It would help that community and America. It could offer new opportunities for team members. Primarily, we just need to make sure it will add the most value to our customers of all investments we could make. It is at this level of strategic investment that software delivery teams, even very small ones, exist. Software delivery is a creative process. They must make sure their investments are aligned to a greater purpose. Every deliverable a team begins is a strategic investment. The team must make sure that the deliverable is the most value added thing they could do with those minutes if the team wants to be truly lean. This is just like Toyota deciding whether the best investment it can make to fulfill it’s purpose is a new plant. The Lean of Software Delivery When software folk talk about lean operations in software delivery, they often talk about how the work is non-repetitive, cannot be scripted, is very creative, etc., and so this “lean” stuff doesn’t apply. There are a few problems with that. The first, is that the lean stuff certainly applies and in a hundred ways. There are repetitive aspects to software delivery that deserve standards and structure. But, the idea of timing software engineers like line workers is ridiculous. Or is it? If our delivery teams are deciding the investments and making strategic decisions like the lean leadership at Toyota, then who are the laborers we could time in our system like factory workers in lean? The users of the software. They clearly have a structured and semi-repetitive job. If not, software wouldn’t work. Some things they do add value to their client and some don’t. The software may help with this, but the principle remains. If you want to apply all of the lean six sigma skills employed at a factory, apply them to the users of software. If you want to help a software delivery team, give them the output of that client analysis, but when prioritizing actions to improve the client process, remember to prioritize based on why.

User Stories as Lean

User stories are a useful and well established agile tool. Could they also be thought of as a lean tool? Definition We’re not going to do what’s been done a million times. If you aren’t familiar with stories, check this out. For more information, google it. How Stories Support Agile By avoiding the “how”, the story does a few things: Stories invite a conversation. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. That conversation can be had only once the story is prioritized high enough. This means there are a lot of conversations we’re not having (work we’re not doing). 10. Simplicity–the art of maximizing the amount of work not done–is essential. Analysts and product owners largely wait for the conversation rather than trying to build a full queue to keep engineers busy. This lets them stay in the here-and-now and focus on what’s needed today rather than on what might be needed tomorrow. This helps everyone focus on delivering now. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. This keeps everyone focused on what really matters (software for the client) rather than building a big backlog. 7. Working software is the primary measure of progress. If written very well, stories allow us to execute the backlog in an arbitrary order. This leaves the order completely up to customer desires every sprint. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. We avoid having upstream stakeholders designing the solution. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 11. The best architectures, requirements, and designs emerge from self-organizing teams. Once we’re ready to act on the story, we can bring the team and client together to solve the most important problem of the day, today. 4. Business people and developers must work together daily throughout the project. All told, a story is a great way of bringing an agile mindset to your backlog. How Stories Support Lean By avoiding the “how”, the story does a few things: It invites a conversation. By relying on a face to face conversation, we minimize the number of times people are going into documents and work tracking systems. By reducing these transactions (inefficient knowledge transfers), we eliminate a lot of waste from our process. Reduce Transport Waste That conversation can be had only once the story is prioritized high enough. This means there are a lot of conversations we’re not having (work we’re not doing). By not having these redundant conversations, we eliminate decisions that will be rendered obsolete (or forgotten) as changes continue to unfold. Reduce Motion Waste Analysts and product owners largely wait for the conversation rather than trying to build a full queue to keep engineers busy. This lets them stay in the here-and-now and focus on what’s needed today rather than on what might be needed tomorrow. They avoid just keeping themselves busy trying to keep other people busy. Reduce Over Production This keeps everyone focused on what really matters (software for the client) rather than building a big backlog. By not building that big backlog of documents, we have much less knowledge waiting for action. Reduce Inventory Just in Time If written very well, stories allow us to execute the backlog in an arbitrary order. This leaves the order completely up to customer desires every sprint. This makes it possible for us to deliver exactly what’s needed as close to the need as possible. This quick feedback loop helps make sure that we’re doing only what’s necessary today. If we’re wrong, the quick feedback makes sure we don’t invest too much time into something that our client doesn’t need (or needs very little of). Reduce Over Processing We avoid having upstream stakeholders designing the solution. This means we can bring in the valuable perspective of those doing the engineering into the solution creation process. This taps into the talents and training of the entire team to make sure we pursue the best (and most minimal) solution rather than the best solution that one person could think of. Maximizes human creativity Once we’re ready to act on the story, we can bring the team and client together to solve the most important problem of the day, today. It’s important for teams to recognize that they are not the client. The client is the client. When it’s time for the conversations about how to implement a solution, that’s the time to bring the client into that conversation to make sure it fits the need with the least amount of work. This can mean a conversation, or it can mean going to where the software is used and truly understanding the need that is driving the story rather than just the request itself. Genchi Genbutsu All told, a story is a great way of bringing lean to your backlog.

Agile, You’re Doing it Right

For all the attention people apply to not being agile, or needing to be more agile, there is a distinct possibility that is often unaccounted for. That you’re already agile. Of course, you could have a better process, but that’s always true. Recognizing that you can be better is at the heart of agile (and lean). Lean uses kaizen and PDCA for incremental improvements. In agile, there’s the principle: 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The fact that you want to be more agile is usually a misrepresentation of your desires. Most teams say things like “more agile” or “leaner” as a euphemism for “better”. That sort of drive is a key characteristic of being agile. We Don’t Look Agile There is no one way to be agile, so stop worrying if you don’t have the scrum ceremonies or roles. You can be agile without a “product owner”. Lacking a “scrum master” does not diminish your agility. There is nothing in agile that says you must have a stand-up, or a sprint, or a prioritized backlog. There are good reasons for these, but that doesn’t mean they’re good for you. Don’t judge how agile you are based on how closely you follow any specific playbook. Look at these for ideas, not rules. Especially in large scale companies there are no shortage of guides such as the scaled agile framework (SAFe) or scaled scrum that talk about how to be an agile enterprise. Enterprise agility a bit of an industry buzz word right now, The great irony of these is that they put a lot of emphasis on the process. Why is that ironic? Individuals and interactions OVER process and tools It’s critical that you know your client and work with them. Having a formal process to facilitate that can be nice, but find a process that works with what you have. Stop evaluating how agile your enterprise appears to be based on some theoretical process that was created without considering your unique context. Go ahead and look at it. It probably has some good ideas. Understand it. It was made by smart people to solve problems. But consider, are the problems it solves problems you have? Look for ways it may help you, but recognize that it doesn’t understand your people, your clients, your processes, or your culture. Your way may be better for you. It may even be more agile. Project Managers Don’t fire your project managers, and don’t re-classify them as scrum masters. Contrary to popular belief, good project managers need not impede agility. Their plans provide a reference point for how much we expect to invest and when our time boxes end. These can help us create visual management, so we can see when we are out of standard and fix it. When things do change (discoveries by the team or new client needs) the PM skillset can help us and our clients understand the trade offs so that expectations remain aligned and decisions are made that are respectful of (sometimes) fixed dates and the needs of others. Consider what is one of the most well known agile shops around; Menlo Innovations. Do they have scrum masters? No. Do they have product owners? No. Do they have project managers? Yes. Are they agile? They are among the best for agile software delivery and their project managers help make that possible. The only problem with project managers is that sometimes you find a bad one. What is a bad project manager? Someone who thinks it’s their job to protect the plan from change rather than using it to facilitate a well informed conversation about the inevitable changes. The problem here isn’t project management, it’s a bad project manager. Don’t confuse the two. Agile and lean processes benefit from having a plan so that way we can check ourselves against it (PDCA) and make trade-offs explicit. Plans are worthless, planning is everything.Dwight D. Eisenhower Evaluating Your Priorities. Are you driven to satisfy your clients or are you wrestling with them? Are you excited to show them what you’ve built and get their opinion, or do you want to be left alone for a few more weeks to perfect it? Are you trying to deliver often or do you want to cut down on deliveries to reduce fixed costs like QA? If you gravitated toward the first statements, you’re probably fine. Stop looking for a whole new way of doing things and just try to get better; one step at a time. If you gravitated toward the latter statements, then you may need an agile intervention. But here’s the trouble. The problem isn’t your methodology, it’s likely how you think about your role and your relationship to the client. Until you fix that, all the scrum ceremonies in the world won’t help you. Worse, having those ceremonies may give you the feeling that you are agile, but you may be fundamentally doing it wrong.

Finding the 8 Lean Wastes in Software Development

Any talk about lean should always include the 8 wastes, so we’ll look at how these apply to software development (or any knowledge industry). Rather than creating a whole new list of wastes, we’ll find that the originals apply just as well; we just need to shift our perspective a bit. Muda, Mura, Muri Before we dive into the 8 wastes, it’s important to put them into perspective. When we’re talking about improving a process within lean, there are 3 primary problems. Muda: Waste Mura: Variability Muri: Stress When we talk about the 8 wastes, we’re only talking about muda. There are two other broad categories that are at least equally, if not more, important. These other problems in a lean process are often under appreciated compared to muda, and in other posts we will look at them in depth. For today, here are the 8 wastes. Defects This is the easiest of the wastes to translate because we’re all familiar with it. Any time the software does not behave as intended, it’s a defect. Defects are costly to our reputation, take time to diagnose, and are preventable. Motion In manufacturing, this would be unneeded movement such as reaching for tools, or walking around to get parts. In the software development, there are many sorts of motion waste. Being required to do double data entry is an unneeded activity. Holding meetings that serve no purpose may be another. There are many examples of this, but you can often identify it because you can feel the waste. You question why you’re at the meeting or doing some activity. You feel that it’s taking your time and not adding value. All of those unnecessary activities are merely motion. Waiting This one is what it sounds like. This is also the same in every context. If you’re just sitting around waiting for something, you’re wasting time. Over Processing In software vernacular, this may be called “over-engineering”. This is when we’ve simply done more work than we needed to, either because we didn’t understand the need or felt that it was worth growing the scope. There are numerous reports of just how many features are not used in a typical software solution. The number varies, but it’s typically quoted as being over half of all features. All of this work whose output is not being used is over-processing. Over Production Most people take issue with this as a waste. They simply cannot understand the problem of having too much new software. Unfortunately, that’s not usually how this waste manifests itself in the software industry. Over production can occur anywhere in the software delivery lifecycle (SDLC). Over production occurs when requests for features come in at 20 a day but only 10 per day are reviewed. Over production occurs if analysts are creating 10 spec documents every week and engineering can only implement 3. The analysts are over producing. Over production occurs if the software engineers are going to complete 3 features this week but the lone DBA can only complete her work for 2 of them. The engineers are over producing. Over production occurs if the the engineers and DBA are finishing 2 features per week but QA can only handle one. The engineers & DBAs are over producing. Inventory This is the manifestation of all that over production. All those U reviewed ideas aging in a suggestion box are inventory. That share point drive full of year old specs are inventory. The engineering team’s backlog is inventory. Those features waiting for database changes are inventory. Those features waiting for QA are inventory. Developed software waiting for six months for the next release is inventory. Wherever someone is over producing, we get inventory. If we have inventory, someone is overproducing. Transport This is the waste that is most difficult to understand in the world of software. In manufacturing, it’s easy. Needing to truck parts from one plant to another, is transport. Needing to have forklifts moving parts to work stations is transport. Taking output from one station and adding it to an internal warehouse is transport. Pulling from that warehouse for a later work station is transport. The trick to understanding this in the world of software is understanding what is being transported. In traditional manufacturing, it’s physical goods. In software, it’s knowledge. When a customer puts their idea into the suggestion box, they’re transporting knowledge. When the analyst reaches out to the client to understand the idea, the resulting meetings, phone calls, and conversations are all efforts to transfer knowledge. The spec written by the analyst is an effort to capture that knowledge in a refined way that is more easily transported. When engineers pull work from their backlog, they’re extracting knowledge from a database just like a manufacturer pulls parts from a warehouse. Software engineering itself is the transformation of one type of knowledge (a human need) into a different kind of knowledge directions for a computer). They take in knowledge, apply more knowledge, and the output is refined knowledge that benefits society in some way. Being that it is a knowledge industry, once you understand that knowledge is what we transport thou begin to see that the most costly thing we do in software is transport knowledge. And we do it a lot. Anything we can do to decrease the number of transfers, or acclerate them, will certainly have the effect of leaning out our knowledge-based supply chain. More on that later. Unused Creativity This waste is also rather easily understood as it applies to software. Despite the reputation some ascribe to us, software engineers are very creative people. Software engineering itself is as much art as science (yes, there can be beautiful code, and that beauty can be across several dimensions). Giving software engineers a solution and telling them to do it, is ignoring a wealth of creative talent. Not encouraging them to improve their own processes, wastes human creativity. Forcing unnecessary motion, wastes human potential. There are a myriad of other ways human creativity is wasted in software delivery. Perhaps you can think of some you have personally experienced. Challenge Can you see these wastes in your environment? How would you act to get rid of them? Can agile be a tool to address these 8 lean wastes in software delivery?

Stand-ups & Standards & Kaizen Oh My

Odds are good that you’re familiar with the classic 3-question agile standup.  Have you ever wondered what a lean standup might look like?  Because it’s lean it’ll just be faster, right?  That’s what lean is really about, isn’t it?  Maybe we can do it in 2 questions if we’re leaner?  By looking at the standup (something we know) from a lean perspective, we’ll gain a better understanding of what lean really is.  We’ll get a better sense of how it compliments agile.  We’ll also begin to see how lean is different, but doesn’t conflict with agile.   As a basis, we’ll need to know about lean standards.  Feel free to check this out if you’d like a quick introduction or refresher.  Knowing that, let’s look at our standup. In Case You’re Unfamiliar If you don’t know what a stand-up is, or you don’t know what the “3 questions” are, then this section is for you. Imagine arriving at work every morning and among the first things you do is get in a circle with the rest of your team members.  Everyone then takes turns answering the following 3 questions. What did I do yesterday?What am I going to do today?Do I have any impediments? This will give everyone a sense of what everyone is doing.  It’ll give us a sense of whether we’re on track.  It’ll give us a chance to ask for and hopefully receive help. After this is over, we disband and go about doing the things we said we were going to do for the day. Stand ups & Standards & Visual Management When arriving at a stand-up, the first thing I want is a visual indicator of where we are against the standard.  I don’t want to ask 3 questions.  I don’t want to ask 2 questions.  I should not have to ask any questions.  I want to see where we are against the standard right now. The best thing I’m likely to have is a burn down chart with an ideal line.  This shows me the current state (how much is left to do as of now), the standard (how much should we have left to do as of now), and I can compare them. If my burn down is at or below the ideal line (our standard), I’m good. If my burn down is above the ideal, I’m out of standard.  I have more work to do than I should at this point in the plan.  I have a problem.   I have an opportunity for kaizen in order to return the system to the standard.  Our standup can be exactly the forum for that conversation. I look at the burn down and I see we are out of standard; we are behind schedule for this sprint.  What are we going to do today to fix this?  What other questions are necessary?  Are any questions necessary if we are within the standard? What Don’t I See? One important question you could ask at this point may be, Is there anything you know, but is not reflected in the burn-down and may disrupt our plan? That would be useful to know.  If anything ever comes up then you have a kaizen opportunity.  However, it’s not likely the kaizen opportunity you’re thinking of.  If there is a problem that someone knows about that is not visible in our visual management system (our burn-down), then we have a problem.  Why can’t I see the problem?  Why are we hiding it? Perhaps it is not work you must do, but a blocker or risk of some kind.  A server needed for testing is unavailable, work another team was doing for you was not deployed on schedule, etc.  No matter what these are, they deserve visibility, too.  Unlike manufacturing or other environments where the job itself provides visibility, in a knowledge industry the problems are things we know.  It is up to us to make them visible.   Either on your burn-down or on the board next to it, any impediments should also be made visible.  More than just having the space, people must be willing to take action to make problems visible (putting them on that board) so that they can be fixed.  This way, anyone looking at this information can see that there are problems.  If we can all see the problem, then we can see the kaizen opportunity and can bring our skills to the table in getting things back on track. Continuous PDCA A good perspective on the standup is that it is a continuous planning meeting; a way to reevaluate ourselves against the plan and make adjustments as necessary. The three question standup seems to serve the same purpose, but it gives a script rather than guidance as to the purpose.  Worse, the script ignores the use of visual standards to indicate a problem; this makes it easy to hide problems by just not saying them aloud.  When talking is the objective, we’ve set a meaningless goal that is easily achieved.  When we set our objective as looking for problems and making any corrections needed to get back on track, then we have a reason to invest the time.  Now the trick becomes setting ourselves up for success, so that we can do these things.  Visual management with a burn down provides a very useful method for fulfilling this purpose. This also provides a great argument for breaking backlog items into tasks and estimating hours.  It is not that the plan itself (the tasks) have much value, but by building that plan we’ve built ourselves an ideal target and can visually inspect our progress toward our goal as best as we know it today.  This also shifts the perspective of the estimate.  It is much less about how long I think this will take, but rather I think that if I haven’t solved this in 6 hours I should be asking for help.  I’ve given myself a time-box and I’ve given my teammates a visual indicator to know that I need help even if I don’t say it out loud.  If we leave our work as just the backlog items we’re working on, we have no way to inspect and adapt.  We can just make sure we’re busy. If we think of our daily cycle as a PDCA loop (plan, do, check, adjust) then 3 of these activities take place in the standup, making it a critically important function.  We CHECK our current progress against the sprint goal.  If there is a problem, we ADJUST.  We PLAN how today will keep us on track.  The rest of the day, we DO as planned.  Tomorrow, we’ll CHECK how we did with today’s plan.  Without a plan, we have nothing to check, and won’t know when to adjust.  We just do, and then we’re back to mere busyness. Stand-ups for Kaizen, Kaizen for Building Human Capability The objective is not to use a burn-down versus a build-up versus any other sort of sprint tracking tool  The key is having the discipline to do something and make it visual.   There should be a PLAN that we can see before going into the sprint.  For every day in our stand up, there should be a standard.   In our standup we should CHECK our progress against the standard.  If there is a problem, we should ADJUST.  We should PLAN a day that will keep us on track DOing the most valuable things we can.  We repeat this paragraph every day, creating a visually managed PDCA loop that makes use of a standard and kaizen.  It may feel slow and not be sexy.  But, if done deliberately it will build capabilities that are needed to become a highly successful and predictable software delivery team.   That, after all, should be the goal of a ritual like the stand up.  It isn’t just keeping us on track today.  It’s teaching us disciplined execution.  It teaches us to work with our eyes open and to be honest.  It teaches us to help each other.  It creates an environment where problems will abound.  Each problem is an opportunity for kaizen.  Each kaizen event is a chance to build the skills of our team members that go beyond just designing, coding and testing.  That is really the end game; creating a system for building better software by building the skills of our people every day. The ideal lean organization is a learning organization.  The daily stand-up is a venue for highlighting more problems than any other in agile.  Because it will surface the most problems, it is the ceremony that offers the most learning.  However, it will only do this if you let it.  You must make sure that it’s meaningful.  You must make sure you can see the things you need to see.  You must make sure that everyone is bringing to light all the things they know, since that is the only way we can become aware of a problem in a knowledge industry. It takes time to do this and it will feel slow.  Don’t be afraid to be deliberate and go slow; it’s the only way to go fast. Challenge In your stand-ups, is everyone actively engaged or is everyone just waiting for their turn to talk?  How many cell phones are in use? Right now, can you see the current status of your team in reaching your sprint or release objectives? Do you deeply understand what you’re looking at?  Do you trust what you’re seeing? Can everyone on the team see the status and do they all know how to interpret what they are seeing?  Do they trust it? Are problem solving opportunities found in the standup handled like explicit learning opportunities for team members? Do the leaders monitor how the problem was solved to make sure that people were being deliberate and learning rather than just patching and running?