Al Shalloway’s Post

The dogma is getting worse. I'm not surprised. Companies are starting to question the value of Agile coaches in general and Scrum in particular. This is scary for many. Fear breads dogma and cognitive inertia. But it also creates an opportunity. "It is difficult to get a man to understand something, when his salary depends on his not understanding it.” Upton Sinclair I continue to be amazed how people say I'm selling my stuff when, in fact, I'm selling an idea. The idea I am “selling” is that we can tell what's happening a lot better than what is generally known. I am not alone here. Eli Goldratt, Donald Reinertsen and Tom Gilb have written books on this. This has NOTHING to do with my approach. My approach is built on it. But it isn't my approach. It is either truth or it isn’t. I am discussing it because only a few of us seem willing to investigate this. Many others have discounted this idea out of hand with no discussion. If it's true, any then every approach can benefit from knowing this. If it's true and an approach doesn't build on it, then that approach won't be as good as it can be. It's worth knowing if it's true or not. Learning and challenging our ideas is a central concept of Agile - "we are discovering better ways ..." Most every problem I see discussed on LinkedIn, whether it be how to do something or the lack of management buy in, can be addressed with this understanding. And it takes considerably less effort to do so. And considerably less training. That actually may be the problem. ;0) Selling uncertainty is a great way to sell workshops. I like selling understanding. And when it comes to working with complexity, I’m literally giving it away. One key tenet of this is that tere are many things that if you do, you can predictably make things worse. The first thing to do then is know what these are and stop doing them. You can see a live session tomorrow – go to my website to join the Amplio Community of Practice – or wait until I put it on youtube.

A Simpler View of Complexity From “The Choice” by Dr Eli Goldratt & Efrat Goldratt-Ashlag. Eli “The first and most profound obstacle is that people believe that reality is complex, and therefore they are looking for sophisticated explanations for complicated solutions. Do you understand how devastating this is?” Efrat “He doesn't claim that reality is not overwhelmingly complex; he acknowledges it in full. But what he says is that there is a way to realize that from another more important aspect, it is exceedingly simple.” Eli “What I mean by Inherent Simplicity is that reality, any part of reality, is governed by very few elements, and that any existing conflict can be eliminated. If we take that as a given, as absolutely correct in every situation, we'll find ourselves thinking clearly.” The two aren’t waffling about complexity. They are saying that we can look at complex systems and get an understanding of things. But you have to know how to look. Sensemaking is the process by which people give meaning to their collective experiences. It has been defined as "the ongoing retrospective development of plausible images that rationalize what people are doing" Weick & Obstfeld. There are several schools of sensemaking. Many people in the Agile space like to classify domains as complex, complicated, simple, …. As a disciple of Goldratt I take a different view. We’re not in one domain or the other. Rather the world around us has varying degrees of complexity, complicatedness, simplicity, …. We can understand enough to be effective. We can’t predict black swan events or even market changing conditions but we can prepare for them by being able to pivot. We can discover our own errors by having quick feedback measured in hours and days not days and weeks. This is the key to working in the complex world of knowledge work. It involves a combination of discovering first principles that can be considered to be the physics of flow – the few elements that govern reality. Then using them to create a set of factors for effective value streams that enable us to make decisions that will improve our methods. For those aspects of our reality that are not complex, these will result in improvements. And if we don’t attend to them, we’ll definitely be less effective. Complexity, either due to outside influences or of our own making by not seeing the full ramifications of our actions, will, of course impact us. This is why we need to be on guard for this with continuous feedback. It’s like having a boat with several holes in it that we can see (simple, complicated). Plugging them up is important. When a new one is caused by complex things we hadn't seen, we have to fix it. But we shouldn’t discount the other ones either. How to do this is the essence of my Amplio Foundations session on the 23rd. Amplio Community of Practice  members can attend live and ask questions. See my website for how to register.

This was a fun, informative talk. Feel free to ask me questions about it here. Just tag me so I know you asked. If you are a candidate for a good podcast, Temitope Awere is a great podcaster. I highly recommend doing one with him. :) thanks so much for having me Temi. :)

Some advice if you're looking for a job. I was talking to a friend the other day who is looking for a new position and I gave him three pieces of advice regarding his job search. Thought it might be useful for others: 1. Take a few minutes and write down where you'd like to be in a year or 2 with your new position. Try to visualize it as best you can. Who you are working with, what your days is like, how it feels, what is satisfying about it, and how you are growing as a result of it. Add anything else that comes to mind. 2. Remember that you are trying to find a company that works well for you as well as them finding someone who works for them. This will have you be interested in them, which you should be - both for their benefit and yours. 3. Remember who you are. Don't try to fit in if it's not who you are. They are looking for people with a particular passion and interest. If you try to talk about what you aren't you're not going to convey who you are - which is what you want them to see. Trust the right company will see this. Self-select by having companies you don't want to work with recognize you are a bad fit. Find a company that wants someone like you. I guess I had a fourth one as well. Don't listen to recruiters who say anything negative about your chances. Most are just trying to fill positions in a market that's getting more crowded and makes personal attention more difficult. Experience is not the big issue. Who you are is more important. Are you open minded? Are you willing to learn? Maybe you aren't and maybe that's not what they want. Some folks now want Scrum Masters who do Scrum by the book. Is that you? If not, don't pretend it is - you'll be miserable. On the other hand, don't pretend to not be that if you are. Doubt can often be a useful tool to see what you believe you need to learn. If you don't do well in a certain situation ask yourself if that's the situation you want to do well in? Many interviews are run by people who pidgeonhole people. Is that who you want to work for? I know times are tough - but new possibilities await. Trust yourself.

If you’re having difficulties with Scrum and want to learn how to adjust what you are doing to something more effective, I have created a free path to do so. In the free Amplio Community of Practice, I have started a track which guides you from Scrum to a simple, effective team approach that fits you. By adjusting to your team’s needs you can have a simple, well defined  workflow that is fit for purpose. This lowers resistance, increases effectiveness and increases motivation. I call this the Amplio Team track. Amplio Team is not a hybrid approach but instead is based on the theories of Flow, Lean, the Theory of Constraints and human centered development directly. It also incorporates the practices of Scrum and Kanban. This combination of practices and theory enables you to choose which practices will work best for you. Many teams have trouble with Scrum for one of two reasons. The most common is that Scrum was designed for autonomous, cross-functional teams that can plan at least one week ahead. This does not fit today’s world as much as it did almost 30 years ago when Scrum was created. The path I present will help you overcome these issues. The second is the presumption that teams will figure out what to do without a model of understanding, but that inspect and adapt is sufficient. This often does not happen and teams tend to flounder and do Scrum so poor it's not really Scrum. The path presented addresses this as well by providing a few key practices that can overcome the challenges that many teams get saddled with with Scrum. There are three other tracks in the community of practice that you may find of interest. One on foundations of knowledge work, Amplio itself, and a coaching track. A presentation is made each week which includes an opportunity to ask questions about any of the tracks. If you are having challenges with Scrum and want to learn how to move to something better, somthing that puts you in charge, go to https://lnkd.in/grXq9SUi There is no cost to the program. You can work at your own pace. And you will have opportunities each week to ask questions as you have them.

Coaching tip: when an approach you're promoting isn't working for a client, you need to balance the thought of 1) they are not doing it correctly with 2) it doesn't fit them. All too often on LinkedIn when I hear someone saying they are having trouble with something there is an immediate assumption they are doing it wrong. I call this "framework bias" where promoters of frameworks are in love with their approach and can't believe it's not working. They should be looking at the situation to see what's happening and if the approach is a fit they make the immediate assumption that people are doing it wrong. One of the key tenets of Agile is to respect people. But all too many seem to respect frameworks (process) over people.

When did we decide it was ok to not understand? I admit, perhaps I go too far. I’ve been trained in theoretical mathematics where, for the most part, you can deduce most things (yes, I know of Gödel’s incompleteness theory).  And supplemented it with an engineering degree that adds an aspect of inquiring “why did that happen?” when things go wrong. Add my involvement in the human potential movement of the 80s which gave me an understanding of the biological mechanism that we call thinking but is mostly reaction, and you can see why. And yes, I understand product development is a complex adaptive system. Any kind of knowledge work is. In fact, I’d contend any organization regardless of what they are doing is. But I like understanding where I, and those I’m trying to help, work. And I have a track record of being able to do it. Too consistently to just be attributed to luck or skill or experience. The evidence is there. Supplement understanding (which is sometimes false) with a quest for quick feedback, and you can stay on track. You can see the rocks before you hit them. But most people don’t look for understanding. And the laws needed to achieve quick feedback are discounted by those who worship complexity. Most people have been all too happy with “follow until you understand.” Too many people use the excuse “we’re in a complex system and can’t understand except after the fact.” This is justified by looking at a complex world that is orders of magnitude more complex than building products. It’s really not that hard to understand product development. But you have to know what to look at. What does the customer need? Look at the customer journey and what their commitments are and how this can be improved. It’s not magic. How to improve your effectiveness and efficiency? Learn the theories of Flow, Lean, and the Theory of Constraints. Learning how to attend to the customer journey is easy – but few do it. The second one is a lifelong journey. But you can create an easy start by taking an existing solution and tailoring it slightly with a little guidance which is readily (and freely) available. If you like, get a coach to help you start. But get one that has you understanding from the beginning. “Follow until you understand” is a trap. It puts you in the passenger seat. It discards your own experience which, with a small amount of explanation, can be used to understand right from the beginning. If you don’t understand how can you hope to help others understand? And if you can’t, then don’t complain about their actions. Start learning together. What’s missing is the courage to step out on our own. The real naysayers are not those who are saying to abandon frameworks but those who are saying to hold onto them. They are discounting the rest of us. I believe we have barely scratched the surface of what’s possible. I am working with others who have the same sense.

The problem and waste created when you talk about getting more work done. A lot of fuss is made about the iron triangle: - scope - time - cost People talk about how when you fix all three quality goes down. But they ignore the fact that there is a way to create more value, in less time, by doing less work. This is the essence of Lean – do the work right, with proper feedback, and little delay while attending to the amount of work in process and you have less work to do. As a result your capacity is spent on creating value with less cost. Cost goes down while quality and value go up. Edgar Schein’s mantra “we don’t think and talk about what we see, we see what we think and talk about” tells us we need to be talking about what we want to do – create more value – not do more work. When we focus on doing more work, it leads to things like opening up too many stories at the beginning of a sprint, or not taking time to properly plan the work we’re about to do, just jumping in when some thought would be a good idea. When we focus on doing things just in time and managing our workload, we make better decisions. And when we make a mistake we get feedback more quickly which means we waste less time. I’ll admit I haven’t read Jeff Sutherland’s book “Scrum: The Art of Doing Twice the Work in Half the Time” but the title alone is damaging. Focus on value. Not work. Focus on not creating waste as shown in the picture. 

If you are committed to growing your own framework (a good idea) but would like something that is DESIGNED to be tailored for your situation AND provide you with how to make the appropriate choices, send me a DM. This is what Amplio is. It's not to tell you what to do. It's there to help you understand what you are up to, what your challenges are, what can be done about that and to grow your own approach. I'm realizing how silly it is to try to show people how to do Scrum and SAFe better when they should be growing their own methods and I can help them with that. All the insights I've talked about are still valid. And I'm still committed to making consultants better with my ACE program. I realize however, that the same program can make people wanting to grow their own more effective as well. So if you're interested in that, DM me and we can chat.

I've been thinking about how teams should be using pull to avoid overloading themselves. That is, they work on the most important thing on the backlog and have a focus on finishing so they can get quick feedback at all levels. This is how flow works. You can pivot your goal daily, not at the end of the sprint since you're committed to the sprint goal. But then a question occurred to me. Are there any #noestimates folks who do Scrum? How do you create a committed sprint goal without estimates? And yes, I've read the Scrum Guide - "The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. " I understand you can build it however you need to. But this doesn't change the question.