Search Results

There are multiple Agile scaling frameworks out there. However, it is clear who is dominating the market and despite its notable detractors in the Agile community there are many adopting the Scaled Agile Framework ( SAFe). In our complex world that is moving faster and faster the attraction of structure and predictability is understandable. However viewing SAFe as a process to be adhered to can lead to unintended consequences. Here we present some of the common pitfalls along with suggestions to help you stay safely out of trouble. Force Fitting Teams Into Trains SAFe is intended for the development of large systems. Most IT organizations have large portfolios of small applications rather than large systems. Rather than co-dependent teams collaborating to develop and evolve one large system a team might have multiple applications they are responsible for. It can be valuable to have a common cadence and create a sense of common purpose. However forcing teams that are largely independent into a train can cause unnecessary overhead and waste. Unnecessary Solution Trains Adding an extra layer creates complexity, overhead and impedes the ability to respond quickly. The guidance for Agile Release Trains is that they consist of 50-125 individuals. Beyond that, the guidance is to have multiple trains organized into a Solution Train. Unless you are building a very large system then you should not be implementing the Solution Layer. Scaling Too Early Many make the mistake of scaling before they have established a good flow at the team level. Before introducing PI Planning ensure teams have a good rhythm of making and meeting commitments at the team level. Over Preparing for PI Planning PI Planning is a time for everyone to come together and establish a shared understanding of the upcoming objectives. However, in the anxiety to have the event go smoothly, many over prepare for PI Planning and expect commitments around prior decisions. PI Planning is not the blessing of a plan, it is planning and you should expect: learning to occur, constructive conflict to flourish and course corrections to be made. Too Many Features Once features become too numerous, all clarity is lost, planning becomes lengthy and tedious and many of the problems we experienced with the waterfall approach start to reemerge. Strategy is about communication. Make sure your features are meaningful to your customer and if your roadmap can't fit on one slide without using a tiny little font then you probably have too many features. Not Creating Real Objectives Customers don’t want stories, they want their problems solved. Clearly articulated objectives help provide clear line of sight to the real business needs and empower teams to better deliver value. Aim for objectives that are significant, concrete, action oriented and inspirational. Staffing Every Role SAFe covers a great deal of possibilities for agility at scale and so its guidance is broad and generic. Your scope will be narrower. Staffing all the roles in SAFe will lead to a lot of unnecessary overhead. Think of SAFe’s roles as a checklist of responsibilities to be met. Do we need a release train engineer if there are three teams in a train? Maybe not. It is quite possible that the responsibility can be met by one of the Scrum Masters. Does each team need a dedicated Product Owner, not necessarily but all the responsibilities need to be addressed. Not Broadening Your Horizons SAFe is not the fountain of all Agile knowledge. It is a knowledge base of proven practices for agility at scale. Much of the content in SAFe is derived from other work and modified by Scaled Agile. To get a deeper understanding of much of SAFe’s content, to stay abreast of new developments and ultimately transcend SAFe, go to the original source for your knowledge and training. Over Valuing Training and Certification It takes many months or even years to become comfortable with a new way of working. Do not mistake knowledge for understanding and proficiency. Although just-in-time training is valuable for level setting and accelerating knowledge acquisition, it cannot replace experience. One cannot become an expert in agility at scale by attending a mere 2 day Leading SAFe class. Conclusion Scaled Agile has always emphasized that SAFe is a framework that must be tailored to your organizational context. However, either the pull of the past is too strong or the impedance of tailoring is too much for many. Regardless, we must find a way to overcome these challenges as adopting SAFe myopically impedes true agility and places each Agile transformation in jeopardy.

Traditionally, Agile organizations struggle with value. The right ingredients exist but we never seem to bake a very good cake. PI Objectives are ignored. Sprint objectives are rarely established or adhered to. We use a user story template that guides us towards addressing the who, the what and why but it is rare to see a story that articulates more than the what. Defining value is subjective and requires guessing about the future. Nobody has a crystal ball, right? Paradoxically there is an insatiable appetite for forecasting effort and tracking the rate of effort spent. Why can't we apply that mindset to value? When did you ever see a value velocity? Why is it we struggle so much with defining and tracking value? Not everybody does. When I joined Rally in 2008 I experienced agility woven into the very fabric of a company. Rally appreciated the value of a shared understanding of value. Influenced by the work of Pascal Dennis, Rally would formulate a True North statement every year to guide all in the organization. Their True North comprised both a broad-brush goal and hard measures. The broad-brush goal or hoshin as Toyota calls it, speaks to the heart, the hard measures speak to the head. The True North was decomposed into mother strategies and later baby strategies as strategic planning descended down through the organization. Like its namesake, the True North was ever present throughout and constantly used to help make decisions. The name I associate with this approach is Hoshin Kanri which loosely translates to Strategy Deployment. Those practicing Hoshin Kanri reflect their strategic decisions on an A3 Strategy or X-Matrix. Strategy is about story-telling so using a single piece of paper is a useful forcing to ensure brevity of communication. OKR stands for objectives and key results. Nothing that mystical once you understand the acronym. John Doerr introduced Google to OKRs in 1999 after two decades of living and breathing OKRs at Intel. OKRs have become very popular in recent years. Due in part to the success of Doerr’s book Measure What Matters. An objective is simply what is achieved, no more and no less. Objectives are significant, concrete, action oriented, and (ideally) inspirational. When properly designed and deployed, they’re a vaccine against fuzzy thinking – and fuzzy execution. Key Results benchmark and monitor how we get to the objective. Effective KRs are specific and time-bound, aggressive yet realistic. Most of all they are measurable and verifiable. As True North is decomposed, so too are OKRs. Key Results becoming objectives at a lower level although Doerr is quick to point out the dangers of doing this too rigidly and cautions against strict cascading. The best approach for you is really the one that sticks and OKRs really seem to have built a lot of momentum. Regardless of your chosen approach, at some stage you need to map objectives to backlog items. You might already appreciate that objectives and backlog items are not quite the same. An objective is a destination, a backlog item is an activity you complete to get there. Agile tools do not map perfectly and we’re seeing a lot of OKR products flood the market. However, I can’t envisage any organization being successful managing both an objective hierarchy and a backlog hierarchy. I think you need to choose one hierarchy and compromise. For me, that compromise is mapping your lowest level yearly objectives to epics in your backlog hierarchy. The key results for those epics may or may not map to features. Lastly my favorite story about tracking value delivery. In 2010 I went to visit Menlo Innovations. CEO Rich Sheridan tells their story in Joy, Inc: How We Built a Workplace People Love. I asked Rich how Menlo defines and tracks value. “That’s easy Ken. We have a demo every Wednesday. If the customer doesn’t show up, work stops. The customer has never failed to show up”.

In March 2020, my cheese moved. I had to quickly adjust from interacting face-to-face to spending my whole day looking at a screen. I started suffering from eye-strain. My 13” Macbook Air was great for traveling but lousy for looking at all day with my 50+ year old eyes. My first priorities were a larger a screen and better eye-glasses. Monitor My coaching friends in FiveWhyz have 34” curved monitors but I settled on a 4K 27” LG monitor with a USB-C connection. I don’t know if I made the right choice, but the picture is super sharp and the USB-C hub at the back of the monitor to helps reduce desk clutter. Blue Glasses I use progressive glasses for reading and driving but they just don’t work for a computer screen. I tried reading glasses, but my 1.25 prescription was too strong. After experimenting, I found stepping down to 0.50 as ideal. The science says it should not matter but Brian Warden swears by his blue light filtering glasses and I found a pair I liked at EyeBuyDirect. Laptop Stand, Keyboard & Trackpad I kept the lid up on my Macbook so I could use it as a secondary screen and because I needed a keyboard and trackpad. However, not having the keyboard aligned with the monitor meant I had to twist sideways to type. Not only did my back hurt but I also noticed an increase in typos. I experimented with external keyboards and mice but ended up buying a Magic keyboard and trackpad. I purchased a BoYata stand for my Macbook so that my laptop screen was at the same height as the monitor. Webcam With a more comfortable setup I started noticing on video calls that my image was grainy, and the lighting was poor. I’m not too picky about my appearance but you can’t look like a confidential informant. Of course, Macbook cameras are notoriously bad. Apple puts much better technology in the iPhone so I tried that as a camera. I installed a special app on my phone called EpocCam and got a tripod to mount my phone. It worked fairly well but the big downside is that your phone is less easily available when you need it. I finally landed on a Logitech 920s which many reviewers rate as the best camera at a reasonable price; I think it works well. With Zoom’s adjust for low light capability and the better camera, I didn’t need the ring light that I had experimented with previously. Microphone I started noticing others had far superior mics. Tom Perry and Hans Samios sound great and they swear by the Blue Yeti microphone. They were hard to find but I got one at a reasonable price at BestBuy. It is an exceptional product but it picks up every noise and vibration from your desk. Reluctantly I bought a boom and shock mount. At the time I thought it was an extravagance but, it is really useful to have the microphone off the desk and out of the way. Headphones For the most part, I use the monitor speakers to listen but sometimes you need to use the headphones. Wired headphones are very restrictive, you can't move leave your office and my pets always seem to be on the wrong side of every door. I got a pair of AKG Bluetooth headphones that I really like. Moving to Windows In January 2021 I started a new role and was presented with a Thinkpad to connect to the office network. There are some obvious downsides to more hardware but I don't miss Citrix. The Thinkpad has a USB-C connection so was able to quickly and easily to connect to my 27” monitor. I got a second Boyata stand. The Magic keyboard and trackpad don’t work that well with Windows besides disconnecting and pairing the Bluetooth between the Macbook and the Thinkpad was unreliable and slow. The Microsoft designer compact keyboard was a very able replacement and I soon realized how much I had missed having both a backspace and a delete key. Replacing the trackpad was not so easy but I really like the hybrid functionality of the Microsoft Arc Mouse that works well as a mouse and a trackpad. What's Next A sit/stand desk might be nice, but I bought a really nice mission style cherry desk some years back that I love so will not be parting with that. My existing office chair that I bought a few years seems to work just fine. The only thing I'd like to have but don't is a KVM switch so that I can switch back and forward easily between the Macbook and the Thinkpad. My inventory Here is the inventory of everything I acquired over the last year including some small yet really useful items I didn't mention above. LG 27UK850-W 27" 4K Monitor with USB Type-C Connectivity $449.99 Apple Magic Keyboard $99.00 Apple Magic Trackpad 2 $129.00 Boyata Laptop Stand (Silver) $35.99 Ergonomic Wrist Rest for Magic Trackpad (Black) $16.99 Blue Microphones - Yeti - USB Microphone $129.99 Blue Microphone Stand $99.99 Noise Repelling Shockmount System for Blue Yeti $25.47 Mount-It! Power Strip Holder Clamp Desk Mount with Included Surge Protector $26.99 Logitech - C920S HD Webcam $94.99 AKG Noise Cancelling Headphones N60NC $116 Headphone Hook Holder Hanger Mount $14.99 5’ Silicone Brown Cord Protector $17.91 6 Feet 360° Rotating Flat Plug Extension Cord/Wire $14.49 Boyata Laptop Stand (black) $49.99 Microsoft Designer Compact Keyboard - Matte Black $54.99 Microsoft Arc Mouse (ELG-00001) Black $48.26

One of my formative childhood memories happened in second grade. I was working next to another student on a blackboard and our teacher assigned us the same math division problem. I used long division and my peer used some form of magic to arrive at the same correct answer in half the time. I later came to know this witchcraft as short division. While we arrived at the same answer, my approach was longer and far less elegant as it took more time and writing. This experience helped me realize there was more than one way to solve problems, even in systems as structured and logical as arithmetic. Like many engineers, scientists, and entrepreneurs, I have a fascination with problem solving -- perhaps even a fixation at times. One heuristic I like to keep in mind whenever I encounter a new (to me) problem or opportunity is to remind myself that someone else has likely already encountered this kind of problem or situation. Someone may have a countermeasure or at least something to say about it. While we are “not yet” able to immediately download the skills and knowledge needed to fly a B212 helicopter, learning via the internet is easier than ever before. One good practice is to look at how people in other fields have solved the same or similar problems. But rather than taking time to explore possible approaches from related fields, some coaches and scrum masters with a shallow portfolio of heuristics tend to rely too much on either popular “best-known” methods or iteration to solve problems. While there is a place for trail-and-error, inspect-and-adapt takes time and effort. What if there were shortcuts or more effective approaches for your situation if you only knew they existed -- like short division? I attended a course on scaling Agile several years ago and after about a day into the Lean section, the instructor introduced a one-page problem solving template that the consultancy had created. As an experienced Lean practitioner, this was quite interesting. It was a different way to visualize solving problems on a single page than I had seen before. I asked, “Why did you choose to develop and recommend this approach to problem solving versus using an A3 and A3 problem solving?” The instructor replied, “What is an A3?” Needless to say, I was shocked by the response. If you are unfamiliar with how Lean practitioners collaboratively solve problems, I'd recommend Managing to Learn by John Shook. (1) It takes discipline to not jump into problem solving and reinvent the wheel. It takes effort to explore how others may have addressed for this kind of situation before. When I research the state-of-the-art in fields with similar problems, I ask myself what underlying principles, heuristics, and practices do practitioners rely on? How might I borrow their approach for my own problem and situation? What are the underlying principles for how their approach works and how should it be tailored for my situation and context? In biology, repurposing or coopting a function for a new use is known as exaptation. The world of technology is full of examples of radical repurposing technology designed for one use case to another completely different application. For example, the re-purposing of a radar magneto for a microwave oven and repurposing a microwave oven to smelt metal at home. One area where I have been exploring related fields lately is human psychology -- conflict resolution more specifically. Like many coaches, I have experienced and participated in several conflicts that erupt over the course of challenging the cultural status quo and radically changing ways of working. Here are a few examples, Agile vs waterfall development, Lean vs Agile, Scrum vs Kanban, project management vs product management, and estimation vs #noestimates. Helping clients resolve unhealthy conflict is a core skill for coaches -- note that some kinds of conflict are healthy and beneficial. What can I adopt and adapt from how psychologists, professional conflict mediators, and peacemakers resolve conflict? A great post that exemplifies the practice of exaptation and repurposing the approaches used by conflict experts in other domains is Complicating the Narratives by Amanda Ripley. Ripley makes a compelling case that journalists can improve their ability to moderate dialogue between conflicting factions by adopting techniques from professional conflict negotiators and peacemakers. Lean and Agile coaches can use these techniques as well. If you ever need to broker a peace deal or mediate a compromise, take some time to learn from others and not re-invent the wheel. Explore what professionals in other domains have learned about the nature of conflict how to nudge tense situations toward a better place. Here is my riff on a list of questions inspired by the article for fellow travelers to consider. 20 QUESTIONS TO HELP UNTANGLE CONFLICT AMPLIFY DIFFERENCES AND SEE THE WHOLE 1. What camps are forming or already exist on this issue? 2. What is dividing us on this issue? 3. What is oversimplified about this issue? 4. What are the larger or higher-level questions that should be discussed first? ASK QUESTIONS THAT EXPOSES TACIT ASSUMPTIONS AND MOTIVATIONS 5. Why is this important to you? 6. What information or experiences have shaped your thinking on this issue? 7. How did you come to arrive at your current position about this issue? 8. What is at stake for you? 9. How might things change for you if the other side had your same understanding? 10. What do you want the other side to understand? LISTEN AND EMPATHIZE 11. Where do you feel torn? 12. Is there any part of the [other side's position that makes sense to you? 13. How do you feel about this issue? 14. Where does that feeling, emotion, or thinking come from? 15. What are you saying that the other side is not listening to? AVOID PREMATURE CONVERGENCE AND COUNTER CONFIRMATION BIAS 16. What’s the question nobody’s asking? 17. What do you think the other group thinks of you? 18. What do you think the other group wants? 19. What do you want to understand about the other side? 20. Is there anything about how the other side portrays you or people with your views that feels inaccurate? Any suggestions or feedback is welcome. Reflection: What problem that am I struggling with today has likely already been solved or addressed by others? What related fields should I be exploring to improve my own capabilities? How would I know if I were in an echo chamber? Do I spend too much time in an environment where I only encounters beliefs or opinions that coincide with my own? References: 1) Shook, John. Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor and Lead. 2008.

One of the natural concerns people have when they embark on an Agile Transformation is that their productivity be dramatically reduced during the change. This is such a large concern that it often becomes the biggest reason not to transform. Interestingly, based on my experience, the reverse of this fear occurs. Most organizations see a significant improvement in their ability to deliver, so much so that they really don’t see a slow down. For a specific organization some Teams will see improvement, some will not, but on average there will be an overall improvement in value delivery in a very short period of time. Now don’t get me wrong, there is often a small dip in productivity, as a result of, for example, attending training or as people learn to apply their learning. But the reality is that the dip only lasts a couple of weeks. And any loss is made up very quickly, also in terms of weeks. It got me wondering why this is so. After all it seems logical that with such a significant disruption, there would be a significant impact in your ability to deliver. However, based on my direct observation the reality is quite the opposite. The biggest contributors to this are the immediate benefits we get from visualizing our work and limiting our work in progress. Firstly, Agile Teams start to manage work-in-progress (WIP). No matter what method of Agile you use they work to proactively to limit work-in-progress. When organizations embark on Agile, their people are typically over-utilized. Many organizations pride themselves on high utilization rates. The irony is that high utilization typically means things take longer to do (i.e. cycle time increases) and the effect is not linear. Take a look at the graph below: Source: What Is Wrong With 100% Utilization Thinking? What this says is “as we approach 100% utilization the time it takes to process something becomes exponentially large.” If you’ve ever wondered why, when you get past a traffic jam, there doesn’t seem to have been anything that caused it, then you have seen over-utilization in action - just that one or two extra cars was the cause. As teams limit their work-in-progress, they tend to first reduce their utilization rate, and over time find their utilization “sweet spot”. By moving away from 100% utilization individual jobs take significantly less time than they would if we were close to 100% utilization. The result? The well implemented Agile Transformation shows immediate improvements in value delivery. The second reason productivity is not lost is that Agile Teams visualize their work. Agile methods proactively work to understand and control what work comes to the Team. This means that work can be better planned and scheduled. Prior to the Agile Transformation work typically comes to people from multiple directions without any real context. To the person who does the work, all work looks like an interruption. As Teams get control of their intake system they find that more work is planable than they thought. For example, in one shop I worked in, work arrived in the form of tickets. For these people there was a natural feeling that nothing was planable. As the Team got control of their work intake system, they discovered that in fact 65% of the work was planable. This allowed the Team to plan out how to get things done, to reduce context switching, to figure out how to help each other out when there were problems, and so on. The result? The well implemented Agile Transformation shows immediate improvements in value delivery. Beyond controlling work-in-progress and improving the ability to plan and Agile Transformation will have other practices that help improve the ability to deliver value. But both these forces are very powerful and increase a Team’s ability to deliver almost immediately. Of all the things you will worry about during an Agile Transformation, perhaps counterintuitively the one area you probably don’t need to worry about is how much of a downturn in value delivered you will experience. This myth should not be the reason that you do not embark on an Agile Transformation. And if you are seeing a significant reduction in productivity as you transform, then perhaps it’s time to dig a little deeper.

Agile emerged towards the end of the 20th century from a burning desire to better address the needs of software developers and their customers. Today, we see people adopting Agile practices across all walks of life. In his TED talk Bruce Feller even talks about how to do apply Agile to your family life. Here we present three Agile practices that transcend development. Practices you should be adopting right now regardless of your industry or team size. Create Transparency If you have customers or colleagues (and most of us do) there is tremendous benefit to being transparent. Transparent about: the work you have completed, the work you are doing and the work you plan to do. Very importantly is the work you are not going to do. Transparency is essential for building trust. With transparency we know that people are listening, we know that people are addressing our needs and we know the priorities that have been established even if we might not agree with them. With visibility into work we have the opportunity to spot the bottlenecks and optimize the flow of work. Transparency should be frictionless and always available as a natural byproduct of the collaboration tools we use. A huge benefit of making work visible through such information radiators is that we can dispense with the universally detested status report. But we shouldn't stop at visibility into work. We need to extend visibility into our thoughts, our fears and our dreams of the future. Implement Fast Feedback Loops If you are a wedding organizer you have the benefit of learning from the many other weddings that have occurred before. The problem space is fairly well known. When the problem space is novel or uncertain, we don’t know all the challenges up-front. One tendency is to spend more time analyzing the problem. Yet, research and experience shows us that we learn better and faster through experimentation. When we conduct small, safe-to-fail experiments we are better able to respond to discovered knowledge. Every sailor is very familiar with this approach likewise anyone who has driven a car. We need to know when we are off-course so knowing our desired outcome is key and we also need to measure our progress frequently as large course corrections are always wasteful. Limit Work in Progress We’re all familiar with what happens to the highway when there are too many cars. The flow of traffic slows down, sometimes stopping altogether. The same happens with our work. With too many things in progress, our output grinds to a halt; sometimes suddenly and catastrophically. Just like the highway, the best way to overcome this problem is by limiting the work in progress. We have to stop saying yes to every demand placed on us. If we try to keep everyone happy, we will keep nobody happy. We need strict prioritization where no two items have the same rank. This requires discipline and courage to have those difficult conversations and sometimes we need to say no. However, it is best to have these conversations proactively. Through this shift in focus away from starting and more towards finishing we can bring about a big improvement in the throughput of value.

Before I begin, I want to clearly state this is not another “death by PowerPoint” rant. There are plenty of those out there and I am not interested in joining that debate. My simple objective by writing this post is to try and help people collaborate better, have more effective meetings and stop wasting so much time creating and polishing presentations. I have had the privilege of working with some of the best organizations in the world, full of extremely talented people. Which is why it pains me so much to see the time and effort that goes into building these elaborate decks used to facilitate meetings. It kills me to see brilliant people where far too much of their working life revolves around creating, refining and presenting slide decks. Great people still achieve great results despite the waste, but imagine what they could do if they found a better way. If building a deck helped us collaborate better, perhaps the work would be worth the effort. But while presentations are a great way to demonstrate and share knowledge, PowerPoint is a lousy collaboration tool. Creating a deck is essentially building out a one-way communication. Sure, we often ask for feedback, but that feedback is often just how to improve the deck. Before we know it, the deck becomes the actual end instead of a means to an end. The worst part comes from the fact that most of these decks are used for a meeting or series of meetings and are sent to SharePoint to die. There are alternatives out there that could change the world. They do not replace PowerPoint as a presentation tool, but as a collaboration tool that has a chance of being long lived and adding value beyond a single meeting. Starting with the simplest collaboration tool, the whiteboard. There is real power in a blank slate and the pictures and diagrams we create together on a board. Of course, this is harder now during the crisis, but incredible tools have made doing this remotely not only possible, but maybe even better. Another tool that I use all the time is more of a simple one-page document that presents some possible objectives and builds out just enough context to support a conversation. I usually include some kind of a picture, diagram, flow chart or something similar. I leave space for the group to fill in the results of our collaboration. The final product is not only a good representation of the topic we needed to work on, but is useful documentation for others not present in the meeting or who subsequently need to quickly and easily absorb the key points. My very informal one-pager is an easy approach to try, and perhaps it could start a more fundamental culture shift to more Lean ways of thinking. One powerful method and philosophy is embodied in the A3, a foundational Lean practice. The A3 is a one-pager, but with some proven structure to help solve problems and manage knowledge while developing people. I highly encourage people to learn more about not just the structure, but also the philosophy behind this approach. A Google search will get you there, but this article is a great starting point. One final alternative was developed in response to Jeff Bezos banning the use of PowerPoint at Amazon. The alternative is based on a “narrative structure” where instead of a presentation; people create these 2-4 page memos and then read them together in a meeting before discussing. The part that is most compelling to me about this approach is the power of the story. People think in stories and are inherently able to understand and take and retain information from stories. It is the fundamental foundation of user stories and narrative-based approaches for sense-making, which are two other practices that are proven to help promote shared understanding and meaning-making. I am quite certain I have only scratched the surface here of all the alternatives. Hopefully, you feel compelled to add your own methods in the comments section. My overall hope is that we can all open up our minds to try something new and that is fit for purpose rather than continuing to follow the PowerPoint construct that is not helping us get better.

What are heuristics and more importantly, why should I care? Heuristics is a term my friend uses all the time and one I simply never understood. It felt to me like a word that no one understood and the simple term “rule of thumb” seemed completely sufficient. It took a global pandemic for me to finally get it. We are in the middle of a crisis that is proving to be one of the most complex problems of a generation. While most medical issues are complex, they typically have a scientific response that often solves the problem. These responses are reinforced through empirical data and continued effectiveness. There are no proven responses to the COVID-19 pandemic and therefore we have to look for the very best alternatives that have the potential to solve the problem, also based on previous experience. It is not that these potential solutions are sure bets by any stretch of the imagination. They may cause harm or one approach may directly conflict with another. We simply do not have time to put in the work to scientifically prove a solution is effective before we act. Whatever we do, that is at least based on something, is better than doing nothing at all. These actions are heuristics. We know from experience that social isolation has a likelihood of keeping people from passing on a contagious disease. It would certainly be preferable to have a 100% safe and effective vaccine so we didn’t have to really do anything to stop the spread, but this will take far too long if it is possible at all. The social distancing heuristic seems like a pretty good idea compared to doing nothing and in the absence of a sure bet. So finally understanding the term is one thing, but then I had to ask why do I care? I am not a Doctor or a Scientist by trade. I am an Agile Coach and Business Consultant working to help people perform to their full potential and deliver maximum value to their customers. But similar to the pandemic response, I have learned that there are really no absolute solutions in my business either. Most of the customers I work with are dealing with truly complex problems that I cannot solve based on memorizing a series of solutions and just matching them up with the problems that are presented. I need a set of solid heuristics that I can leverage to help me try some things and see what works. I start to get in trouble if I start thinking my heuristics will always work or if I start to apply too much precision where there is no such precision. The bottom line for me is I am actually pretty glad to have a word to describe this much larger definition of what I do for a living. Any given heuristic-based approach my customer and I use, may or may not help teams improve. If we go in to the exercise of trying things with this understanding, we set the right expectation and if we need to pivot, everyone is prepared to do so. If we think in absolutes, we may master the approach without really seeing the benefits. The result could be that we do agile practices well, but are we any better for it?

In many IT organizations that I have worked with, there is a focus on controlling and reducing costs. This makes sense as most IT organizations are regarded as cost centers, and so it is thought, a focus on reducing costs should result in improved business outcomes for all concerned. This thinking leads to a focus on efficiency, utilization rates and so on with the theory that if we can get more out of a resource (for example, a person), then we will be better off. For those with this focus, what actually happens as they implement Agile is a disappointment. Usually there is no visible reduction in cost and no visible improvement in efficiency. Worse, as we implement agile it looks like things such as utilization rates will decrease as we staff roles such as Product Owners, Scrum Masters, and so on. Agile is focused on predictably delivering the most value given the known capacity. Some of this comes from a base misunderstanding of what Agile is about. Agile is not about using our resources more efficiently, although it will usually result in this. It is not cost focussed. Agile is focused on predictably delivering the most value, as defined by our customers (to the business), given the known capacity. Agile delivers more value because: It helps teams know what the most valuable thing they could work on right now It focuses on flow efficiency, not resource efficiency, which reduces handoffs, context switching, and wasted additional work. This is a result of aligning our work execution directly with customer needs It introduces slack into the system which helps because high utilization rates actually result in lower throughput and higher lead and cycle times. How much additional value is delivered? Your mileage will vary. A recent implementation I worked (agile transformation of around 1000 people) showed improvements of hard benefits delivery of over 100% year on year. “But”, I hear you say, “if we are delivering more than we ever have, surely this means that we can reduce costs.” That is true; you could do that. In reality there is always more demand on our capacity than our ability to fulfill the demand. This means that rather than reducing capacity, most organizations just take on more demand. So while it is possible that organizations could reduce the number of people they have, they don’t. Ironically, this means the organization’s cost structure will remain the same. An outsider with the traditional cost oriented mindset doesn’t see the additional value delivered, just the cost. If you were to point out to people that there is more value delivered most people would be happy with that. But this is not usually the discussion. What is happening here? The problem is that “value delivered” is hard to measure. Most organizations don’t do a great job of measuring it. Worst, value takes a long time to manifest (it’s a lagging metric) and it is not always clear that this particular investment resulted in a specific return. Contrast this with measuring cost, which usually easy to measure and where actions taken today almost have immediately visible results. Now don’t get me wrong. Understanding cost is important. But if we focus only on cost using our traditional mindset (efficiency, utilization, etc.), we end up actually being less effective in delivering value.

A series of posts about the engineering method, Lean thinking, and complex adaptive systems. In case you missed it, you can read the prior post here: Paid to Think (Part I): Everyone is a Scientist Another aspect of my work that I’d like to explain to my son is that of an engineer (systems engineering and chemical engineering). Imagine trying to explain a subtle, abstract concept like engineering to a four-year-old. The job is a bit like a builder, which he understands, but not quite the same thing. Perhaps also part designer, part creator, and part scientist (as discussed in prior post). As I continued watching the educational video with my son about an engineering team (Leapfrog Letter Factory Adventures: The Letter Machine Rescue Team), the team used a sequential set of steps to discover and solve problems. I was pleasantly surprised when they presented their own version of the Shewhart cycle (1), later popularized by Deming (2). This is my recreation of the cycle they described. Explore: use direct observation to discover and understand problems first hand Design: innovate and develop a plan to solve the problem Build: execute the plan and build a countermeasure for the problem Test: try out the countermeasure to see if it addresses the problem and improve if needed Improve: reflect on how the countermeasure(s) might be improved and make a change for the better (kaizen) Celebrate: express gratitude, share your work and ideas with others, and celebrate success as a whole team The show heavily emphasized “explore” through direct observation of problems at their source. A popular version of this in the Lean Startup community is Steve Bank’s motto, “Get out of the building.” (3) Which is a Lean thinker may recognize as genchi gembutsu. According to Wikipedia, Genchi Genbutsu (現地現物) literally translates as the "real location, real thing” and is sometimes referred to as "go and see." “Go and see” is about understanding how things are in context - the actual thing in the actual place. This Lean principle asserts that to truly understand a situation he or she needs to observe what is happening at the site where things actually take place, the gemba (現場). Going to the gemba is a critical practice for leaders at every level to get out of their offices and actually go to the workplace to see how the work is done rather than relying on reports and second hand information. This may be more challenging in distributed work environments, but it is still critically important. The same applies for when and where products and services are actually used. Effective leaders stay in touch with how problems are being solved and with how value is being co-created with customers in context. For some Lean practitioners, myself included, the gemba is regarded as a sacred place of sorts. When observing the gemba as part of new coaching and consulting engagements I often experience moments of awe and reverence. I find deep satisfaction helping teams improve their own value-creating work and improve how their products and services satisfy the customer’s jobs-to-be-done. The practice of going to the gemba is related to a couple concepts in complex adaptive systems theory which will be discussed in a subsequent post, disintermediation and managing in the present. Stay tuned for more about that. Going back to the engineering method from the show, in addition to “explore” I also really loved that the method presented emphasized “celebrate” which is something many teams don’t practice enough. Small celebrations are especially important to help accelerate the adoption of new behaviors and practices. While most learn about the scientific method - theory corrected by experimentation – in grade school, the engineering method is less well known. Most engineers learn about it in their freshman-level engineering 101 course in college. One of my favorite descriptions, of the engineering method comes from Billy Vaughn Koen’s work, Discussion of The Method. (4). “The engineering method is the use of heuristics to cause the best change in a poorly understood situation within the available resources.” With this broad definition, Koen goes on to make some persuasive arguments to claim “to be human is to be an engineer” and “everything is heuristic.” Lean and Agile are a fantastic set of heuristics for making things better and creating more value with customers. However, like all heuristics, they are not universal truths. All Lean and Agile principles and practices have bounded applicability – some nearly universal. I’d highly recommend Koen’s work if your team, organization, or coaching community is even the slightest bit dogmatic about the “right” way of doing or being Agile. Koen’s work would also be helpful for anyone that claim’s “That’s not pure Agile” or “Have you seen any companies doing 100% Agile?” The next post will focus on another less well-known aspect about how Toyota sustains kaizen by integrating learning and work execution. Reflection: · What method does your team use to detect and develop countermeasures to abnormal conditions? · What is you team’s ritual for celebrating success (small wins and large alike)? · How should leaders at every level regularly practice genchi gembutsu? References: 1) Shewhart, Walter. Statistical Method from the Viewpoint of Quality Control. 2012. 2) Deming, W. Edwards. Out of the Crisis. 1986. 3) Blank, Steve. The Four Steps to the Epiphany: Successful Strategies for Products that Win. 2020. 4) Koen, Billy Vaughn. Discussion of the Method: Conducting the Engineer's Approach to Problem Solving. 2003.

A series of posts about the engineering method, Lean thinking, and complex adaptive systems. As a consultant, I often struggle to explain what I do for work to friends and family, but especially my four-year-old son. I usually try simple explanations like saying, “I help people solve problems” or “I help people make things better.” I also refer to relatable roles such as teacher and coach. Not a bad start, but pretty simplistic. I’m always on the lookout for easier ways to explain the work I do. The other day I was watching an educational video with my son about an engineering team (Leapfrog Letter Factory Adventures: The Letter Machine Rescue Team). Yeah! This seemed like a perfect opportunity to try and explain another aspect of my work as an engineer to my son. The video talked about the job of the engineering team and showed several engineering examples. According to the video, it’s the job of the engineers find and solve problems. After a few minutes, my son’s eyes lit up, he paused the video and turned to me, excited to share his revelation. “Dada… You get paid to think!” Yes! [smiling] Yes, I do. This perfect moment reminded of a Lean concept that I learned from one of my mentors, Steven Spear (1). Spear spent time with Toyota doing research to “decode the DNA of the Toyota Production System” and to understand how they were able to out-learn their competitors. According to Spear, “We found that, for outsiders, the key is to understand that the Toyota Production System creates a community of scientists.” Everyone at Toyota acts as a scientist who experiments to continually improve his or her own work. For example, if a front-line worker’s job is to install a tire, then their job is also to learn how to continually improve how to install tires. It’s everyone’s job to think and improve every day. I like to help clients cultivate workplaces where everyone feels like they are paid to think. This is why I tend to have a negative reaction when people mention the concept of “knowledge workers.” Isn’t every employee or entrepreneur a knowledge worker? It makes me wonder if some folks believe that there are jobs where people don’t need any knowledge. On my pilgrimage to Toyota City in Japan, I decided to test this out for myself. Our factory tour was led by a seasoned tour guide who gave public tours as her primary job. I asked her if she had any plans to improve her work, and she described an experiment to position the tour group in a different place to get a better view of something she wanted to share. She passed the test. Her job was not just to provide tours, but also to experiment and improve how she ran tours to make them better. This is the essence of kaizen. From Dictionary.com, Kaizen [ kahy-zen ] (改善): noun a business philosophy or system that is based on making positive changes on a regular basis, as to improve productivity. an approach to one’s personal or social life that focuses on continuous improvement. While I like both of these options, here is my preferred way of defining kaizen: Kaizen – A philosophy where everyone, everywhere, everyday takes responsibility to drive change for the better. I sometimes encounter workplaces that struggle with kaizen. Some workplace cultures cultivate a “paycheck mentality” where people only feel like they are there to do the minimum needed to get paid. These folks are often not bad employees, but rather the system that they work in has beat them down over the years and seriously degraded their intrinsic motivation to the point where only extrinsic rewards matter (i.e. a paycheck). I have also seen some cases where there is not a strong enough social contract in place between the company and employees in order to make it safe to improve. For example, if a ten-person team improves their productivity by 20% through kaizen, is someone at risk for being let go? If so, why even bother with kaizen? During a prior Lean transformation for 600+ person service organization, the leader recognized the need for a strong social contract and made it a point to announce to all employees at the onset of the transformation that no one would be let go due to the improvement efforts. If you would like learn more about this spirit of kaizen, I’d recommend the work of Masaaki Imai (2). Here is a short video and longer book. In my next post I’ll share more about the engineer’s method to improve. Stay tuned. Reflection: What examples of kaizen have you observed recently? (I sometimes see extraordinary examples in what is generally regarded as ordinary work.) What symptoms would you expect to see at workplaces that lack a “paid to think” culture? What other social contracts are needed to foster a “paid to think” workplace? References: Spear, Steven. The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. 2010. Imai, Masaaki. Gemba Kaizen: A Commonsense Approach to a Continuous Improvement Strategy. 2012. Image credit: Kaizen in kanji by Majo statt Senf CC BY-SA 4.0

When we see, hear or even touch a word, a signal travels to our amygdala where the word is processed. Some words trigger an emotional response. One such word for me is accountability. It didn't used to cause an emotional response. It is a very common word in the business lexicon. However, over the years, accountability has become associated with blame. Now, when I hear someone use the word accountability. I get nervous, I start to get a little twitchy. Am I observing a finger pointer, someone who likes to play the blame game? Someone who is perfectly willing to delegate so long as "you don't mess up". This leadership style belongs in a Sopranos episode. You can't manage through fear. Not in today's collaborative environments. One we way we change attitudes is by starting with changing the language we use. What if we started talking less about word accountability and more about responsibility. But, we need to take it one step farther. We can't just start talking about being responsible. Christopher Avery explains it in The Responsibility Process: Unlocking Your Natural Ability to Live and Lead with Power: Being responsible means being good and acceptable in the eyes of another. It means receiving approval. It means conforming to expectations. By definition, being responsible relies on feelings of shame and obligation, and in having ready-made answers of denial, blame and justification. No, clearly being responsible is not enough we need to go a step beyond. Taking responsibility is vastly different. It means to see yourself as a powerful causal force for your experience of life. You, through your choices and action or inaction, can be seen as the primary cause for your: happiness of unhappiness, success or lack of success, performance or lack of performance ... Holding people accountable isn't effective. You can't manage through fear. We need to start fostering psychological safety. A very simple first step towards creating an environment where we all take collective responsibility is to retire the word accountability. Couple that with shifting the focus away from the individual and more onto teams that take collective responsibility and you will have built the foundation for lasting success.