thinking – Page 4 – its what i do

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.

The Worst Waste – Unused Human Creativity

Busyness may be the prime waste and a cause of the others, but it is not the worst. Only one of the wastes is an asset that is lost forever if not used; human creativity. Unused Creativity > The Other 7 Let’s consider the other 7 wastes. Waiting wastes time, which also cannot be recovered for individuals. For a company, there will always be more time. We’re just wasting money paying people to wait. Over production and inventory are waste, but they’re mostly financial. Our money is locked up in warehouses. That’s a poor way to use money, but if we have enough then why worry about those dollars. Transport & motion are both wasteful. These are actions that don’t produce client value; we’re paying people for a valueless activity and wasting money. As long as these costs aren’t too big, we’ll be fine. Over processing costs us time doing work clients don’t need. This adds to costs without adding value. It lowers competitiveness, but only a little. Defects cost us a few things; reputation, time, money, etc. given enough time and effort, we can recover from these. Why is Unused Human Creativity the Worst? Any agile or lean operation, requires the constant addition of new ideas to improve the process. Whether it’s a scrum retro or a lean kaizen, we’re constantly applying brain power to improve the process. Just sustaining such an operation requires this, since all processes naturally degrade. Unlike time & money, human creativity is lost if not used. It is very contextually sensitive. There must be a problem, the time to invest into finding an idea, and the support to invest into applying the idea. If any of these elements is lacking, there is irreparable harm to mankind. That flash of insight may never be had by another person. Money can’t buy back missed improvements or ideas. If there is no support to implement the idea, that creates a negative feedback loop, which may cause the person to stop applying human creativity to their work. That is perhaps the most tragic outcome and is too common in inhuman and bureaucratic organizations. Not having nor acting upon creative impulses robs people of their very humanity. It denies them the chance to grow as an individual and improve the world they live in. A Learning Organization by Using Human Creativity Many people describe the zenith of a lean organization as a “learning” organization, but that is a bit of a misnomer. These aren’t companies that just learn, these would be more correctly described as companies that are harnessin the collective creativity of their team members in a rigorous way (like through PDCA loops) to learn the best way of being and competing. The organization learns, but the fuel is freedom to pursue and apply human creativity at an individual and team level. Unused Creativity in the Other 7 Wastes Waiting is only a loss if that time could have been spent in a more valuable way. Most pointedly, if that person was applying some human brain power to a problem instead of waiting. That also forms a counter point, is waiting a waste if that time is invested into applying human creativity into a problem? Like, perhaps, the problem of how to eliminate this waiting from the process? Over productions and inventory create longer feedback loops. Rather than applying human creativity to a problem when it arises, we waste that opportunity and let weeks or months of inventory build up before we address it. Now we have to apply human creativity to fix real the problem, and to the problem of all that inventory. Or, we choose not to do that and accept the defects. To be able to recover from defects rather than perpetuate them, we must apply human minds to find the source of the defect and insure it doesn’t happen again. When we don’t do this, we will keep a phasing similar defects. Transport & motion require people invest human mind power to a task that isn’t helping anyone. We’re wasting creativity by moving stuff rather than doing stuff. When we’re over processing, we’re applying human creativity to a less valuable problem. Conclusion Why is unused human creativity the worst? Perhaps most simply, using human creativity is the only way to eliminate the other 7 wastes. By wasting human creativity, we’re making all the other wastes acceptable. The more we do that, the more invisible they become. The more invisible they become, the less we’ll invest into fixing them. The less we invest into fixing them, the less likely people will be to come forth with ideas to improve the process. When people start accepting the world as it is rather than applying their talents to improving it, we’ve deprived them of what it means to be human.

Microsoft as Agile, but not Enterprise Agile

Microsoft is a dominant player in IT. But is it agile? Does it display enterprise agility? Organization Microsoft has gone through some re-orgs in the period we’ll look at. The most recent re-org created 5 engineering groups and a bunch of non-engineering groups. Those engineering groups are largely responsible for themselves are are: Operating Systems (Windows) Cloud & Enterprise (Visual Studio) Applications & Services (Office) Devices & Studios (x-box) Dynamics (ERP) Each of these has done a very good job competing in their respective markets. The x-box has given the PlayStation a run for it’s money. Visual Studio tends to defeat eclipse when put to the test. Office is king in productivity software. As for operating systems, Windows is still getting by with something like 90% of the market. Microsoft tends to win in every market in which it decides to compete. Within each market, Microsoft tends to display agility. However, there are shortcomings. When we take a broader view of the entire organization, it falls far short of the type of enterprise agility we saw with Apple. Operating System Inventory To start, we’ll consider Microsoft’s flagship product; Windows. As previously stated, Microsoft has about 90% of the consumer operating system market. Despite that dominance, Microsoft has clear indications of not being agile in the market. To understand, let’s look at a picture with data provided by net applications as of March 2015. This is a pie chart of the current market share of each version of Windows according to how many years ago it was released. What’s clear, is that every 2~6 years Microsoft releases a new version of Windows. Operating systems are a complex product, so perhaps this is the shortest sustainable pace. If that’s true, then the Windows team is doing an alright job at iterating and releasing new software. What’s the problem? The two most popular versions of Windows are 6 and 14 years old. Does that mean that the more modern Windows operating systems are lousy? Not at all. What it does tell us is that the more recent Windows products aren’t solving problems that people care about. If it’s not solving any problems for me, why upgrade? The windows team can keep being agile and delivering frequently. They could even become more agile and keep delivering more frequently as they’ve been doing so far this decade (an average of a 2 year release cycle). This, however, is not enterprise agility. If there were a lean system being used by Microsoft then the problem is clear. Microsoft is staying busy and building a big inventory of new OSes and there is no demand for what is being produced. From a lean perspective the message to Microsoft is clear. Stop what you’re doing. Just-in-Time Operating System For comparison, let’s take a look at that diagram for Apple’s OS X. How often does apple release a new OS? Just about every year. Even in this domain, Apple displays a truer agile principle: 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. The adoption of Apple’s OS is also quite heavily weighted to the newest version. More than half of Macs are running an OS that’s less than a year old. Fully 90% of Macs are running an OS that is newer than Microsoft’s most popular version of Windows. What does this tell Apple? People are finding value in their newer operating systems. Applying the update is valuable enough to be worth the hassle and risk. Should Apple invest more into the OS team? Maybe. A case could certainly be made for that. At a minimum, they shouldn’t slow it down. People clearly find a lot of value in what they’re producing. More Agile < Enterprise Agility As Microsoft demonstrates, you can have agile characteristics in a team or a division and not have enterprise agility. You can even be dominant in many industries and not really demonstrate enterprise agility. What would enterprise agility look like at Microsoft? I don’t know. What is clear is that instead of investing so much talent into the Windows platform, they should be applying those talents to other problems that exist in peoples’ lives. People are telling Microsoft that they care less about the operating system updates than something else. It’s up to Microsoft to find out what that something else is, drop less valuable products, and focus their vast and immensely talented workforce to the problems that people would value having solved. Microsoft has the talent to do almost anything they desire. But do they have the discipline to demonstrate enterprise agility?

Apple, Agile, & Iterative Platform Building

Some people struggle with Apple as an example of enterprise agility. It is a behemoth known for building massive (and sticky) platforms over many years. Are they the opposite of agile? Or are we misunderstanding Apple’s rise? Creeping Determinism Be careful of creeping determinism. Once we know what Apple did and that it was successful, we all begin to think that their successful outcome was widely expected and understood all along. We lose sight of all the forks in the road Apple could have taken, the analysts who advised those paths, the competitors who took them. We see only the well trodden path directly from here to where we were and say “obviously that was the way to go”. But is that how Apple got here? Forks in the Road Let’s start with the iPod. It solved a problem. Many MP3 players were hard to work with and had little capacity. Apple made the software easy, and the capacity big. Rather than making the software Apple bought the company SoundJam MP and re-branded their product. The first version did not support iPods or the next gen OSX operating system. Version 2 added support for the modern OSX operating system and iPods. In these two years, Apple would have seen the fallout of file sharing, lawsuits, people’s dissatisfaction with the price and content of CDs, and the hassle of needing to go to the store, buy, rip, transfer and then listen to music. To solve all these problems, version 4 of iTunes added the iTunes Music Store and a windows based iTunes app. That’s 3 years between the debut of the iPod (2001) and the release of the iTunes Music Store (2004). Was a music store really an obvious next step after the iPod? Other music services had been offering pay per song sales for years. Why would an iTunes music store fare better in a pay per song market? Why not try something truly innovative like cloud based music storage? 2 years before the iPod (1999) the web site MP3.com released a digital locker for CDs that let users insert a CD, the service would acknowledge ownership, and the user could then stream that album from the cloud. This is much like services from Amazon and Apple today. Why not use this model for iTunes instead? Why not just offer a subscription for unlimited music streaming? Careful of your logic, you’re probably inserting some creeping determinism. Here’s another fun point that is obvious in hindsight. It was the iTunes Music Store. Was there a plan to add podcasts (2005)? What about books (2010)? Movies (2006)? Apple was thinking about the current problem, and the next logical step; some type of music store. If it failed, they’d try a different model (like they did with their cloud services several times). Of course, having this digital store would give them options down the line (books, movies, etc). But for the moment, music was all they needed to know; the rest was just a distraction. Not worrying about anything else, iTunes Music Store becomes a pretty good name. From 2005 on, there were constant changes to iTunes (the app & store), but the investment began to wane. Why? Apple could have introduced cheaper iPods, included more music sales, offer limited editions iPods, and done all sorts of other things to generate more money in this ecosystem. That would make sense wouldn’t it? We have this user base, we want to keep it. Careful of your logic, you’re probably inserting some creeping determinism. For Apple, the next step was a different direction. iPods still had a lot of life left, but that problem was basically solved. At least, solved enough that there were new opportunities of greater significance in peoples’ lives than cheaper iPods and music. What direction? TV? Phones? Servers? Careful of your logic, you’re probably inserting some creeping determinism. Apple tried all of those. One failed and was killed. One was completely thrown away and redone. One was a great success. Which should Apple have done first? Careful of your logic, you’re probably inserting some creeping determinism. Jobsonian Vision People talk about Apple as if it has some master plan starting in the late 90s when Jobs returned to Apple and is still being executed today. They think there is one long cohesive plan that has gotten Apple here. To believe that, you must believe that somewhere there is a plan that said (in this order): Create music player Create portable MP3 player Get the two to play nice Create a music store Add videos to the music store And TV shows to the music store Add movies to the music store Create cellular phone Add apps to the music store Create tablet computer Recognize purchased CDs in a streaming music cloud Add subscription music That plan doesn’t exist. Sure, pieces were talked about years before they happened. They only happened once the combination of technology and customer demand made it a wise next step, Slow = Fast The only reason Apple’s ecosystem was successful, is that they went slow. They grew with the customer’s demands. They took feedback every year and iterated with a laser like focus on the next steps for the next year. What’s the lesson for your own platform building? Go slow. Build it with your customers. Try to build it in a way that will give you options down the line. Don’t think too much about what those options might be. Postpone implementing options until necessary. If you do it well, you’ll look back and think about how obvious it always was that you would end up where you are. Be careful of creeping determinism.

Agile Apple – Apple Inc. & Enterprise Agility

There are a lot of people who talk a lot about enterprise agile or agile “at scale”. They even put together very big graphics to show us how to do it. Unfortunately, they seem to miss the point. Individuals and interactions OVER processes and tools To understand what enterprise agility means, let’s look at Apple. How To Not See Enterprise Agility People have written about Apple as agile before, and some people challenged those arguments. At the end of the day, they both miss the point. Apple does not demonstrate enterprise agility by having Steve Jobs serve as an enterprise “product owner”. Nor is Apple not agile because it uses Direct Responsible Individual (DRI) over team ownership. You won’t find enterprise agility by applying scrum roles to a company. Nor does a company fail to be agile because it uses management techniques that you (or agile evangelists) don’t like. Enterprise Iterations & Client Value What does small scale agility look like? With each sprint, you deliver as much value to your client as possible. What does enterprise agility look like? With each product cycle, you try to deliver as much value to the entire client base as possible. To consider this with Apple, let’s start in the early 2000s. MP3s we’re all the rage, but burning CDs was a chore, most portable players could only hold a handful of songs, the software for these devices was terrible. Apple introduced the iPod with a 1,000 song capacity and a good app for managing the device. Consumers were growing dissatisfied with how music was purchased; buying a full CDs that had just a pair of good songs. Apple gave consumers a buying experience closer to their preference, with the iTunes music store. Consumers lamented having a phone, a camera, and an iPod. Apple introduced the iPhone as the convergence of these devices. People wanted more flexibility with the phone, and the App Store was created. People wanted to be able to more seamlessly sync their many devices. Apple created iCloud. In case it isn’t clear yet, Apple consistently addresses the biggest opportunity within it’s customer base every few years. It strives to solve real problems that real people have and they will pay to see go away. By generating real value for clients, Apple generates a lot of real revenue for itself. 1(ish). Our highest priority is to satisfy the customer through early and continuous delivery of valuable software products and services. Enterprise Does Not Mean Perfect Nor New Was iTunes the best music player? No. Was the original iPod the best device? Maybe, but it was a Mac only peripheral. iTunes wasn’t the first online music store. Others were selling $0.99 songs and $9.99 albums years before the iPod debuted and almost 5 years before the music store. The iPhone wasn’t the first touch screen smart phone. Phones had apps long before the App Store. Was iCloud the most advanced cloud technology? No. It’s second tier (at best) compared to Amazon and others. To most consumers, these things don’t matter. It’s only the value delivered by Apple that matters. 7(ish). Working software products and services are the primary measure of progress. Enterprise Starts with Just Enough There are entertaining stories about how the iPhone’s screen was changed from plastic to glass a month before the launch. Needless to say, this was quite disruptive. Steve Jobs’ demo in the public debut followed a “golden path” using exact text inputs, no full audio clips, and other specific actions because any deviation could cause a software crash. The software team was so nervous that they got drunk during the keynote. With the thrashing and just getting by, you’d wonder how the phone was ever finished, or how it ever worked. But it did. Subsequent generations were far better, but the first was good enough. Responding to change over following a plan 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Focus What Apple does better than almost any other company, is focus. No matter how big Apple gets, it knows it has finite pool of human talent and creativity. To get the most out of it, Apple decides what it is not going to do. Steve Jobs was famous for taking his top people on a retreat, having them fight amongst themselves to create Apple’s top 10 priorities. He would then cross out the bottom seven and declare that they will only work on the top 3. This often means killing products that don’t support Apple’s future. iTools gave way to .Mac, which gave way to MobileMe which gave way to iCloud. iPhoto and aperture gave way to Photos. iLife is just gone. There are no Mac servers. With each generation, the previous was killed off, even if the new product does not offer feature parity. Products are killed off, even if they have loyal users. The iPad had been in development for years, but were paused for the iPhone. Once the time was right, development resumed on the iPad. Priorities change and when they do, Apple changes how it invests it’s human talent. The goal of R&D at Apple isn’t to make money from each investment, but to find the right opportunities in which to invest. Despite researching many, Apple only releases a few. This gives the whole company the focus needed to keep thousands of people aligned on a singular purpose. 10. Simplicity–the art of maximizing the amount of work not done–is essential. Based on This, It Sounds Like All Successful Companies “Agile”… In a sense, yes. They likely became successful by working with clients to solve some need and were delivering something of value. Blackberry, for instance fits this mold. Mostly, no. One successful product can make you a lot of money. It doesn’t make you agile. Blackberry for instance, has failed to find a new need to solve since the debut of the iPhone. The question is less about success, and more about sustained success via consecutive successful iterations. It isn’t about a product or an industry. It’s about building your base then following it. Find the problems they have. Find the problems they don’t know they have. Identify the biggest one you can do the most to fix, and execute. If you do this via a platform rather than a series of ad hoc solutions, you’ll become very sticky as well. Fortunately, as long as you keep up with the growing need, most people will gladly stay with you. It’s also not about trying to solve every problem for your customers. Apple does well because it only solves a few things a year. Samsung does well for itself, but it pales in comparison to Apple. Samsung must divide it’s talents across microprocessors, phones, refrigerators, TVs, microwaves, and a whole lot more. It’s also not about helping every human. Apple gladly loses customers with each major change (like dropping iLife). But for each client lost, more are added, and the added focus helps Apple serve those whom stay even better. HP by contrast does a lot of contract IT work for many clients. This gives HP breadth of customers, but this also diffuses their talent and makes it harder to do big things since they’re busy doing lots of small things. Conclusion Enterprise agility is fundamentally different than team agility. Having lots of agile teams do not constitute an agile enterprise. In fact, per HP, that can be counter productive. Nor does using SAFe and having a big agile process does not grant you enterprise agility. It gives you a process to follow. You get enterprise agility by following Apple’s lead. By solving major client problems with every cycle. Do this consistently over many cycles. Apply focus to get rid of low value problems or solutions from yesteryears that no longer solve problems for the majority of your clients. Is Apple perfect? No. Neither are it’s products. However, Apple is focused on delivering value to consumers through the regular delivery of new products or services that solve actual problems people face. These products aren’t perfect but with greater adoption comes greater refinement. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Apple exemplifies what it means to have enterprise agility. Apple may not follow any agile rules, but perhaps that’s not what it takes to be agile.

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.

Agile, You’re Doing it Wrong

There’s an interesting problem that can appear in companies that develop their own agile IT capabilities. Ceremonies get added, scrum masters are appointed, deliveries ramp up, and all is looking good. Then a team is formed to tackle some novel problem or implement some new industry buzz word. I think that having an SDLC will help us. Let’s get some people on that. Big data changes all of this. We need cloud in order to stay relevant. We need more ALM in order to get ahead. The team goes to conferences, hires consultants, buys books, reads blogs, brings in vendors, and sequesters itself in a room for weeks to design a perfect solution based on all this information. The result is usually a multi-year timeline with no real detail on what problem is getting solved. Worse, it seems to require everything to be in place for anything to work. The team may have sprints, and scrum ceremonies and is thought of as being agile because of these characteristics. However, the team is missing the point of agile (and lean for that matter). Teams fall into these traps with good intentions, but they are traps. Proving the Need One of the reasons teams often create these models and roadmaps is to prove how much work there is for them to do. Armed with that information, they feel that leaders will come to their senses as soon as they see the weight of it and triple the size of the team. That never happens. Any other team competing for internal investments can create an equally long roadmap. It’s useless. It delivers no value. Showing leaders a multi-year timeline and saying that the reason you’re not getting things done is because there is too much to do is not a winning strategy. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. A much better way to invest your time is figuring out how you serve your clients this week or this sprint. Look at the capacity you have and use it as best you can. Change the nature of the problem or how you attack it if you need to. What problems are going to be solved? How do these add up with other work being done to turn into big wins? 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Once you’ve established your ability to deliver client value, you’re in a much better position to have a talk with leaders about more team members. But, now you can point to how much you have done, how you’re doing it, and talk about how much more you could do in the coming weeks if you had more team members. You’ve proven you can keep yourselves on track, that you can deliver value, and that you are motivated to deliver what the clients find valuable (not what you or a consultant finds valuable). Leaders are much more likely to invest into that kind of team than to invest into any sort of multi-year roadmap whose team is not yet delivering. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Increasing Knowledge Sometimes teams focus on creating a utopian version of thie tech or process. They create models, diagrams, and describe what it should look like (to them and the consultants and bloggers and books), often with little regard to the actual process being changed, the people in that process, the problems those people have, the skills of those people, or existing solutions (many of which may not be technical). Once they have this utipian vision, the team becomes confident in how much they now know. Looking at this, the team may imagine that if they just had more people they could do it all so quickly. Unfortunately, they don’t understand any of it. Worse, the people that will use the solution know and understand even less. The only way to actually gain organizational understanding, is by doing. No amount of blogs can increase understanding (sorry). Vendors will gladly lineup to sell you tools, but those tools may be looking for a problem in your company rather than solving one. No conference can confer understanding. Nor can consultants. These are all great venues to gain some quick knowledge and direction, but the only way you can truly understand what it means for your organization is to apply it. Your culture is different. Your current process is different. Your technology is different. The skills of your people are different. The only way you learn these things is by working in that world and gaining understanding for how to solve real problems in your context. This type of understanding comes slowly. If you want a real solution, though, you must have the disciple to take the time to understand the situation as it is. You must be willing to go slow to go fast. 11. The best architectures, requirements, and designs emerge from self-organizing teams. You cannot gain understanding in in an off-site with just the team, and not by creating a utopian vision. Take what you have learned externally, sit down with your internal clients, and figure out what you will do together in the next week or sprint to apply it. 7. Working software is the primary measure of progress. Once you’ve done that, you’ll understand far more in a week than you would have in a year of modeling a perfect process. Continue this sprint after sprint and before long, your team and clients will understand exponentially more of the opportunities and solutions. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Even better, since you’re working to solve actual problems you won’t waste time creating solutions to problems that don’t exist. That is something you can not find in a war room, at a conference, or in talking to a consultant or a vendor. The only way to figure out what you don’t need, is to start doing and learn what’s there that works. 10. Simplicity–the art of maximizing the amount of work not done–is essential. Lean – Kaizen & PDCA In a lean improvement, we may get huge changes, but not all at once. It’s the countless kaizen events that each make a small tweak that will accumulate into that big change. Each of these changes are made of many smaller PDCA (plan, do, check, adjust) cycles. These cycles apply some external knowing to an existing problem, but with some testable assertion. I think that using big data could get us that answer. I think that a more formal SDLC will help us identify where we are short cutting out processes. If these experiments are in (or near) the real environment and include the people actually doing the work, you’ll have a better check and know what to adjust for the next cycle. Lean – Genchi Genbutsu If you’re working with the people doing the work, where they do it, then you’re getting into the lean principle of genchi genbutsu, which essentially means going and seeing the actual situation. This would be instead of a summary, second hand knowledge, or just guessing. In our case above, involving the people doing the current jobs that will be impacted by the new process is at least a start at genchi genbutsu. By engaging them, you can learn (or see) exactly what they do, how, why, and when. This gives you a much better idea for how what you’ve learned externally will fit in this context and serve to help or hinder this person. Leanish – Yokoten About those sources, there’s something we should say. Often people like to gravitate to experts and their “best practices” as they way things should be done. Why would we do it any differently? Those practices are the “best” way to do it. Life is not so simple as to let us say that there is a single “best” way to do anything. That’s especially true when we’re talking about novel opportunities in a large complex environment. Although not necessarily a “lean” idea, Toyota offers some wisdom about how to handle these scenarios. When they find a new way of doing things, they do not engage in standardizing people on the “best practice”. Rather, they engage in yokoten, which can be translated as “across everywhere”. The idea is not to tell everyone that this is the way to do it, but to say that this is a way it can be done. Exposing people to the idea will give them a chance to see if it will help in their context. It may. It may not. It may also inspire someone to try something else entirely, which may itself become a subject of later yokoten. This engages people in acquiring knowledge from external sources but requiring them to think critically about the solution and their current situation to see if there’s a way to improve the standards. Using Human Creativity Intel is a company that made the transition from forcing “best practices” to a model of exposing people to new ideas and tapping into human creativity to apply these ideas appropriately in each context. This can be seen in the shift of their internal language from “copy exactly” to “copy intelligently”. Fortunately for those of us in software, agile methods provide a way to copy intelligently. We work closely with all stakeholders, we deliver frequently, and we are always adjusting to make sure we’re delivering the most valuable solutions possible this week. Knowing what we want to achieve In a year or two is nice. It’s critical to understand why and to know what we’re delivering this sprint.

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?

Optimum Busyness

Recently, I’ve said a lot of bad things about “busyness”. I stand behind all of them, but that does not mean that the way to be agile and lean is to do nothing. It is not true that just because you’re doing something that you’re delivering value. It is also true that you must do something in order to deliver value. Today we’ll look at some research on relating hours worked per week to long term productivity. Why does this matter? Working in software can be a rather terrible experience. It can also be fantastically rewarding when your hard work and long hours make life better for (potentially) billions of people. The trouble is that there’s too much of the former in the world. There’s more legacy code than not. There are more deadlines than vacations. And no one ever seems to understand why things take so long or that by asking for feature “X” there will be an impact on the timeline for feature “Y”. The result is a very short developer half life. From graduation until the age of 40, here is a continuous flow of people leaving the profession. For an organization, this is terrible. Just as people become masters of their craft with all that time and energy having been invested into their development in that arena, they leave it. There may be some elements such as people becoming managers at play here, but most engineers don’t become managers. As an industry, there is a brain drain that occurs. It simply hasn’t been an issue yet, because the new graduates are plentiful enough to fill the need. But we shouldn’t be satisfied with that. Why does this matter? It takes years to develop skill mastery, and by 40, most engineers are likely at that skill level. These people could be tremendous assets to to building truly world class software. Maybe you also care about your own work-life balance, quality of your work, and if you’re a leader then these attributes for your team members. If that’s not enough, consider an agile principle that reinforces the need: 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. U-Shaped Curves This may be the most obvious element of this article to anyone in software. That having been said, it’s also the most frequently violated (even by those who intuitively know that it’s true). The idea is that when we consider hours worked and productivity, there will be a range starting from zero where for each extra hour worked, I’m positively increasing my productivity. While in the next range, as I increase the number of hours worked, my actual productivity doesn’t really change. It’s neither increasing nor decreasing. In the final range, for each extra hour worked, my productivity actually decreases. Continued long enough, and each additional hour worked may actually be undoing the preceding hours’ gains. Loosely, this could be pictured as an upside down “U”. As a concept, it actually applies in our world in many scenarios. Often we fail to understand that the outcome we’re manipulating lies on one of these curves. For a period of time, the changes we make get us the result we want (working a few more hours to get stuff done, reducing class sizes by a few students to increase learning). However, there reaches a point when changing that variable stops helping. Worse, if taken too far it can actually be a negative. If I work 120 hours per week, my output is likely of poor quality and will require much rework. If we have only 5 kids per classroom, the ability for the kids to sustain a productive dialogue or have sufficient skill diversity may actually impede learning. For a great book that delves deep into this idea, pick up Malcolm Gladwell’s David & Goliath. We know enough of the idea here to continue, but there’s much more to be said for understanding this idea more thoroughly. Points of Inflection If we take the lesson of the “U” curve to heart, then there are two points we need to identify. The first is at what point working more hours actually causes productivity to decrease. The second, is the point at which productivity appears to have reached it’s peak. Anywhere between these values, is likely a good place to find optimal productivity. One important consideration is that we’re concerned about these values sustained over a long period of time. Returning to our agile roots, this is the pace that everyone should be able to sustain for their career. Maximum Sustainable Pace As Henry Ford was getting started, the vast majority of Americans were working 12 to 14 hour days. There had already been people lobbying for 8 to 10 hour workdays for over a century, but this wasn’t the norm. Regardless of the motivation, Henry Ford instituted an 8 hour day for all factory and office workers. This was a decrease from 9 hours per day. Despite the reduction in hours, there was a significant boost in productivity. Over the next two years, his profit margins doubled. What does this tell us? 9 hours per day is beyond the peak of the U-curve. 8 may not be optimal, but it yields better sustained results than 9. Many countries have found a similar upper limit and passed laws that impose penalties on companies with employees exceeding 35 hours per week or outright bans on working more than 48 hours. What does this mean? As a general rule, you probably shouldn’t be working more than 40 hours per week. Over the long term, it’ll contribute to burn out and it’s actually reducing, not improving your productivity. Minimum Sustainable Pace As noted earlier, some countries consider full time work to be in the range of mid-thirty hours per week. They’re not alone in finding that to be optimal. Moreover, those researchers found that the 35 hour week was best for mistake prevention, a costly element of software delivery. Rather than beat this to death, let’s assume that the ideal value may vary a bit from person to person but that it is likely in the range between 35 to 40 hours per week. Keep in mind, this is not the minimum. This is the net hours. If you plan for 40 but have a night or two you stay late per week, then you’re likely exceeding your sustainable pace. If you shoot for the middle of the range, that gives you some slush room on both sides while still maintaining a sustainable level of peak productivity. What Is a “Working Hour” Does this include lunch? If I take a brain break for an hour, is that work or not? What if I’m still in the building? I don’t know. I’d encourage you to just keep this limit in mind and evaluate how you feel over time. At the least, you should have a sense if you’re notably over or under. If you’re close enough that you’re counting the minutes you spend walking to Starbucks everyday, you’re probably fine. Alternative Schedule Some of that research made a point of saying that the way we distribute the hours doesn’t impact what the total is. Whether it’s fewer hours over more days or more hours over fewer days didn’t seem to matter. That supports a different argument to help people sustain a better work-life balance, to get away and to return with a fresh perspective. That is to shift to a 4 day work week. This offers a 20% reduction in days worked and a 50% increase in days off. It also makes it easier to work what is regarded as a full day while respecting the ideal limit of hours. Likewise, it removes some opportunities for people to over extend themselves and ultimately deplete value from the team by staying late. There are some cautions to go with this idea. One is that for it to work, everyone must be on the same 4 day schedule. Otherwise, a fear of missing key talks or being omitted from decision making may cause people to forgo their extra day off, or at least not use it well. With that in mind, there are many scenarios where teams must provide support during all traditional business hours and that may make it impossible to have such a schedule and avoid that pitfall. Regardless of how long a weekend may be, use it. Not taking the time off to refresh yourself will do more harm in the long term than good in the short term. How can I keep up by doing less? There are two sides to this. The first, is to be very purposeful with the time you do invest into work. Prioritize and be prepared. If you need help figuring out how to prioritize your opportunities, refer here. The second is the cruel irony of this whole thing. Your overall productivity can actually go up by working less (especially if you’re at an extremely high number of sustained hours). It may not feel that way, but your mind may be lying to you. Remember, being busy is not synonymous with value delivery or productivity. What is the right balance? There may not be a one-size fits all answer, but perhaps some of the ideas we’ve discussed may provide some guidance. Just remember that feeling as though you’re getting a lot done doesn’t mean that you are. Our goal shouldn’t be a great day, week, or month, but a great career within an even better life. Our goal is a pace that is sustainable by all contributors for their entire career. It may feel as though you’re losing a great deal of productive time, but remember that each shortcut has a cost. Sometimes it’s defects. Sometimes it’s rework. Sometimes it’s high blood pressure at 40. Sometimes it’s a heart attack at 50. Sometimes it’s being disabled at 60. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Trust is more than just acknowledging that the tech folk know software engineering and can choose a framework better than their manager. It means trusting that being away from the project is sometimes the best way to contribute, that they’re growing professionally, and that you will want to use their ever-growing expertise for future projects. For that, though, the engineers must still be alive, they must still work in software, and they must still work here. Don’t be afraid to go slow to go fast. Challenge How often do you work over the weekend? How much of your vacation time do you not use? How often do you answer e-mails late into the evening? Can you sustain what you’re doing forever, or do you keep thinking that you’re just one or two milestones from finding a better balance?