Kurt has not earned any certifications yet.
Classes Attended by Kurt
Latest Blogs by KurtSee all blogs
A college roommate of mine retired this week, after a long and successful career. While he's figuring out the next chapter of his life, it caused me to think about whether the notion of a "career" is even relevant in today's world.
Apr 3, 2019 Read blog
I’ve had this ongoing discussion with a few of my colleagues who says that the term “agile leader” is an oxymoron - that the ideal organization is a bunch of Scrum Teams and not much else. Even in an ideal world, I disagree, and here’s why in a nutshell: I’ve never seen, and have not even heard of, an organization that was successful in their pursuit of agility who did not have a strong leader guiding the vision for what the organization can become, motivating people to achieve that vision, nurturing the pursuit of that vision, and protecting, when necessary, the people who want that vision from the people who don’t. The reason for this is simple, and is as old as civilization. As Nicolo Machiavelli observed, “It must be considered that there is nothing more difficult to carry out nor more doubtful of success nor more dangerous to handle than to initiate a new order of things; for the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order; this lukewarmness arising partly from the incredulity of mankind who does not truly believe in anything new until they actually have experience of it.“ As intellectually compelling and self-evident we would like the advantages of agile to be, the truth is that there are people who benefit from the old system, and they didn’t get to where they are because they are not astute and influential. They are not simply going to resign their current advantages because someone proposes a superior system; you have to expect that they are going to fight to maintain the status quo. What Agile Leaders Do? Agile Leaders focus on three things: (1) they create and nurture a culture in which experimentation and learning are embraced; (2) they collaborate with employees (at all levels in the organization) to find common values to create a greater goal for the company and the teams; and (3) they create an organizational structure that reinforces and rewards the other two dimensions. Goals Providing guiding vision for shared goal setting is, in my opinion, the most important focus area, and the one that survives even after the organization and culture are largely self-managing and self-sustaining. The goals they inspire others to contribute to and make their own are strategic, and are generally customer or market focused. By strategic, I mean bold and audacious; both aspirational and inspirational. To providing contrasting comparison, think about the motivational difference between the goal of landing on the moon and returning, by the end of the decade with a more prosaic goal of improving profitability by 25%; no one is going to tell their grandchildren that they helped improve investor returns. These motivational goals that leaders help us to identify have some common characteristics: the are motivating and inspiring, but they also are uncertain; they force us to stretch, to do things we have never done before. That’s why agility is so important; if we knew how to reach those goals, we should just develop a plan and march to it. Leaders help their employees to persist in the pursuit of their shared goals and values when times get rough and old behaviors want to take over. Organization The basic agile team structure is very simple; if we use Scrum as an example, there are only three roles: the Product Owner, the Development Team, and the Scrum Master. But not everything an organization does is done by an agile team; agility is needed whenever we are dealing with complexity, but not everything is complex. If you were running a company that makes paint, research and development would need agility, but the paint factory itself might be better suited to using lean processes; unless you’re doing a lot of small-batch custom manufacturing, a predictive continuous flow process is probably better than planning production as a series of Sprints. The point is that, unless you are a small software start-up, there will always be things outside the scope of what agile teams do, even if they are only as mundane as payroll, accounting, tax compliance, legal, and investor relations. The role of management is to design, monitor, and correct this system to make sure that the organization achieves its goals. Even product development companies need to do more than simply developing the product. Where agile leadership comes into play in the management context is that they need to make sure that the different parts of the organization, with different operating models, don’t destroy each other. Put more positively, agile leaders need to help the organization optimize for flexibility and continuous improvement, making sure that improving customer outcomes always comes first, and that the other parts of the organization support this mission. But the other things need to get done, too. Agile leaders also help teams progress in their maturity. Agility is not binary, and there are predictable stages that teams go through as they improve their ability to learn and improve. Leaders create a supportive environment in which teams can progress, they provide coaches and exposure to peers who can help the teams learn, and they commit themselves to improving their own abilities in parallel. My college Ron Eringa has written a handful of excellent blog posts about this topic. Culture The most important thing agile leaders do is to foster a culture that supports empiricism and learning, and that is constantly seeking better customer outcomes and better ways of achieving those outcomes. The challenge for leaders is that they can’t dictate the culture; they can only create the right conditions for it to emerge. Some of my colleagues like to use a “gardener” metaphor: if you’ve ever had a garden, you know that you can’t make anything grow. You can create the right conditions with the right amount of water (but not too much), and enough sun (but not too much). You can remove other plants that might compete with the ones you want to grow, and you can protect the plants from predation. You can’t control all factors, however, and an organization’s culture emerges only partly as an expressions of its leaders aspirations; most of it comes from the people in the organization, how they treat each other and work together. Culture is the non-copyable je ne sais quoi that makes your organization unique. But while leaders can’t control and dictate this culture, they can encourage it and cause it to flourish by the examples they set and the behaviors that they model. Agile Leaders are the key to scaling agility Agile leaders play an important, even essential, role in scaling agility in an organization. While agile teams can fly under the radar so long as their scope remains small, the larger the scope and scale of agility, the more agile teams need supportive leaders to help them to frame the right goals, to make the organization work in support of agility and not against it, and to evolve the culture to embrace and reward learning, rather than merely tolerating it. What organizations who are struggling to scale their agility are most often missing is strong, supportive agile leadership that helps them to build strong, cohesive agile teams. Agile leadership and high-performing teams work in a kind of feedback loop: weakness in one weakens all, while strong leadership reinforces and strengthens strong teams, and vice versa.
Nov 5, 2018 Read blog
It has been said that the definition of insanity is doing the same thing and expecting different results, and yet we engage in an unconscious fiction of predictability every day. We work in an uncertain world, and our main goal in pursuing agility is to confront the unknown, and in doing so, to master it.
Aug 24, 2018 Read blog
Impact Mapping is a powerful technique that helps teams understand how to link the work that they do with results that their organizations would like them to achieve. We’ve been using this technique for a while in our Scaled Professional Scrum and Professional Scrum Product Owner courses.
Jun 12, 2018 Read blog
According to Forrester Research, 90% of Agile teams use Scrum. One reason for this popularity is that Scrum is a simple framework that promotes transparency and empiricism. It is based on a set of principles and values, and consists of three roles (Product Owner, Scrum Master, and Development Team), five events, (the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective), and three artifacts (the Product Backlog, the Sprint Backlog, and the Product Increment), making it highly adaptable to different situations. Scrum is documented in the Scrum Guide, and is free for anyone to use. When one team works on a single Product, they simply use Scrum. In cases where one team works on multiple Products, they may still benefit from using Scrum if they work on one Product in one Sprint, then another in the next Sprint. This is simply a kind of multi-tasking (see Figure 1). Using Scrum across Multiple Teams Scrum is targeted at a single Product being produced by a single Scrum Team. Two teams, and sometimes three, can use Scrum to develop a single product, but as more teams are added, the teams need a bit more than Scrum to manage their cross-team dependencies to ensure that they are able to deliver working Product Increments. We call this “something more” the Nexus Framework, which adds minimally to Scrum. Figure 1 When to use Scrum and Nexus, at a glance Sometimes, the need for Nexus sneaks up on an organization. They start with one team, working on one Product, but as the Product’s complexity grows, they start adding people to that team until they have too many to effectively work as one team. With two teams, they can still use Scrum but they need to spend some extra time collaborating informally across teams. This might even work if they grow to three teams, but they often find they need a little something extra to help the teams collaborate. Nexus provides minimally intrusive mechanisms to help them continue to scale without “breaking” Scrum. Nexus is based on decades of experience working with organizations who are scaling their use of Scrum. Nexus is documented in the Nexus Guide, and is also free for anyone to use. There are several pieces of updated and new Nexus content now available. A new version of the Nexus Guide has just been released. In addition to the guide updates, Patricia Kong, Dave West, and I, from Scrum.org, have also recently written a book on Nexus, The Nexus™ Framework for Scaling Scrum, published by Addison-Wesley Professional. If you have questions regarding Nexus and the updates to the Guide, register for our upcoming webinar, What is Nexus? An Introduction to the Framework for Scaling Scrum. If you’d like help beyond those resources, you can take a Scaled Professional Scrum with Nexus course. Many teams working on many independent or semi-independent Products is really a different kind of problem. Each Product may use Scrum or Nexus, some kind of product portfolio management and/or program management approach is usually needed to coordinate their work Scrum and Nexus can be used in conjunction with these practices, without modification. But what about organizational change and culture? Adopting Scrum and Nexus often mean changing the way people in an organization, beyond the Scrum Teams, work. It requires creating a supportive environment in which the cultural changes that support Scrum can take hold. While the Scrum Master helps a Scrum Team to change the way they work, Scrum teams need support, nurturing, and protection to help the new behaviors stick. That’s where Scrum Studio helps to create the right management and cultural environment in which empiricism can survive and thrive. We recently published a white paper describing Scrum Studio, and an organization who is using it was recently featured in an article. Links to Resources Scrum The latest Scrum Guide Nexus The latest Nexus Guide Nexus book: The Nexus™ Framework for Scaling Scrum Nexus course: Scaled Professional Scrum with Nexus Nexus webinar: What is Nexus? An Introduction to the Framework for Scaling Scrum Scrum Studio Scrum Studio white paper: Scrum Studio: A Model for Innovation Scrum Studio article  https://www.forrester.com/How+Can+You+Scale+Your+Agile+Adoption/fulltext/-/E-res110444#AST962998 2013
Jan 17, 2018 Read blog
I have created a little exercise that I like to use to help focus the on things we can change, or at least situations to seek out or avoid, to help focus change efforts. The essence of it is summarized in a picture. I call this the agile affinity model, and the dimensions the key drivers of empiricism.
Nov 28, 2017 Read blog
I was speaking at a conference recently, and during the Q&A an audience member asked a question that I hear a lot: what should an Agile organization measure, and where should they start? My answer: start by measuring customer outcomes. I could tell this wasn’t quite what he expected, because he said, “well, sure, that’s nice, but that’s really hard. what about stuff like velocity?” My answer was still the same, but to shed a different light on the problem I asked: “What’s better? A hundred story points in the wrong direction, or one story point in the right direction?” Output matters, but only when delivered outcomes are right The truth is, worrying about velocity is a trap: it says “we don’t care where we end up, so long as we get there fast.” That’s just wrong. Teams who measure their velocity but don’t or can’t measure customer outcomes may, quite simply, be driving in the wrong direction. When I talk to teams about this, they have a lot of reasons why measuring customer outcomes is very hard, and they are right - but if you can’t tell whether you’re delivering something valuable, you might be wasting your time. The root of the problem is that most requirements are wrong Measuring velocity would be the right thing to do if you could be sure that you’re building the right thing. Most teams think they have sidestepped the problem by claiming that the Product Owner decides whether a Product Backlog Item is correct or not. And this is true – except that Product Owners are not somehow magically omniscient; they have the same confirmation biases the rest of us have. The problem is nicely researched in a number of studies by Ronny Kohavi.  In his research group’s long-term study of ideas and their impact on business results, they found that only a third of the ideas produced positive results, another third resulted in no change, and a third of the ideas actually made things worse. Things get implemented but are never used, or when they are used they require substantial rework to get them right. One of the philosophical ancestors of Agile delivery approaches was the Toyota Way, which identifies 8 types of waste; at the top of this list is overproduction, producing items for which there are no orders.  Requirements that are never used or don’t deliver a desirable result is a normally invisible form of unsellable inventory, a form of waste. Focus on Outcomes, not Outputs Velocity measures output, how much work a team produced. Except that it really doesn’t measure useful work, just that they did something. Relying on the Product Owner or Stakeholders to tell the Development Team that the work was useful might seem like a solution, but they are usually the source of the PBIs, and they wouldn’t have proposed them if they didn’t think they were useful. Sprint Reviews are necessary, but not sufficient. Years ago I was in charge of a product development group consisting of many teams and several Products and Product Owners. The teams really worked hard on a release, and we aggressively worked to deliver what we thought was what customers wanted. Shortly after the release, I was meeting with some of our larger customers, and I asked them what they thought of the release. The answers I got back varied, but the general theme was that they didn’t think we had done very much. I was stunned, more than a little confused, and frustrated. We thought we had listened to our customers and delivered what they wanted. My experience in this is not unique – nearly everyone I know who has had responsibility for delivering products has had a similar experience. I thought about this a lot, and I finally realized what had happened – we had delivered a lot of features to those customers, lots of output, but we hadn’t really improved the outcomes that they experienced. Making hypotheses explicit helps As I learned when I talked to customers, you can’t see any of this until you start to measure customer experiences. When you do start to measure experiences, the light bulb goes on, and it changes the way you look at the world. Every Product Backlog Item is really just a theory about how you are going to make someone’s life better, and your life gets easier when you state the PBI as a hypothesis, not a statement of fact. Jeff Gothelf and Josh Seiden’s book Lean UX is a great resource for shifting your mindset to think about outcomes and hypotheses.  Among other insights, they offer a different format from the typical user story for capturing PBIs: We believe that we will achieve [business outcome] if this user [persona] can achieve [user outcome] with this feature [feature]. The important difference from the typical user story is that the belief is made explicit, as is the business outcome that will be achieved when the user has a particular experience. What’s missing from this statement, but captured along with the statement, is how you will measure the user outcome. “Done” really has to mean “in use” It’s not enough to say that something is “done” because it's been tested, or even that the Product Owner has agreed that it's done, or even because stakeholders agree that it's done because everyone may be mistaken in their assumptions about what customers really need. It’s not even enough to say “done” is “deployed to production” because we can’t test our assumptions until someone uses it; no one receives any value until the product increment is being used. This is a very high standard for most teams, and it will take a lot of work to get there, but until everyone understands that only outcomes matter, nothing will change. Why Lead Time matters When Development Teams, Product Owners, and Stakeholders start seeing what’s being used and how, their behavior changes. They start focusing on forming and testing hypotheses and learning fast. I talked to a lot of organizations when I was an analyst with Forrester Research, and the pattern that emerged was that once the lead time (the time between when an idea is conceived and when you can measure the results) drops below 3-4 weeks, people start working more experimentally. Anything longer takes too long for them to think of working differently; by the time they get the answers, they have forgotten the question. The smallest possible release: one outcome, one persona Using Lean UX vernacular, the smallest release that is worth measuring, or even releasing, for that matter, is a single improved outcome for a single cohesive set of users (represented by a persona). Anything more than this increases your lead time by delaying the benefits that might be experienced by a more narrowly focused set of users. And anything less than this is simply a waste, a bunch of features that don’t improve anyone’s outcomes, and a lot of effort for nothing. A lot of leaders in product delivery organizations want faster delivery, but they are still stuck in a “big release” mindset and they spend a lot of time and money trying to speed up the delivery of big releases. The fastest way to improve lead time is to reduce the size of the release, or the batch size, using Lean vernacular. The smallest meaningful batch is one outcome for one persona. The sooner they do this, and the sooner they start measuring outcomes, the sooner they find out that most of what they thought they needed to deliver isn’t needed, but some things they didn’t even think of are really essential. Their situation is much like the one faced by John Wannamaker (1838-1922), a successful merchant, who observed: “Half the money I spend on advertising is wasted; the trouble is I don't know which half.”  Reducing Lead Time and release size by focusing on one outcome for one persona gives them the rapid visibility that they need. One outcome, one persona is really the minimum viable release. If you can’t maximize Outcomes, maximize Learning Sometimes you can’t tell what the desired outcome is, but you can form hypotheses about what you think customers want and then test them. The faster you can do this, the faster you will learn and the sooner you will be on your way to delivering something of value. In reality, we should worry less about continuous delivery and more about continuous learning. Delivery is essential to learning quickly, but learning is the real goal. Customer’s needs are always changing, and the need to learn, to inspect and adapt, never really goes away. How to get started It’s easy to say “measure outcomes, not outputs”, but doing so means lots of small, and even some dramatic changes, by lots of different people. Product Owners must state PBIs in terms of outcomes and success measures. This helps everyone - Development Team and stakeholders - because it more clearly describes the goals that everyone needs to achieve. The discussions that result are healthy and invigorating, and they help everyone be more creative in coming up with solutions. Product Owners must set Sprint Goals in terms of outcomes and learning. Achieving a particular customer outcome is best, but when you don’t have enough information for that, making the goal to learn specific things about the customer will help you to converge on delivering the right solution. Product Owners must scope releases in terms of outcomes and personas, the fewer the better. This will reduce the complexity of releases, give everyone clear targets, and reduce batch size which reduces lead time. The Development Team and Operations must work together to create a reliable delivery pipeline. Smaller and more targeted releases mean that organizations will need to release products more frequently. Developers and Ops need to get really good at releasing reliably all the time. Developers need to create reliable automated regression tests for legacy applications. Every application today is connected to lots of other applications. Fear of breaking something often prevents organizations from releasing quickly because they know they can’t adequately test all applications manually. Automating regression tests takes time, but measuring outcomes helps. If you instrument your code to identify dead code that’s never run, you can identify a lot of regression testing that doesn’t need to be done.  https://ai.stanford.edu/~ronnyk/2009controlledExperimentsOnTheWebSurvey.pdf  Jeffrey Liker, The Toyota Way, 2004, McGraw-Hill, pp. 28-29.  Jeff Gothelf and Josh Seiden, Lean UX, 2016, published by O’Reilly Media, Inc.  https://www.b2bmarketing.net/en/resources/blog/half-money-i-spend-advertising-wasted-trouble-i-dont-know-which-half
Jul 28, 2017 Read blog
Organizations who don’t understand why they want to become Agile also often take the wrong path to get there. Agility requires empowering teams and helping them make decisions on their own, learning from their experiences as they go. They must organize themselves, yet they often have Agile practices forced upon them. I’ve personally encountered many teams who didn’t understand why they were on an Agile journey, didn’t really want to be on the journey, and weren’t particularly happy about it. No good comes from those situations, and the result is usually a team going through the motions, telling management what they think they want to hear rather than really embracing Agile principles. Agile transformations can't be planned Management, for their part, are equally culpable in this comedy of errors: they don’t really understand what Agility means or demands. They can be motivated by mistaken assumptions such as thinking that Agility is a means of improving efficiency rather than a means of achieving better outcomes that cannot be fully understood at the onset. Convinced that Agile Everywhere must be a good thing, these managers want a plan for rolling out Agile, with milestones and progress measures that they can use to manage the roll-out. The Agile adoption is planned like a military campaign, with great speeches and slogans, sometimes even complete with banners exhorting teams on to victory. “Becoming Agile” is a strategic objective, like a hill that troops must take on the path to victory. The military metaphor for Agile adoption is flawed for many reasons, not the least of which that it applies a Waterfall process for adopting an empirical approach to delivering business value. It ignores the essential importance of team self-organization in a way that actually prevents teams from ever self-organizing. It discourages empowerment from the very beginning. Agile practices are not like a new version control tool that can be rolled out to one team after the other, in lock-step execution of a plan. We need a different metaphor to help us think about the problem. Becoming an Agile organization requires a cultural phase change In physics, phase changes occur when matter changes from one state to another, like when a pond changes from liquid water to solid ice. No one would talk about planning which molecules are going to change phase in what order; in fact the process is unpredictable. What happens is that, when the temperature of the water is just right, a small non-conformity causes a crystal to start to grow. Sometimes this happens in a single place, and sometimes in a number of places at once. The crystals grow and spread naturally, depending on local conditions. Changing a culture requires an approach more similar to encouraging a pond to freeze than planning a military campaign. The right conditions for the change have to be in place; these conditions can be evaluated by examining the beliefs of the product owners, business leaders, and delivery team members responsible for a product. When the beliefs of these people support experimentation and learning, they are open to trying new things and working in a new way. These product teams are capable of making the changes. When their beliefs are not supportive of the change, it is like having impurities in pond water that prevent it from freezing; forcing them to change is ineffective. Instead, you should work on changing their beliefs, perhaps by helping them to understand that a predictive approach to product delivery will not help them achieve the results they want. This is a long path, however, and if you are trying to change the organization, you are probably better off finding some other product team that is ready for the change than investing time in changing the beliefs of people who are not yet, and may never be, ready. Agile organizational change is opportunistic Working opportunistically, using the metaphor of the freezing pond, means focusing on helping parts of the organization that are ready to change, and that need to change to be successful. Agile practices will help them thrive. But other parts of the organization are nowhere near the critical phase transition, and no amount of energy applied to make them change will produce more than superficial conformity. Beyond finding product teams ready to change, what can be done? Well, every part of the organization can benefit from improving their engineering practices, and reducing their technical debt. Senior leaders can be helped to understand why an empirical approach may be essential for their organization’s survival, just as Jeff Immelt came to see that Agile software delivery was essential to the future of GE. Leaders have a strong influence over the beliefs of an organization, and they alone usually have the ability to help their organizations see things in a new way. What they usually need is to be shown proof that an empirical approach delivers innovation where the predictive approach won’t, usually by trying it on a product in a new market, or on a product that has nothing to lose by experimenting with a new way of working. These are the pockets of non-conformity where the cultural phase change starts and from which it spreads. Find and nurture these, and then look for other similar opportunities while building a supportive Agile ecosystem.
Oct 20, 2016 Read blog
I’ve spent a lot of time looking at how organizations are using DevOps to improve their software delivery cycle time, their ability to innovate, and their ability to improve quality. I’ve heard some people go so far as to say that DevOps has replaced Agile, but I don’t think that’s true. If anything, DevOps reinforces and supports Agile, and Agile is still at the heart of DevOps. The essential features of Agile - working in small increments (batches), delivering working software frequently based on business priorities, working in small self-managing cross-functional teams, and measuring progress by working software - are essential for DevOps to work. In my view DevOps makes explicit what many Agile teams had already learned but may not have formalized. DevOps also spreads Agile principles to other parts of the organization, especially Ops. In truth, Agile and DevOps are symbiotically and inextricably linked. Agile needs automation to really boost velocity The Agile Manifesto says Agile teams value working software over comprehensive documentation. This means that they need to build and test software. A lot. All of the time, in fact. Ideally, they need to build every time they commit a change to the source code repository. But builds are just the starting point - they also need to test every time they make a change. Not just unit tests, but functional tests, regressions tests, performance and scalability tests, all driven from APIs. And not just in simple environments, but ones that look as much like production as possible. When they do this they deliver better code. To do this, they need to practice trunk-based development. They need continuous integration automation that drives not only the build process but a robust API-based testing process, every time code is changed. They also need to have robust test environments available on demand, which means using infrastructure as code or other environment provisioning automation. And at some point, when they are fully responsible for supporting the application in production, they need release automation tools to reliably deploy code. Some people have taken the Manifesto’s statement that Agile teams value Individuals and interactions over processes and tools to mean that tools aren’t important. People are most important because they are the ones who actually create software, but in practical terms those people need tools. The gap between “potentially releasable” and “actually released” can be vast Demonstrating working code in a demo at the end of every sprint is essential. Demos are not the same as the real world, however. Demos don’t test real workloads in real-life threat environments. Demos don’t have to play nice with other applications. Demos don’t have to be fault tolerant or self-healing. Demos in a test environment are necessary but not sufficient. Scalability, security, reliability, and maintainability are essential. Demos can focus too much on the look and feel of the application and not enough on its real-world characteristics. Agile teams who support their applications in real world environments learn this in a hurry. Realistic production-like testing environments are a good first step. Advanced deployment techniques like blue-green deployments and canary deployments, deployments to subsets of the user community, provide insights that demos never can. Testing the deployment processes themselves by frequently deploying to real-world environments helps to remove inconsistencies that are significant sources of production incidents. Agile teams need to adjust their definition of done to eventually encompass deploying to real customers - until they do they may be fooling themselves about the quality and value they think they are delivering. Product Owner and stakeholder feedback is great but real customer feedback is the true test of value delivered The Product Owner is the single authority on what needs to be built and the arbiter of “done”, at least until real customers speak. Product Owners, even great ones, are people like the rest of us, with their own biases and blind spots. Adding other stakeholders to demos can help by expanding perspectives, but they, too, have blind spots. The ultimate arbiter of value is the customer, and the faster a team can deliver to real customers, the faster they will confirm or reject the theories they have about what those customers really need. This is not a criticism of the Product Owner’s role, or the opinions of stakeholders, merely a reflection of reality. Application architecture matters Performance and scalability matters. Security matters. Services, microservices, and APIs especially matter. The more loosely coupled an application, the easier it is to change one part without that change breaking lots of other parts. APIs can be regression tested as part of the Continuous Integration process. Minimizing code dependencies also has a pay-off when tackling larger applications: coordinating work with other teams through shared APIs is a lot easier than sharing data structures. A lot of complex program management and team coordination overhead can be avoided when team dependencies are mediated through APIs. Techniques like service virtualization (otherwise known as mocking and stubbing) can be used to simulate commitments while the other team works on delivering the new API. One of the reasons that legacy application code is so hard to release frequently is the the applications tend to be monolithic, sharing data structures and databases with other applications. They are hard to change because every change has unknown side effects. Getting this code back under control will take years, and it may simply be easier to rewrite it. But modern applications don’t have to be this way, and Agile teams need be work hard to see their applications loosely coupled, lest these applications become the legacy applications of tomorrow. Small batch size is really important for fast feedback cycles and reducing release risk The smaller the release, the fewer the dependencies. The fewer the dependencies, the fewer things there are to go wrong. If you want to reduce the risk of a release, reduce the size, don’t double-down on control processes that actually increase release size by creating a process so onerous that people will do anything to avoid it, like releasing less frequently. Smaller releases makes coordination easier. They make user adoption easier because there are fewer changes or new features to learn. Smaller more targeted releases make it easier to evaluate their impact because their are fewer things to measure. This makes feedback faster, which reduces waste and helps teams to better scope future releases. Smaller, more frequent releases are good. They are good, but only if a team is continuous building and testing their software. They are good only if release processes are simple, streamlined, and predictable. They are good only if applications are loosely coupled and don’t create a cascading series of problems when something fails. Agile teams need DevOps practices, and DevOps needs Agile’s teaming model and connection to business value to drive better results DevOps practices help Agile team to automate the mundane and routine, letting their focus on writing high quality modular, loosely coupled code that delivers the right solution. DevOps needs Agile’s business-driven (through the Product Owner) backlog and pipeline management capabilities. It needs the Agile teaming model to create high-performing cross-functional teams. Agile teams need to add Ops and Security skills to their repertoire as they increasingly take on responsibility for managing applications in production. Agile and DevOps are not really separate things. Agile has always embraced excellence in engineering principles. Having to deliver and support applications in production expands that focus. Doing so at significantly faster cycles means that automation is now an even more important part of those engineering practices.
Sep 15, 2016 Read blog
Agile approaches, including Scrum, are empirical approaches to delivering software and business value. It is ironic, then, that the biggest impediment to adopting an Agile approach is the culture of the adopting organization. The Cambridge English Dictionary states that culture is "the way of life, especially the general customs and beliefs, of a particular group of people at a particular time.” The beliefs of the people in the organization, and especially its leaders, are powerful predictors of whether that organization will successfully embrace Agile principles. Change is painful. The change that we ask organizations to make when they embrace Agile principles can be deeply unsettling. We ask the people in the organization to potentially see that everything they have come to believe about planning and managing software delivery, and even business value delivery, is wrong. They may believe that the best way to deal with uncertainty is to have a more precise plan. They may believe that resource specialization is the best way to manage scarce skills, and they believe that career paths based on specialization will best guarantee their economic success. They may believe that they will get the best results if they reward individual success and punish individual failure. Organizations that embrace Agile principles reject all of these beliefs, and many others, as false. When we ask people to embrace Agile practices, we are asking them to abandon a world view that, while not perfect, may seem to them better than the next best alternative. At the core of our mission to help them, we must show them that Agile is not just different but better. We are only successful in that mission when their beliefs change. In order for us to do this, there have to be cracks in their world view that can let new ideas penetrate. I have found that the following beliefs establish the possibility that the organization is open to change. The greater the degree to which the people in an organization affirms these beliefs, the more open they will be to embracing Agile principles. Conversely, when those people do not affirm these beliefs, their organization’s cultural inertia may be too strong to overcome. Belief #1: “If the organization does not change, it will cease to exist.” There is nothing like imminent demise to make an organization willing to try something new. Plenty of organizations find themselves in this position today; upstart digital innovators are breaking old business models at a pace that traditional organizations cannot match. When an organization’s leaders believe that their current culture cannot produce the innovative products and services that the market demands, they are open to changing anything and everything. The problem that many organizations face is that they don’t see that the world has changed around them until it is too late, if they even see it then. They can powerfully insulate themselves from seeing the truth. When they do finally see it they can succumb to despair or finger-pointing. Neither are productive. They must come to believe that Agile is a way out of the crisis in which they find themselves in order for an Agile transformation to be successful. Belief #2: “The path forward cannot be planned or predicted without experimentation.” Even when they believe that they are in trouble, people may still cling to the belief that traditional, predictive planning will save them. They may believe that if they can just deliver the competitor-killing new product that they have on the drawing boards, they will be fine. The problem with this belief is that when markets change, assumptions change along with them. Traditional planning approaches are chock-full of assumptions about markets, features, and customer needs that have never been tested or validated. As long as the organization believes that “the business” knows what customers want, they just need to deliver it faster, they will continue to cling to traditional delivery models. If they believe that they already know what they need to deliver, they will see no benefit in working iteratively, delivering working software, measuring the result, and refining their definition of the right solution. They will believe it reasonable to expect a detailed plan on when those requirements will be developed and tested. They must first come to believe that their understanding of customers is imperfect, that they really only have theories about what customers really need, and that they need to form and test hypotheses about those needs in order to achieve success. Once they believe this they are ready to embrace an empirical approach. Belief #3: “Delivering business value is more important than individual employee utilization.” Knowledge work in the 20th century came to be characterized by functional separation into roles and job categories, based on the assumption that work is specialized and that the best way to reduce cost is to keep expensive resources as busy as possible all the time. This usually means that people work on lots of different projects at once to minimize idle time. Since almost everything modern organizations do requires people to work together, the result of this is that everyone waits on someone else to get things done. More multitasking means more waiting on others, which leads to more multitasking and more waiting. The result is that delivering even the simplest change can take a very long time due to waiting and hand-offs. Delivering value to customers, faster, means reducing wait time, which means reducing role specification and dedicating resources to focus on product delivery. The Scrum team does this by having dedicated multi-skilled resources that reduces their dependence on resources external to the team. This minimizes wait time and improves time-to-market. Until organizations value time-to-market more than employee utilization they will be unable to improve their ability to deliver value quickly. Belief #4: “The organization’s leaders believe that their teams are capable of making decisions and doing the right thing.” Traditional organizations reward and promote based on the ability for individuals to get things done. They reward initiative and results. They celebrate “heroes” who single-handedly rescue troubled projects from disaster. The underlying belief is that teams are incompetent on their own and without a strong hand guiding them they tend to be hapless. This, unfortunately, tends to be true in organizations who punish mistakes and does not encourage learning and innovation. Leaders in these cultures use phrases like “accountability”, and want to have “one throat to choke”. Unfortunately, when the work is complex, these “heroes” usually cause more damage than they fix. Delivering software, or designing complex physical products that involve software, is a complex team activity, not the result of individual heroic acts. When the work is complex enough to require a team of professionals to deliver the product, managers must trust that the team is capable of making important decisions. Managers can set goals, ask questions, and clear impediments, but they must accept that they don’t understand the work and can’t effectively direct it. This realization can be an emotional punch in the gut, and is one of the hardest transitions a manager has to make when adopting an Agile approach. When leaders believe in teams, they are tolerant of mistakes. They ask questions that help the team to learn from empirical data. They use retrospectives at multiple levels to help the organization learn and improve. They DO NOT look to lay blame or punish mistakes. They DO help the team clear roadblocks and make sure they have the resources they need. Belief #5: “The organization’s leaders believes that innovation is more important than efficiency.” An organization that values efficiency over innovation believes that it knows its customers and that it is building the products those customers want. It also believes that it is doing it better, at least in some important dimensions, than its competitors. An organization that values efficiency over innovation believes that it will differentiate itself through lower costs, or it believes that its prices are good enough and it simply wants to increase its profit margin. An organization that thinks efficiency is more important than innovation will never successfully embrace Agile principles. An organization that values innovation over efficiency does not yet know what its customers want, or it seeks a new set of customers with unknown needs. It also does not yet know what it needs to do to meet those unknown needs. It relies, instead, on an empirical approach, on forming hypotheses about what customers need and what will satisfy them. It values fast delivery of high quality solutions, and it values and acts on feedback. Agile approaches help organizations systematically create solutions that test these hypotheses and adapt based on results. Recommendation: Understand your organization’s belief system and choose battles carefully Large organizations are complex societies with sub-cultures and pockets of non-conformity. Even small organizations can have sub-cultures. If you’re trying to introduce Agile practices into an organization, focus on finding small enclaves where the traditional belief system is being threatened by forces from the outside - an emerging market segment, or one which is threatened by digital competitors. Build Agile success here first. Success will get attention from other parts of the organization who are also similarly threatened and ready to change. Not all these beliefs may be fully in place, but there need to be signs that the beliefs are starting to change in an Agile-friendly direction. Beliefs can be influenced, nurtured or dampened, but they are ignored at one’s peril.
Sep 9, 2016 Read blog