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?

Lean Standards

Because it is essential to understanding lean (and I want to refer to this continuously), today we’ll talk about lean standards.  If you’re already thinking that standards aren’t lean (or agile) because they’re rigid, audited for compliance, and defended from change, then you are not familiar with lean standards.   Hello Lean Standards To quickly introduce lean standard work, we’ll go to the grandfather of lean  Today’s standardization…is the necessary foundation on which tomorrow’s improvements will be based.  If you think “standardization” as the best you know today, but which is to be improved tomorrow – you get somewhere.  But if you think of standards as confining, then progress stops. – Henry Ford Standard work is typically designed by those who know the work best.  These are also the people who are most well equipped to evaluate changes to the standard.  These are the people actually doing the work. The key is that everyone in that role follows the standard.  When someone invents a way to do the work better, the standard is changed.  Because everyone follows the standard, the improvement cascades across the entire team.  In this way having a standard is a tool for individual empowerment, innovation, and continuous improvement (kaizen).  It allows us to prove that a change is an improvement (by comparing it to the current standard), rather than demonstrating that we have found merely another way of doing the job.   Visual Management For standards, there should be a simple visual control so that everyone can see if something is within the standard.   This can be the job instructions (posted outward so that others can see that we are following the standard).  If we were on an assembly line this might be colored regions on the floor indicating at which point you should be done with your job and getting ready for the next car.  If you see someone working on a car after that marker, they are out of standard.  Because there is something out of standard, there is a problem.  Because there is a problem, there is an opportunity for kaizen. Standards & Kaizen There are several forms of kaizen.  The most abundant kind involves just handling the problems the world throws at us everyday.  Whenever anything is out of standard (a misshapen part, a misplaced tool, a person behind the takt, code coverage is too low) then there is a problem; there is an opportunity for kaizen.  We must strive to sustain the standard. Bigger process improvements, that most people think of when they hear “kaizen”, are typically obtained by changing the standard; sometimes dramatically.  Such a change means that you are out of standard more often and must find a way to improve the process. Agile Standards Agile alludes to, but does not include the idea of standards.  Scrum, being a bit more explicit, gets closer but is also lacking.  The prescribed Scrum activities can give way to standards, but they do not provide this. We’ll find that in most environments, agile benefits greatly from the use of lean standard work and visual management.  However, we’ll draw attention to a good use of lean standards as we explore topics rather than trying to create a list here.  For your consideration, here are the three agile principles that insinuate the presence of a standard.    9. Continuous attention to technical excellence and good design enhances agility. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Challenge Do you have any standards that support those agile principles?  Any best practices? Do you have visual management to support those standards?  Can everyone see and do they use these? When something is out of standard, is kaizen practiced to immediately fix the problem?

Why > Busy

Earlier, we talked about how busyness works against agile & lean.  Today, we’ll look at how to replace busyness with value delivery (the heart of agile & lean). Given that busyness has been framed as the enemy, you may be thinking:  That sounds great, but there are still salaries being paid and clients expect results; if I’m not making sure everyone’s time is fully utilized, how do I make sure we’re adding value? The first problem that needs to be overcome, is that you may be confusing busyness with value creation.  It is true that to deliver value, you must do something.  It is not true that by doing something you’re delivering value. To even talk about value delivery, though, we first need to know what “value” actually is to us. To start understanding, let’s borrow some wisdom from the great entrepreneur, David Packard  I want to discuss why a company exists in the first place. In other words, why are we here? I think many people assume, wrongly, that a company exists solely to make money. Money is an important part of a company’s existence, if the company is any good. But a result is not a cause. We have to go deeper and find the real reason for our being. As we investigate this, we inevitably come to the conclusion that a group of people get together and exist as an institution that we call a company, so that they are able to accomplish something collectively that they could not accomplish separately – they make a contribution to society, a phrase which sounds trite but is fundamental – David Packard In short, companies don’t exist to make money.  Companies are created to serve some purpose and in doing so they make money.  Making money means they can keep fulfilling that purpose (or do more of that purpose if they make a lot of money).  You can think of money in a company as acting like blood in your body.  You need blood to stay alive, but you don’t live for your blood.  Likewise, your team does not exist to write code.  Your team writes code in order to serve some greater purpose. Challenge Why does your software delivery team exist? If your answer includes the phrase or idea “writing code” (or anything like that), then you’re missing the point.   YOU ARE NOT WHAT YOU DO WHAT YOU DO IS NOT WHY YOU DO IT If all you understand is what you do, then you will never get beyond busyness; merely doing more stuff to stay busy.  Unfortunately “what” we do is the most obvious thing about us.  We see developers write code.  We know how to write code.  We’re trained to write code.  When people ask us what we do (which they always do), we say we write code. It’s absolutely true, that is what we do. Because this is such a simple thing to observe and understand, it begins to become the default way in which we view ourselves, our role, and if we’re not careful it becomes our purpose.   It is not enough to be busy. So are the ants. The question is: What are we busy about? -Henry David Thoreau If you want to get beyond busyness then your first step, which may be very uncomfortable, is to find out why your team exists. Discovering Why If the answer is not obvious, there are a few things you can try to get at the answer. The easiest thing is to just talk to everyone and look for a unifying purpose or motivator. If you want to make it a more interactive experience, then bring your whole team together.  Give everyone an index card and have them all write down why they think the team exists.  Collect and shuffle the responses.  Read them aloud and have a conversation to find which idea, if any, the team generally agrees as being why they exist.  Not only will you (hopefully) arrive at a purpose, you may learn a lot about why disagreements and conflict exist on the team.  If people are applying different values to evaluate the same opportunities, then they may be talking past each other and seeing the other person in a negative way rather than understanding that it is a difference in the values being applied rather than a real difference of opinion about the opportunities. Hopefully something emerged organically in that talk.  If it didn’t (or you don’t feel comfortable running that game), you may need to reverse engineer your team’s purpose. Consider your current trajectory (look at your backlog).  What launched you in at direction?  What problem were you trying to solve?  What opportunity were you pursuing?  For whom is this intended?  If anything appropriate comes out of that, then embrace it.  Now you can stop assuming that your current trajectory is the right way forward and you can start looking for new ways to better fulfill your purpose. Still have nothing?  If you can’t find a singular purpose, then it’s up to you to create a cause.  Sound silly?  It’s not.  Consider the custom software company Menlo Innovations out of Ann Arbor Michigan.  There is no one client.  There is no one industry.  There is no one technology.  So why do they do what they do?  To put it in their own words, Our mission as an organization is to end human suffering in the world as it relates to technology™. What does that mean?  They try to make the creation and use of technology a joyful experience for their team members and their clients and their clients’ clients.  That’s a purpose that doesn’t depend on industry or technology.  So how would a Menlonian (their word for themselves) evaluate a project as being worth doing?  They don’t take work to be busy.  Since they strive for a joyful experience, clients need to want the same thing.  The client must be willing to work with Menlo in a way that is respectful to the Menlonians.  The project must allow the Menlonians the latitude to create a solution that helps end human suffering as it relates to technology, which means letting Menlo take the time to deeply understanding the problem the client is solving rather than doing what the client says they want.   Will that “why” work for you?  Probably not.  But it doesn’t matter what your “why” is as long as you have one and your team can understand and rally behind it. Start with Why Once you’ve discovered (or created) your “why”, start talking about it.   Make it something you talk about regularly. Put up posters. Put it on mugs. Buy t-shirts. Buy stickers. Make it visible. Make sure it’s known by everyone. Why is that helpful?  It gives everyone on the team a frame of reference from which every decision (big or small) can be evaluated.  It gives you a way to prioritize a backlog that is tied to values rather than just dollars.  It gives you a way to evaluate future team members.  It gives future team members a way to evaluate you.  It gives you a way to evaluate clients.  It gives potential clients a way to evaluate you. There is a vast amount of dialogue that could be had on this topic.  More than can be covered in this article.  If you want to go deeper (you should) then visit https://www.startwithwhy.com/ and get Simon Sinek’s book by the same name (Start with Why).  Once you understand the power of this way of thinking, it will help you to break free of busyness and deliver value in a way you haven’t ever done before. Reflection Knowing why is more than just a way for the team to look at the outside world, it should be a way for the team to look at itself.   How does your team measure success? If a team values unwavering predictability, then perhaps up-time will be a key metric.   If a team values saving their clients’ time, then perhaps each sprint they’ll calculate the number of yearly-human-hours of manual effort they’ve removed from a process and judge their success on that number.   Both are good, but only if they align with your purpose. As a question, “How do you measure success?” is a trap if you don’t know your purpose.  How can you measure being successful if you don’t know what “success” is?  Once you know what you value, you can figure out what success looks like, then you can figure out how to measure that.  Once you’re measuring it (if you’re into that), you can make sure you’re being true to your purpose. Prioritization The most precious resources we have are our time and creativity.  Teams prioritize backlogs to make sure that these limited resources are applied to things that will deliver the most value.   If I can’t measure how many dollars will be returned by something in our backlog, is it worth doing?   I’m not sure.  Against what standard are we evaluating it?  Not knowing the dollars only matters if our purpose is to make dollars.  Dollars are something we need, but it’s not why we do what we do. Knowing how we evaluate our work gives us a way to consistently prioritize as a team.  Even if the entire team does not prioritize the backlog, every day every team member is making decisions about where to invest their time and mind.  By making sure everyone understands the values and can prioritize on their own, then everyone will be making the investments that will maximize the value created by the team.  Those decisions may be about the backlog, which meetings to attend, who to talk to, what to document, how to engineer a solution, or almost anything else in their day.  In other words, it helps us to follow the agile principle 10. Simplicity – the art of maximizing the amount of work not done – is essential. In lean terms, getting rid of all this busyness helps us work down all 8 wastes (at least, it stops exacerbating them).  It’s also helps us to understand which things we do that add value, and which things don’t.  In turn, that means we work to create a process that maximizes the output of whatever it is we value and stop doing things that don’t contribute to our values. How does starting with “why” help us to get rid of non-value added tasks?   By aligning decision making.  There is no better way to ensure that distributed decision making is aligned than to make sure everyone is using a shared value system.  Once everyone is using the same values, you can have much more confidence in the decision making of each individual.  That makes it much easier to embrace the agile principle  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Starting from where we are, how do we establish a shared value system? Start with why.

The Prime Waste – Busyness

There is a common feeling that indicates the presence of all 8 wastes. It was best described by my former leader when he summarized what team members were telling him: I’m too busy doing my job, to do my job. By taking a step back, it becomes obvious how constant busyness undermines the business by inviting all 8 wastes and creating a vicious cycle. Overproduction, Inventory & Defects Fans of Toyota will recognize that I’m starting with Taiichi Ohno’s most egregious waste; overproduction. This is intentional. Overproduction can be seen as enabling the other wastes, however, overproduction is more accurately seen as the problem’s symptom, not it’s source. The root issue tends to be a bias toward busyness. If I only feel valuable when doing my job, that is what I will do. Often there are metrics, rewards, and even my continued employment that all hinge upon spending time doing that thing for which I was hired (write code, test software, write specifications, etc.). If my goal is to keep myself busy, that is very attainable. I will create as fast as I can and pile output upon whichever unfortunate fool happens to be next in the chain. I don’t care if those team members can keep up; it only makes me look better if they cannot. It’s their job to figure out how to keep up. Even worse, my success may be measured by the build up of a work backlog for the next team (someone needs to make sure they’re busy). The bigger that backlog, the greater the testament to just how awesome I am; that whole QA team can’t keep up with my coding speed – so congratulate, reward, and promote me. Once I’ve buried the next team under a mountain of work, I don’t stop and look for opportunities for my own process improvement (test automation, new techniques, refactoring, etc.). I’ll get more accolades by starting the next project or iteration early and further burying my extended team under an even bigger backlog. The worst part about this cycle is that by constantly running ahead of my team, I’m delaying feedback loops. If QA finds a bug in my code, I’ve already forgotten about that module and I’m a full sprint into something else. Now we need to have a debate about which is more important, the quality of some feature from weeks ago that is “done” or avoiding “thrash” by staying busy on our new #1 priority. Which is more important; quality or busyness?  Too often, busyness. On the bright side, once all of those defects pile up, we can introduce a maintenance team that can be kept busy fixing all of the work we were too busy to do right the first time. 8. Sustainable development, able to maintain a constant pace Over-processing Adding unnecessary (or unrequested or lower value or gold plated) features is a sure-fire way to get some kudos upon delivery, especially if still delivered on time and on budget.  Even better, it shows how well we utilized our time by staying busy doing stuff. Then, there’s the scope we convince the client to add. What if traffic to your website suddenly increases 100 fold? You’ll certainly need dynamic load balancing in the cloud if that happens, so let’s make sure we implement that best practice now.  We could defer that work until the need presents itself or challenge ourselves to see if we can handle the load with a more conservative approach, but that won’t keep us busy. Was there a different project of greater value that could have been started? Possibly. Did we take the time to invest into our own processes by automating integration testing? Possibly, but probably not. Do we know for a fact the the client actually wants and will use these features, or are they simply things we thought they may want at some point in the future? According to the Standish Group’s 2013 Chaos Report, about 50% of software system features are essentially never used. If we spent more time questioning what we should be doing (or finding more conservative ways of doing it) we may not look so busy, but would that be a bad thing? 10. Simplicity – the art of maximizing the amount of work not done – is essential. Motion, Transport & Waiting Motion & transport are busyness that create the illusion of productivity. What if I were an analyst or PO? If I need to talk to a lot of people then the value I’m generating could be measured by how full my calendar is, right? That’s a testament to how busy, thus important, I am. Unfortunately, this becomes a vicious cycle. When information is needed by an engineer, it cannot be extracted from my brain (transport) because the I’m too busy in all those meetings. The more team members need my answers, the busier I become. This can escalate until team members are waiting days for answers. Should they just send an e-mail and hope for a clear enough response? Should they just work on lower priority work until they can get an answer? Should they just guess at what the answer might be and hope for the best? It’d be a shame if the engineers stopped working in order to draw attention to the problem; they can’t get the information they need to add client value. More to the point, which is more important for me as the analyst or product owner with all that knowledge; the meeting I’m busy with or making sure that those directly adding client value have what they need to be successful right now? 4. Close, daily cooperation between business people and developers Unused Creativity This may not be the prime waste, but it is the most costly to the team members, to the business, and to society. If I keep myself too busy, I don’t give myself the time to reflect and improve. These improvements could be in my craft. These improvements may be investments in the development of junior teammates. These improvements could be in the processes of my team. These improvements could be in the processes of my extended team. These improvements could be shared with the whole organization (or to the world). These improvements could yield more software of greater quality to our clients. Too often, these improvements come slowly or not at all. We’re too busy doing our jobs to do our jobs the way we know they ought to be done. 9. Continuous attention to technical excellence and good design How Agile Tackles Busyness By using a short term, iterative, PDCA cycle, we get many benefits. Cross-functional teams can make sure they are planning only as much as they can complete together. Rather than focusing on keeping everyone busy, we shift the conversation to what needs to be done to deliver client value. As interruptions come up (they will) we can now judge their value versus the plan and make an informed decision. If our goal was just busyness, we’d just toss that interruption onto the list of things to do and just keep trying to keep up. We can also check our performance against the plan and reflect. This gives us a chance to see how we can improve. It can be in our skills, our process, or anything else. But to that point, we take the time to implement these changes which will help us deliver more value in the long term. 3. Working software is delivered frequently (weeks rather than months) How Do I Do That? This is not easy. What is often missing, is patience and discipline. The ultimate goal is not to “be agile” today and coast forever. It’s to create the opportunity to recognize and implement the next step in our journey of continuous self improvement. Creating these opportunities means that we must create a plan, we must execute it (learning by doing), check against what we expected, reflect on what we learned, and figure out the next step in our journey. There is less “doing” in that process than most people are comfortable with. It feels as though we’re not doing what we’re supposed to be doing (writing code, testing, etc,). It takes a lot of will power and long term vision to recognize that the best thing for team, the organization, and the client is to move a little slower so that we can ultimately move much faster. What If I Don’t Know How To Do That? What if you apply agile and lean concepts incorrectly? Don’t worry. If you’re regularly reflecting and learning, you’ll find those problems and fix them. Even if you apply the concepts perfectly, you’ll still find problems and fix them. Reality is messy, it will offer you chances to improve. The most important thing is that you give yourself and your team the time to reflect, to learn, and to try new ways to improve. Give yourself time to ask hard questions and make sure you’re solving the right problem and not just finding the fastest way to stay busy. However, it’s ultimately up to you to find a way to be a little less busy doing your job, so that you can actually do your job. Challenge Here is some litmus tests for busyness in your professional life. If you’re in a direct value-adding role, are you taking time to improve the process of software delivery systemically for the long run, or are you trying to maximize your productive time to keep up with the schedule? If you’re in an indirect role, are your efforts focused primarily at supporting those directly adding client value or are you not as close to them as you’d like because other projects are keeping you too busy?

Cross-Functional Teams & Production Cells

Prior to lean thinking, Taylorism was the dominant managerial philosophy in industry (and it is still a powerful influence).  Labor efficiency is a pillar of this approach.  To achieve that goal, a common practice was to group together all sets of similar equipment (lathes, drills, presses, etc.).  This allowed the technicians to specialize, allowed for redundancies in case one machine went down, and provided a very easy set of metrics by which each set of machines could be measured for success (output, utilization, machine up-time, etc.).  Now our leaders are equipped with metrics that tell us about how well their investment is being managed and we have specialized people working with specialized machines that are being fully utilized.  Clearly, this is going to maximize the amount of value we’re creating, right? The same philosophy underscores many software delivery organizations.  People are put into functional groups (BA, QA, architect, developer, etc.).  Each of these groups is measured for productivity based on hours worked (something like machine up-time) and output (code, tests run, designs written, etc.).  It’s the functional manager’s job to make sure that his group has a full queue of work from which to pull at any time in order to make sure that everyone is fully utilized.  If all of these expensive humans are constantly doing their thing, we’re definitely delivering the most value, right?  Let me tell you a story about this approach and unintended consequences.  A few people create a new factory for creating chairs.  There is a single loading bay at which trucks regularly deliver foam and fabric that is used by the looms and trained techs on Phil’s team to create the sitting surfaces.  From the same loading bay, different trucks regularly drop off metal and matte black plastic used by Mary’s team to create the chair frames and covers.  Adam’s team is the final stop.  They assemble the chairs and prepare them for sale.  All told, this is not a complex process and has been modeled below. This seemed to work for a few batches, but shortly after the first few clients received their chairs, defects were reported.  We had hoped to be our own QA, but Phil, Mary, & Adam were so focused on getting things done that they neglected to really scrutinize their own (or each others work) and quality suffered.  They had a long talk with senior management about the quality problems, and decided that it’s best if these leaders keep their focus on execution and we’ll hire Connor to lead our new QA team. That seemed to work out pretty well, but Adam’s team kept pulling ahead of Mary’s team and the metal frames.  As a result, Adam’s team wasn’t well enough utilized and he missed his bonus for the month.  Mary managed to get some more machines in place to fix the problem going forward, but then one of Phil’s looms broke down and Adam ran out of material again.  After a second month with no bonuses, Adam decided to fix the problem once and for all.  He idled his team for a week so that Phil & Mary’s teams could build a buffer. Now he had a full week of seating surfaces and frames that his team could run through.  If any of Phil or Mary’s machines went down, Adam would not be impacted for almost a week.   Now we have a slightly more complex process.   Unfortunately, Adam and his team underestimated the difficulty in storing and accessing all of these components.  They ended up needing to invest into a somewhat expensive storage solution and a few forklift drivers who could ferry components from the trucks to Phil & Mary.  The drivers would then take batches from Phil & Mary and put them into storage.  As Adam’s team started to get to the end of they’re materials they’d call the forklifts to have them pull more frames and seats from those storage spaces and bring them over for final assembly. Our real process now looks a bit more like this. When we organize functionally, it’s easy to paint a very simple picture about how those systems feed each other.  Unfortunately, it’s rarely the complete truth. Organizing functionally creates point efficiencies in an inefficient system.  As pictured above, that system looks more like a warehousing operation than anything else.  It is.  There’s much more inventory on those forklifts and in those queues than is in any of the actual value-adding steps (remember, we’ve optimized those).   What’s worse, QA is happening at the very end.  Because we want to make sure that Adam won’t be stopped by upstream issues, if there is a problem with the seat frames, the flaw may have already permeated through a full week of seat frames.  Now we’ll need to decide what to do with a week of defective parts.  We will either need to be fix them all (expensive), throw them away (expensive) or we’ll just accept the quality deficiency (expensive). Lean manufacturing challenged the traditional mindset and introduced the idea of a “production cell”, something now generally referred to as cellular manufacturing.  Within a production cell, we would expect to find all of the machines and equipment necessary to produce a collection of similar products that will be passed onto the client.  This had several important consequences.  However, before we go any further it is worth highlighting that the machines are organized based on how they add value, not what they do. If our factory implemented production cells, maybe we end up with two.  The first cell has all of the machines and team members needed to take foam, fabric, metal and plastic in order to create chairs.  The second cell may have the exact same configuration, but operates in parallel.  If we want to expand capacity, we simply add another cell. A side effect of the production cell is that these machines won’t be as highly utilized. The same people operating the loom may also be handling the metal and they’re only going to be doing one thing at a time.  The machines utilization will go down.  Counterintuitively, this produces something that is more efficient.  We’ve essentially accepted point inefficiencies for system-wide efficiencies.  Where did all of that inventory go?  It’s gone.  Our need for forklifts is also nearly eliminated. Now consider our quality problem. If anyone in our cell produces a defective piece, we have one defective piece.  We can fix it, educate the person, and move on.  We are all responsible for all of the machines and pieces in our cell, so nothing is out of bounds for our own improvement process. Our incentives are also likely to shift.  Rather than measuring machine utilization or up-time, we’d be much more apt to measure the cell based on it’s purpose; the value we’re generating for the client.  In this case, perhaps the number of chairs produced.  And now, back to agile software development. Have you ever worked in a world where there is a queue of requests stored somewhere on a server?   Perhaps it’s in a CRM or ERP system by the name of TFS or JIRA.  Maybe it’s just an Excel workbook.  Either way, your computer is your forklift and the backend for that system is your warehouse.  Odds are good that every day you open that tool to find out what needs to be done (the forklift pulling material from the warehouse).  You’ll do your thing and when you’re done you go back to the tool and update the state of the task to indicate that you’re done (the forklift putting the material in the storage queue for the next stage).   Our raw material is information and the database is our warehouse.   Now let’s talk about a software delivery firm that has a few functional teams; DBAs, designers, and developers.   On day 1, our DBAs pull from that queue and start working on the schema.  After all, no proper development can begin without a schema so we need to make sure that our DBAs are working at least a week ahead of our developers. Perhaps also on day 1, our designers start mocking up the UI and getting some feedback.  We can’t let them wait until everything else is done to get started because they’ll have to go through far more iterations than anyone else once the client begins seeing it.  They simply can’t afford to wait. Our development leader will be monitoring the progress of these teams, and once the schema is done and UI is mocked up, he’ll find a developer who has capacity.  That developer will be given the task of picking up those pieces, adding some business logic, and making sure everything works together as expected. Lastly, our QA team is monitoring that queue and deployment reports to see which tasks have been promoted to beta.  Once something new pops up, they begin testing new work and executing routine regression tests. Sound familiar? If not, does it look familiar? In agile, there is the notion of a cross-functional teams.  An agile team is designed to have all of the skills necessary to deliver the value expected by our client.   Moreover, we encourage agile teams to measure they’re productivity not by hours worked, but by the delivery of software.  After all, working software is the primary measure of progress.    Sound familiar?  How about a picture? I’ve used work tracking systems to illustrate the system-wide inefficiencies of a functionally segregated IT organization.  There is truth in that, but it’s not quite the truth.  If that’s not it, then from where does the improvement come? Cross-functional teams gain system-side efficiency by reducing or eliminating explicit knowledge transfer (read: handoffs). Each handoff consists of wrapping up work in a pretty bow, which takes time.  It is usually done electronically.  This means that there is usually some notes added to a backlog item or simply a closed task.  This tells the next person things are ready, but that’s it.  There is no context.  There is no warning of what things may be incorrect and need another look.  No one knows the assumptions that were made but the person who did the work and that is rarely shared.  The next person must re-learn much of what the previous person discovered, but they must re-learn it on their own.  This cycle of learning, doing, handing off, learning, doing, handing off, learning, doing, handing off is ripe with inefficiencies and opportunities for miscommunications.  Try asking a QA team member who has worked in a functional organization how often they spent days testing something only to learn that it was actually not ready and the engineers were still working on it; they simply forgot to update the task. There is much more that can, and will, be said about knowledge transfer as a large factor in software delivery organizations.  Ignoring knowledge transfer can be done at the peril of leadership.  But for our purposes, that’s not needed to see that an agile cross-functional team and a lean production cell are essentially the same solution to the same problem. In both cases, we accept point inefficiencies in order to collect system-wide efficiency.

ILean

Agile enthusiasts rightly praise the agile approach to software development. It puts a high value on humans, it encourages tight client collaboration, delivery of client value, and it makes sure that everyone (client & engineer alike) is working together toward a common goal. When framed in this way you may wonder why anyone would ever do things differently. Does it shock you to learn that many software delivery organizations do operate differently? Is it even more shocking to learn that many organizations in many industries operate differently? Perhaps most of all, is it shocking to learn that many of the problems in software delivery that agile has helped overcome, had already been overcome generations earlier in other industries in much the same way? What has been done for software delivery is fantastic. However, now it’s time to look beyond just agile concepts, agile methodologies, and understand how these fit into the bigger picture. This is especially true for any organizations that have a software delivery function but are not strictly software companies. Does this mean that it’s time for a while new set of agile ideas and methodologies? Not necessarily. What it does mean, is that we should look first at how organizations operate; see what philosophies and methodologies drive value outside of software delivery and then we can do two things. We can see how agile fulfills (or not) these principles so that we can see where non-software teams may benefit from agile ideas. We can also look at agile from the lense of operations in a generic way to see how it implements the ideas from other industries and what new value it may bring to those arenas. For us, that means something very specific. We’ll be talking about how agile is a very good implementation of lean in a creative as opposed to manufacturing industry. This may sound blasphemous to some, but soon you’ll believe and believing is seeing. At this point I’m going to leave you hanging. Not because the answers aren’t available, but because they are subtle and understanding cannot be hurried. It will take us some time. We will talk about agile, software delivery, Dev-Ops, lean, teams, operations, leadership, humans, and host of other topics. Through these talks we will begin to see the agile in lean.