Category: Agile

Jidoka and Captured Knowledge

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

Jidoka (automation with a human touch)

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

Muri, Kaizen & Retros

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

Takt Time & Waste Elimination

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

Takt Time & Sprints

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

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.