One of the most insidious obstacles to continuous delivery (and to continuous flow in software delivery generally) is the works-on-my-machine phenomenon. Anyone who has worked on a software development team or an infrastructure support team has experienced it. Anyone who works with such teams has heard the phrase spoken during (attempted) demos. The issue is so common there’s even a badge for it:
Perhaps you have earned this badge yourself. I have several. You should see my trophy room.
There’s a longstanding tradition on Agile teams that may have originated at ThoughtWorks around the turn of the century. It goes like this: When someone violates the ancient engineering principle, “Don’t do anything stupid on purpose,” they have to pay a penalty. The penalty might be to drop a dollar into the team snack jar, or something much worse (for an introverted technical type), like standing in front of the team and singing a song. To explain a failed demo with a glib “<shrug>Works on my machine!</shrug>” qualifies.
It may not be possible to avoid the problem in all situations. As Forrest Gump said…well, you know what he said. But we can minimize the problem by paying attention to a few obvious things. (Yes, I understand “obvious” is a word to be used advisedly.)Pitfall 1: Leftover configuration
Problem: Leftover configuration from previous work enables the code to work on the development environment (and maybe the test environment, too) while it fails on other environments.Pitfall 2: Development/test configuration differs from production
The solutions to this pitfall are so similar to those for Pitfall 1 that I’m going to group the two.
Solution (tl;dr): Don’t reuse environments.
Common situation: Many developers set up an environment they like on their laptop/desktop or on the team’s shared development environment. The environment grows from project to project, as more libraries are added and more configuration options are set. Sometimes the configurations conflict with one another, and teams/individuals often make manual configuration adjustments depending on which project is active at the moment. It doesn’t take long for the development configuration to become very different from the configuration of the target production environment. Libraries that are present on the development system may not exist on the production system. You may run your local tests assuming you’ve configured things the same as production only to discover later that you’ve been using a different version of a key library than the one in production. Subtle and unpredictable differences in behavior occur across development, test, and production environments. The situation creates challenges not only during development, but also during production support work when we’re trying to reproduce reported behavior.
Solution (long): Create an isolated, dedicated development environment for each project
There’s more than one practical approach. You can probably think of several. Here are a few possibilities:
- Provision a new VM (locally, on your machine) for each project. (I had to add “locally, on your machine” because I’ve learned that in many larger organizations, developers must jump through bureaucratic hoops to get access to a VM, and VMs are managed solely by a separate functional silo. Go figure.)
- Do your development in an isolated environment (including testing in the lower levels of the test automation pyramid), like Docker or similar.
- Do your development on a cloud-based development environment that is provisioned by the cloud provider when you define a new project.
- Set up your continuous integration (CI) pipeline to provision a fresh VM for each build/test run, to ensure nothing will be left over from the last build that might pollute the results of the current build.
- Set up your continuous delivery (CD) pipeline to provision a fresh execution environment for higher-level testing and for production, rather than promoting code and configuration files into an existing environment (for the same reason). Note that this approach also gives you the advantage of linting, style-checking, and validating the provisioning scripts in the normal course of a build/deploy cycle. Convenient.
All those options won’t be feasible for every conceivable platform or stack. Pick and choose, and roll your own as appropriate. In general, all these things are pretty easy to do if you’re working on Linux. All of them can be done for other *nix systems with some effort. Most of them are reasonably easy to do with Windows; the only issue there is licensing, and if your company has an enterprise license, you’re all set. For other platforms, such as IBM zOS or HP NonStop, expect to do some hand-rolling of tools.
Anything that’s feasible in your situation and that helps you isolate your development and test environments will be helpful. If you can’t do all these things in your situation, don’t worry about it. Just do what you can do.
If you’re working on a desktop, laptop, or shared development server running Linux, FreeBSD, Solaris, Windows, or OSX, then you’re in good shape. You can use virtualization software such as VirtualBox or VMware to stand up and tear down local VMs at will. For the less-mainstream platforms, you may have to build the virtualization tool from source.
One thing I usually recommend is that developers cultivate an attitude of laziness in themselves. Well, the right kind of laziness, that is. You shouldn’t feel perfectly happy provisioning a server manually more than once. Take the time during that first provisioning exercise to script the things you discover along the way. Then you won’t have to remember them and repeat the same mis-steps again. (Well, unless you enjoy that sort of thing, of course.)
For example, here are a few provisioning scripts that I’ve come up with when I needed to set up development environments. These are all based on Ubuntu Linux and written in Bash. I don’t know if they’ll help you, but they work on my machine.
- Provision a Node dev environment
- Provision a Python dev environment
- Provision a COBOL dev environment
- Provision a Java dev environment
- Provision a Ruby dev environment
If your company is running RedHat Linux in production, you’ll probably want to adjust these scripts to run on CentOS or Fedora, so that your development environments will be reasonably close to the target environments. No big deal.
If you want to be even lazier, you can use a tool like Vagrant to simplify the configuration definitions for your VMs.
One more thing: Whatever scripts you write and whatever definition files you write for provisioning tools, keep them under version control along with each project. Make sure whatever is in version control for a given project is everything necessary to work on that project…code, tests, documentation, scripts…everything. This is rather important, I think.
One way of isolating your development environment is to run it in a container. Most of the tools you’ll read about when you search for information about containers are really orchestration tools intended to help us manage multiple containers, typically in a production environment. For local development purposes, you really don’t need that much functionality. There are a couple of practical containers for this purpose:
Develop in the cloud
These are Linux-based. Whether it’s practical for you to containerize your development environment depends on what technologies you need. To containerize a development environment for another OS, such as Windows, may not be worth the effort over just running a full-blown VM. For other platforms, it’s probably impossible to containerize a development environment.
This is a relatively new option, and it’s feasible for a limited set of technologies. The advantage over building a local development environment is that you can stand up a fresh environment for each project, guaranteeing you won’t have any components or configuration settings left over from previous work. Here are a couple of options:
Generate test environments on the fly as part of your CI build
Expect to see these environments improve, and expect to see more players in this market. Check which technologies and languages are supported so see whether one of these will be a fit for your needs. Because of the rapid pace of change, there’s no sense in listing what’s available as of the date of this article.
Once you have a script that spins up a VM or configures a container, it’s easy to add it to your CI build. The advantage is that your tests will run on a pristine environment, with no chance of false positives due to leftover configuration from previous versions of the application or from other applications that had previously shared the same static test environment, or because of test data modified in a previous test run.
Many people have scripts that they’ve hacked up to simplify their lives, but they may not be suitable for unattended execution. Your scripts (or the tools you use to interpret declarative configuration specifications) have to be able to run without issuing any prompts (such as prompting for an administrator password). They also need to be idempotent (that is, it won’t do any harm to run them multiple times, in case of restarts). Any runtime values that must be provided to the script have to be obtainable by the script as it runs, and not require any manual “tweaking” prior to each run.
The idea of “generating an environment” may sound infeasible for some stacks. Take the suggestion broadly. For a Linux environment, it’s pretty common to create a VM whenever you need one. For other environments, you may not be able to do exactly that, but there may be some steps you can take based on the general notion of creating an environment on the fly.
For example, a team working on a CICS application on an IBM mainframe can define and start a CICS environment any time by running it as a standard job. In the early 1980s, we used to do that routinely. As the 1980s dragged on (and continued through the 1990s and 2000s, in some organizations), the world of corporate IT became increasingly bureaucratized until this capability was taken out of developers’ hands.
Strangely, as of 2017 very few development teams have the option to run their own CICS environments for experimentation, development, and initial testing. I say “strangely” because so many other aspects of our working lives have improved dramatically, while that aspect seems to have moved in retrograde. We don’t have such problems working on the front end of our applications, but when we move to the back end we fall through a sort of time warp.
From a purely technical point of view, there’s nothing to stop a development team from doing this. It qualifies as “generating an environment,” in my view. You can’t run a CICS system “in the cloud” or “on a VM” (at least, not as of 2017), but you can apply “cloud thinking” to the challenge of managing your resources.
Similarly, you can apply “cloud thinking” to other resources in your environment, as well. Use your imagination and creativity. Isn’t that why you chose this field of work, after all?Generate production environments on the fly as part of your CD pipeline
This suggestion is pretty much the same as the previous one, except that it occurs later in the CI/CD pipeline. Once you have some form of automated deployment in place, you can extend that process to include automatically spinning up VMs or automatically reloading and provisioning hardware servers as part of the deployment process. At that point, “deployment” really means creating and provisioning the target environment, as opposed to moving code into an existing environment.
This approach solves a number of problems beyond simple configuration differences. For instance, if a hacker has introduced anything to the production environment, rebuilding that environment out of source that you control eliminates that malware. People are discovering there’s value in rebuilding production machines and VMs frequently even if there are no changes to “deploy,” for that reason as well as to avoid “configuration drift” that occurs when we apply changes over time to a long-running instance.
Many organizations run Windows servers in production, mainly to support third-party packages that require that OS. An issue with deploying to an existing Windows server is that many applications require an installer to be present on the target instance. Generally, information security people frown on having installers available on any production instance. (FWIW, I agree with them.)
If you create a Windows VM or provision a Windows server on the fly from controlled sources, then you don’t need the installer once the provisioning is complete. You won’t re-install an application; if a change is necessary, you’ll rebuild the entire instance. You can prepare the environment before it’s accessible in production, and then delete any installers that were used to provision it. So, this approach addresses more than just the works-on-my-machine problem.
When it comes to back end systems like zOS, you won’t be spinning up your own CICS regions and LPARs for production deployment. The “cloud thinking” in that case is to have two identical production environments. Deployment then becomes a matter of switching traffic between the two environments, rather than migrating code. This makes it easier to implement production releases without impacting customers. It also helps alleviate the works-on-my-machine problem, as testing late in the delivery cycle occurs on a real production environment (even if customers aren’t pointed to it yet).
The usual objection to this is the cost (that is, fees paid to IBM) to support twin environments. This objection is usually raised by people who have not fully analyzed the costs of all the delay and rework inherent in doing things the “old way.”Pitfall 3: Unpleasant surprises when code is merged
Problem: Different teams and individuals handle code check-out and check-in in various ways. Some check out code once and modify it throughout the course of a project, possibly over a period of weeks or months. Others commit small changes frequently, updating their local copy and committing changes many times per day. Most teams fall somewhere between those extremes.
Generally, the longer you keep code checked out and the more changes you make to it, the greater the chances of a collision when you merge. It’s also likely that you will have forgotten exactly why you made every little change, and so will the other people who have modified the same chunks of code. Merges can be a hassle.
During these merge events, all other value-add work stops. Everyone is trying to figure out how to merge the changes. Tempers flare. Everyone can claim, accurately, that the system works on their machine.
Solution: A simple way to avoid this sort of thing is to commit small changes frequently, run the test suite with everyone’s changes in place, and deal with minor collisions quickly before memory fades. It’s substantially less stressful.
The best part is you don’t need any special tooling to do this. It’s just a question of self-discipline. On the other hand, it only takes one individual who keeps code checked out for a long time to mess everyone else up. Be aware of that, and kindly help your colleagues establish good habits.Pitfall 4: Integration errors discovered late
Problem: This problem is similar to Pitfall 3, but one level of abstraction higher. Even if a team commits small changes frequently and runs a comprehensive suite of automated tests with every commit, they may experience significant issues integrating their code with other components of the solution, or interacting with other applications in context.
The code may work on my machine, as well as on my team’s integration test environment, but as soon as we take the next step forward, all hell breaks loose.
Solution: There are a couple of solutions to this problem. The first is static code analysis. It’s becoming the norm for a continuous integration pipeline to include static code analysis as part of every build. This occurs before the code is compiled. Static code analysis tools examine the source code as text, looking for patterns that are known to result in integration errors (among other things).
Static code analysis can detect structural problems in the code such as cyclic dependencies and high cyclomatic complexity, as well as other basic problems like dead code and violations of coding standards that tend to increase cruft in a codebase. It’s just the sort of cruft that causes merge hassles, too.
A related suggestion is to take any warning-level errors from static code analysis tools and from compilers as real errors. Accumulating warning-level errors is a great way to end up with mysterious, unexpected behaviors at runtime.
The second solution is to integrate components and run automated integration test suites frequently. Set up the CI pipeline so that when all unit-level checks pass, then integration-level checks are executed automatically. Let failures at that level break the build, just as you do with the unit-level checks.
With these two methods, you can detect integration errors as early as possible in the delivery pipeline. The earlier you detect a problem, the easier it is to fix.Pitfall 5: Deployments are nightmarish all-night marathons
Problem: Circa 2017 it’s still common to find organizations where people have “release parties” whenever they deploy code to production. Release parties are just like all-night frat parties, only without the fun.
The problem is that the first time applications are executed in a production-like environment is when they are executed in the real production environment. Many issues only become visible when the team tries to deploy to production.
Of course, there’s no time or budget allocated for that. People working in a rush may get the system up and running somehow, but often at the cost of regressions that pop up later in the form of production support issues.
And it’s all because at each stage of the delivery pipeline, the system “worked on my machine,” whether a developer’s laptop, a shared test environment configured differently from production, or some other unreliable environment.
Solution: The solution is to configure every environment throughout the delivery pipeline as close to production as possible. The following are general guidelines that you may need to modify depending on local circumstances.
If you have a staging environment, rather than twin production environments, it should be configured with all internal interfaces live and external interfaces stubbed, mocked, or virtualized. Even if this is as far as you take the idea, it will probably eliminate the need for release parties. But if you can, it’s good to continue upstream in the pipeline, to reduce unexpected delays in promoting code along.
Test environments between development and staging should be running the same version of the OS and libraries as production. They should be isolated at the appropriate boundary based on the scope of testing to be performed.
At the beginning of the pipeline, if it’s possible develop on the same OS and same general configuration as production. It’s likely you will not have as much memory or as many processors as in the production environment. The development environment also will not have any live interfaces; all dependencies external to the application will be faked.
At a minimum, match the OS and release level to production as closely as you can. For instance, if you’ll be deploying to Windows Server 2016, then use a Windows Server 2016 VM to run your quick CI build and unit test suite. Windows Server 2016 is based on NT 10, so do your development work on Windows 10 because it’s also based on NT 10. Similarly, if the production environment is Windows Server 2008 R2 (based on NT 6.1) then develop on Windows 7 (also based on NT 6.1). You won’t be able to eliminate every single configuration difference, but you will be able to avoid the majority of incompatibilities.
Follow the same rule of thumb for Linux targets and development systems. For instance, if you will deploy to RHEL 7.3 (kernel version 3.10.x), then run unit tests on the same OS if possible. Otherwise, look for (or build) a version of CentOS based on the same kernel version as your production RHEL (don’t assume). At a minimum, run unit tests on a Linux distro based on the same kernel version as the target production instance. Do your development on CentOS or a Fedora-based distro to minimize inconsistencies with RHEL.
If you’re using a dynamic infrastructure management approach that includes building OS instances from source, then this problem becomes much easier to control. You can build your development, test, and production environments from the same sources, assuring version consistency throughout the delivery pipeline. But the reality is that very few organizations are managing infrastructure in this way as of 2017. It’s more likely that you’ll configure and provision OS instances based on a published ISO, and then install packages from a private or public repo. You’ll have to pay close attention to versions.
If you’re doing development work on your own laptop or desktop, and you’re using a cross-platform language (Ruby, Python, Java, etc.), you might think it doesn’t matter which OS you use. You might have a nice development stack on Windows or OSX (or whatever) that you’re comfortable with. Even so, it’s a good idea to spin up a local VM running an OS that’s closer to the production environment, just to avoid unexpected surprises.
For embedded development where the development processor is different from the target processor, include a compile step in your low-level TDD cycle with the compiler options set for the target platform. This can expose errors that don’t occur when you compile for the development platform. Sometimes the same version of the same library will exhibit different behaviors when executed on different processors.
Another suggestion for embedded development is to constrain your development environment to have the same memory limits and other resource constraints as the target platform. You can catch certain types of errors early by doing this.
For some of the older back end platforms, it’s possible to do development and unit testing off-platform for convenience. Fairly early in the delivery pipeline, you’ll want to upload your source to an environment on the target platform and buld/test there.
For instance, for a C++ application on, say, HP NonStop, it’s convenient to do TDD on whatever local environment you like (assuming that’s feasible for the type of application), using any compiler and a unit testing framework like CppUnit.
Similarly, it’s convenient to do COBOL development and unit testing on a Linux instance using GnuCOBOL; much faster and easier than using OEDIT on-platform for fine-grained TDD.
But in these cases the target execution environment is very different from the development environment. You’ll want to exercise the code on-platform early in the delivery pipeline to eliminate works-on-my-machine surprises.Summary
The author’s observation is that the works-on-my-machine problem is one of the leading causes of developer stress and lost time. The author further observes that the main cause of the works-on-my-machine problem is differences in configuration across development, test, and production environments.
The basic advice is to avoid configuration differences to the extent possible. Take pains to ensure all environments are as similar to production as is practical. Pay attention to OS kernel versions, library versions, API versions, compiler versions, and the versions of any home-grown utilities and libraries. When differences can’t be avoided, then make note of them and treat them as risks. Wrap them in test cases to provide early warning of any issues.
The second suggestion is to automate as much testing as possible at different levels of abstraction, merge code frequently, build the application frequently, run the automated test suites frequently, deploy frequently, and (where feasible) build the execution environment frequently. This will help you detect problems early, while the most recent changes are still fresh in your mind, and while the issues are still minor.
Let’s fix the world so that the next generation of software developers doesn’t understand the phrase, “Works on my machine.”
If you’re familiar with our model of organizational transformation, then you know we’re fond of the metaphor of taking a journey in a specific direction, possibly (but not necessarily) ending up at the farthest imaginable point of that journey. We think of the journey as a series of expeditions, each of which aims to fulfill a portion of a vision and plan.
The metaphor is both spatial and temporal. When you picture a group of adventurers embarking on an expedition, the visualization is mainly spatial: They are marching across territory toward a goal that lies on the horizon. The horizon moves ahead of them as they march. Their concept of “the possible” depends on what they are able to see or imagine from their current position and, as they progress, they are able to see and imagine more and more possibilities.
A way forward based on Lean principles involves conducting a series of experiments. Learnings from each experiment inform the design of the next experiment. Always, there’s a goal in mind. Over time, outcomes meet needs more and more effectively. Improvement over time suggests a temporal angle on the “journey” metaphor.Step-by-step Improvement Over Time
It’s easy to find examples of similar journeys that suggest change over time. One that I find relevant, particularly in larger, well-established IT organizations, is the tale of the Eddystone Lighthouse. You can read about it on Wikipedia. There are also many videos on YouTube about the lighthouse, and it has been featured on the Science Channel program, “Impossible Engineering.”
I see this as an example of a temporal journey of improvement because of the progression of engineering advancements reflected in the series of lighthouses built on the site from 1699 to the present. Similarly, improvement in organizational performance often involves building a series of solutions that incrementally move closer to strategic goals.
…it turns out to be faster, cheaper, and better to find the way forward through a series of experiments than to design the ultimate solution in advance.Lighthouses and expeditions
It’s easy to get tangled up in a sea of metaphors. Even referring to the situation as a “sea” could be one metaphor too many, were it not for the fact we’re also talking about lighthouses.
This lighthouse at Eddystone was the the first to be built in the middle of the sea and was erected on a rock that which was submerged 20 hours a day. Over the course of history, it was rebuilt four different times, each quite different from its predecessors. Engineers had learned things and materials science had progressed, enabling each successive lighthouse to be better than those that had stood before.
The same pattern occurs in organizational transformation. A Scrum team on a journey from Basecamp 2 to Basecamp 3 will use the Scrum events and artifacts quite differently than a team progressing from zero to Basecamp 1. The more mature team will use Scrum in a lighter-weight fashion than the novice team. For example, they have learned how to level out their work by crafting User Stories of roughly the same size. They’re on their way to dispensing with story-level sizing. Meanwhile, the novice team may still be struggling with separating the notion of size from the notion of time, and they may have difficulty visualizing the possibility that story-level estimation is a crutch that can be made unnecessary by mastering other practices.
Also, the organization surrounding the two teams will be at different levels of proficiency with lightweight methods. You’ll often hear us speak of clarity around the backlog, or words to that effect. An expedition approaching Basecamp 3 will have learned skills in identifying worthwhile initiatives, prioritizing those initiatives, and refining backlogs that are sensible and actionable by program and delivery teams.
It’s more feasible for the delivery teams in the Basecamp 3 expedition to function in a lightweight way than for the novice teams, which are supported by organizations still early on the learning curve, still struggling to reach Basecamp 1. They may not receive actionable backlog items on a consistent basis. Everyone is trying to get a handle on quite a few unfamiliar concepts and methods. Even an advanced team would have challenges in maintaining flow and delivering value without appropriate support from the program and portfolio teams.
The two organizations just can’t build the same kinds of lighthouses. They have to advance one step at a time.Why not just determine the final solution through research?
Sometimes, people are uncomfortable with this approach. They would prefer it if we could design the “final” solution in advance and then simply implement it. That way, they would have only one sizeable capital investment to make, and they could check the “improvement” box. All done!An aside: This mentality may be at the root of the numerous attempts to “implement” a framework, such as SAFe or LeSS, and lock it in as the “final state.” Although the proponents of such frameworks are consistent in saying they are meant to be a starting point for ongoing improvement, people tend to try and “implement” a framework as if it were a “solution.” Are they hoping for a magic bullet?
The “implementation” approach may be feasible for relatively small enterprises that have fairly narrowly-bounded goals. When a larger enterprise, that has longstanding habits and entrenched processes, sets a goal to “be more effective” or “be more competitive” or “improve the customer experience” or “be able to pivot quickly,” it’s harder to visualize a Golden End State in a vacuum. Such goals are real and meaningful, but difficult to quantify, and the path to achieving them in the face of an ever-changing competitive landscape is not easy to discern.
Perhaps counterintuitively, it turns out to be faster, cheaper, and better to find the way forward through a series of experiments than to design the ultimate solution in advance. It takes less time and less money to build something, learn from it, discard it, and build another (repeating the sequence several times) than it does to learn all the possibilities and pitfalls of numerous options in advance through “research.” This has been a practical reality for a long time, far longer than the buzzword agile has been in use.That pesky moving horizon
Now you may be asking, “If you’ve seen this pattern before and you know what to expect, why don’t you just tell us what we need to do to be at Basecamp 5? Let’s start Monday!”
That would be great. Unfortunately, things don’t seem to work that way. Combining the experiences of the LeadingAgile consultants, we’ve seen that approach many times in many kinds of organizations. We’ve tried starting with culture change; with procedural change; with technical practices. We’ve tried driving change top-down; bottom-up; by consensus or invitation; by management dictate. What’s common in those cases is that when people are told what to do, the desired change in mentality doesn’t happen. When people are invited to change their thinking, they simply don’t know how. People remain in the mindset of following orders. The only difference is they’re following different orders than before. The changes don’t penetrate deeply, and they aren’t sticky. People become frustrated with the results, and abandon the effort to change.
It seems to be important that people deeply understand the why of the change. To become aware of some of the possibilities is a good first step, but it isn’t sufficient to create meaningful and lasting improvement. People need to be able to get their heads around the potential benefits and risks of any given change. For that to be possible, they need guidance beyond the limits of their comfort zone…but not too far beyond those limits. Very radical change, introduced suddenly, will only lead to fear and frustration. The only way to reach Basecamp 5 is to walk there, step by step.
Remember the bit about the horizon moving ahead of you? It does. At the outset of the journey, you don’t have enough information to visualize possible end states. There may even be so much organizational “fog” that you can’t really tell which way to turn. The best you can do is set a direction that seems to be consistent with your goals. Then you have to take a deep breath and start walking, pausing to check your compass frequently and adjusting course accordingly.
Maybe the first few lighthouses you build will burn down or be swept away by the sea (or be destroyed by Napoleon’s army, as the case may be), but eventually you’ll build one that nothing and no one can tear down. The key is to be willing to try things that don’t turn out exactly the way you hoped, and learn from those experiences. Just keep going. As long as you have a good compass, you won’t get lost.
I believe the number one reason for failure or waste is a lack of clarity or understanding. If you get clarity on something, it gives you the freedom to decide if you want to do it or not. If something is ambiguous, you may agree in principle but you don’t know what you’re really getting yourself into.OKRs
Firstly, what are your Objectives and Key Results (OKR)? How do you set and communicate goals and results in your organization? Because you want people to move together in the right direction, you need to get clarity.KPIs
What are your Key Performance Indicators (KPI)? How do you want to measure value that demonstrates how effectively your company is achieving key business objectives? Because you want your organization to evaluate its success at reaching targets, you need to get clarity.Structure
What does the team design or structure of the organization look like on portfolio, program, product, and service layers? We need a shared understanding of which individuals or teams are responsible for what.Governance
What does the governance of the organization look like? How do we manage our budget, dependencies, risks, or quality? What are the inputs, outputs, and artifacts?Metrics and Tools
Because we want to manage our system of delivery, what are necessary metrics and tools of the organization?Get Clarity
Remember, if you expect others to commit to something, regardless if it’s a process or a deliverable, we need a shared understanding.
Because organizations rely on an ever increasing number of technologies, we often wind up with an increased number of specialists on staff. When departments over-specialize, they develop silos and increase the number of organizational dependencies. Everything begins to require multiple handoff and things slow down. To counter silos and increase the flow of value moving through the system of delivery, we often encourage cross-functional teams with more “T-shaped” generalized-specialists.
Now, I’m currently reading The DevOps Handbook: How to create world-class agility, reliability, and security in technology organizations . For anyone who has read (or currently reading) the Phoenix Project, read this book next. In addition to this, my colleague Jim Hayden recently pointed out a passage that got my attention. On page 86, there is a table that compares I-shaped, T-shaped, and E-shaped staff. That table is based on a 2012 blog post by Sarah DaVanzo. It inspired me to make a few changes to the table below and write this blog post.
The vertical stroke of the “I” is a depth of skill that allows someone to contribute to the creative process. They can be from any number of different fields to include: a developer, an architect, a tester, or an analyst. In organizations still utilizing a Waterfall model for application development, one can find specialists in functional phased groups. Having too many specialists can result in an increase of bottlenecks and frequency of ridged handoffs. In short, they create dependencies. These people are insensitive to downstream impacts and unwilling to help beyond their primary job. You may literally hear them say,
That’s not my job.T-shaped (Generalized Specialist)
The term “T-shaped person” was coined by IDEO Chief Executive Tim Brown. When recruiting, IDEO assessed candidates based on both their breadth and depth of experience. In a 2010 interview with Chief Executive Magazine, Brown explained what a T-shaped person is:
The vertical stroke of the “T” is a depth of skill that allows them to contribute to the creative process. That can be from any number of different fields: an industrial designer, an architect, a social scientist, a business specialist or a mechanical engineer.
The horizontal stroke of the “T” is the disposition for collaboration across disciplines. It is composed of two things. First, empathy. It’s important because it allows people to imagine the problem from another perspective – to stand in somebody else’s shoes. Second, they tend to get very enthusiastic about other people’s disciplines, to the point that they may actually start to practice them. T-shaped people have both depth and breadth in their skills.
Since then, in the Agile community, the T-shaped staff member has become synonymous with a generalized specialist. You may hear someone is a developer by trade but is willing to roll up their sleeves when needed, to help test, clarify user story acceptance criteria, or fulfill some other team obligation. This will help remove bottlenecks and lessen the frequency of ridged handoffs. These people are sensitive to downstream impacts and willing to help beyond their primary job.E-shaped (NextGen Specialist)
I note the term “E-shaped” was first referenced in the 2010 DaVanzo post. From there, I’m going to take some liberty to redefine it as the next generation (NextGen) of specialist for an Agile team.
The vertical stroke of the “E” is expertise in a few areas, to allow the specialist to contribute to the team. That can be from any number of different fields, just as we noted for the vertical stroke of the T-shaped people.
The first horizontal stroke of the “E” is experience. Not only do we want people with expertise in a few areas, we also want experience across several areas.
The second horizontal stroke of the “E” is execution. We need a specialist with proven execution skills.
The last horizontal stroke of the “E” is exploration. These people should always be looking of ways to improve their craft or learn new skills.
If you can locate and employ these next generation specialists, your team will have almost limitless potential.
 Kim, G., Willis, J., & Debois, P. (2016). The Devops Handbook: How to create world-class agility, reliability, and security in technology organizations. United States: IT Revolution Press.
When Scrum was first defined, it addressed a number of issues that plagued IT organizations of the 1980s. Functional silos and their key side-effect, cross-team dependencies. Lack of clear communication. Extended lead times. Poor alignment of solutions with needs. High defect rates. More.
To this day, Scrum continues to be a valuable tool for teams and organizations that are operating in a traditional way, or that have achieved a certain level of basic proficiency with lightweight methods based on Lean and Agile thinking. As with any tool, Scrum is useful in situations where its characteristics are helpful, and when it’s applied mindfully and appropriately.
Scrum has helped, and continues to help many organizations get started on their Lean/Agile journey. It’s still an appropriate choice in many situations. There’s nothing wrong with it. At LeadingAgile, we use, recommend, teach, and coach Scrum quite a lot. It doesn’t fit every situation, but where it does fit, it fits very well indeed.The Scrum cult
Scrum has been phenomenally successful. It may be the single most widely-used method for delivering software solutions, with the possible exception of the venerable and popular Random Method, and the widely-used Random software engineering technique, Copy-and-Paste-from-StackOverflow. But Scrum’s success has led to a curious phenomenon: A sort of Scrum cult has emerged. Scrum is All Things Good. Scrum is The Answer. Scrum is the End Game. There is nothing more beyond Scrum.
When you ask a Scrum cultist where a team or organization might go after Scrum, they look at you as if they can’t process the question. It’s as if you asked a Christian where you go after you’ve died, gone to heaven, and died in heaven. They look at you quizzically, because in their worldview there’s nothing beyond heaven; it’s the “end state.” You don’t “die in heaven.” They can’t process the question. Scrum cultists have the same mentality regarding Scrum. There’s nothing beyond Scrum; it’s the “end state.”Continual improvement
But to a person who has internalized the idea of continual improvement, there is no end state. Continual improvement is like Jonathan Livingston Seagull, or maybe a really hard video game, in which conquering one level leads to another level. Or you could say it’s like attending school. When we graduate pre-school, we become beginners in elementary school. When we graduate elementary school, we become beginners in middle school. When we graduate middle school, we become beginners in high school. When we graduate high school, we become beginners at university.
When we graduate university, we become beginners in a Masters program or in the work force. As we progress through our careers, we reach numerous milestones in our professional growth, but we never reach a permanent end state. We become beginners again and again, at different levels.One more metaphor
I sometimes liken Scrum to Forrest Gump’s braces. In the movie, Forrest Gump, the title character wears braces on his legs as a child. He needs the braces to stand and walk. Then the day comes when he’s ready to run. At that stage, the braces are a hindrance. In the film, the title character starts to run, and the braces begin to break apart. Piece by piece, they fall away, leaving his legs free to carry him smoothly.
As an Expedition progresses through the LeadingAgile Basecamps on its Agile journey, it requires guidance and structure appropriate to its level of proficiency with lightweight methods; its ability to apply Lean and Agile thinking in practice. Teams in the Expedition that are burning down a backlog of planned features can benefit greatly from Scum when they are in the early stages of learning Agile. You could say that Scrum helps these teams learn to stand and walk. It adds value at least through Basecamp 3, and possibly further.
What we really want to see is Expeditions, and whole organizations, start to run. When they reach the stage that they’re ready to run, Scrum can be the same kind of hindrance as Forrest’s braces. Scrum practices can fall away naturally as teams learn to achieve the same goals with less ceremony. If we don’t allow the braces to fall away, we’re impeding the teams’ ability to progress.
Scrum practices can fall away naturally as teams learn to achieve the same goals with less ceremonyCult? What cult? I don’t see no cult!
You may disagree that there’s any such thing as a Scrum cult. Disagreement is okay. But if the observation is valid, then what might have caused the emergence of a cult around Scrum?
I’ll make the personal observation that the vast majority of Scrum (and Agile) coaches have never seen or experienced what can happen once an organization truly internalizes Lean and Agile values and moves beyond the novice level with these approaches. Most coaches introduce novice practitioners to the basics of Lean and Agile (and Scrum), and then move on to another client where they introduce the basics again.
And again and again and again.
The best organizations and the best teams they ever see are those that have managed to achieve a reasonably good level of proficiency with basic, by-the-book Scrum (or some sort of Scrum-like hybrid).
But that’s not the “end state.” There’s more.Value and overhead
A key concept in the Lean school of thought is customer-defined value. Time spent in activities that directly add customer-defined value to a product is deemed “value add time.” All other time is deemed “non-value add time.”
The distinction is often misunderstood, as it differs from conventional thinking about value. Conventionally, we consider anything that helps us deliver value to customers to be useful and possibly necessary. Things that are useful and/or necessary to get the job done surely are valuable, right? Sure, in the casual sense of the English word, “valuable.”
Consider a financial institution that offers services to customers. All services must comply with government regulations designed to protect consumers and the national economy from errors and unethical actions that might do harm. Conventional thinking tells us the things we do to assure compliance are valuable. We may well invest additional time and effort in compliance activities just to be really sure we’re doing it well.
When we look at the same situation through a Lean lens, we perceive that customers are willing to pay for certain services. They have a baseline expectation that their transactions will be accurate, ethical, and safe, but they don’t think about those things as part of what they’re paying for. They only intend to pay for the service they want. The time we spend in maximizing the direct value of those services is value add time, and the time we spend to support necessary overhead items such as compliance is non-value add time. We may well invest some effort in seeking ways to minimize compliance overhead.
Similarly, customers do not wish to pay us to fix our own bugs. If we create a bug, that’s our problem, not our customers’. Therefore, from a Lean perspective, bug-fixing, remediating technical debt, and production support—even testing—are non-value add activities. A Lean thinker will seeks ways to minimize the time spent on such activities. A conventional thinker might only think about improving how they do these things, rather than looking for ways to eliminate the need for them.
No doubt you can see how this minor shift in perspective helps us identify potential areas of improvement in our delivery processes. Every minute spent on non-value add activities is a minute lost to value add activities. But what does this have to do with Scrum, or with the supposed “cult” of Scrum?From walking to running
As mentioned above, Scrum was created in an era when certain organizational and procedural problems were endemic to large-scale IT organizations. It was designed to address several of those problems directly. Its three roles—Product Owner, Scrum Master, and Development Team—represented a sharp change from the then-common manager-driven hierarchical organizational structure and “matrix” assignment of so-called “resources” (meaning humans) to multiple projects concurrently.
Many IT organizations needed something like Scrum to help them stand and walk. The Product Owner mitigated the generally poor communication between business stakeholders and the IT organization. The Scrum Master mitigated the generally poor understanding of effective delivery processes on the part of IT staff. The Delivery Team brought together individual specialists from various functional silos to create a cross-functional team, significantly reducing communication delay and misunderstandings.
But that was the 1980s, hanging over into the 1990s. There are still organizations operating as they did in the 1980s, but the industry as a whole has long since moved on. Does Scrum help an organization in which communication between business stakeholders and the IT organization is already good? How about an organization in which the staff understands and uses effective delivery methods? How about an organization in which staff routinely collaborate across individual specialties and are accustomed to transparency? How about an organization that already delivers small batches incrementally and on a short time scale?
In other words…what about an organization that has learned how to stand and walk, and is ready to run?
From a Lean perspective, every role, every artifact, and every event defined in Scrum is overhead. Scrum itself is not what customers buy. It isn’t what they want to buy. It’s a way of delivering what they want, but it isn’t The Thing they want. A conventional thinker will think of ways to “do Scrum better.” And maybe that’s exactly what they should be doing, based on where they are in the journey at the moment. A Lean thinker will seek ways to minimize the overhead of using Scrum, with the eventual goal of making Scrum unnecessary. That’s quite a different goal.The rub
To outgrow the need for Scrum is a fine goal, but you have to earn it. To earn it, you have to understand the substance of what Scrum is helping you achieve; merely following the prescribed practices isn’t sufficient for that. A novice delivery team can’t arbitrarily discard Scrum, just because they recognize it as overhead. Teams must learn to achieve the same goals and deliver the same value without the overhead of Scrum. Then the braces can fall away.
Scrum cultists will chafe at the word “overhead” here, but the reality is that there’s always some form of overhead in any process. Lean thinkers prioritize “eliminating waste from the process” third, behind “focus on value” and “maintain continuous flow.” They know some overhead is inevitable, necessary, and ultimately all to the good. The trick is to minimize non-value add time while still fulfilling all necessary requirements.
In their book, Lean Thinking, Womack and Jones distinguish between two types of non-value add activity, or muda. (That’s Japanese for “non-value add activity.”) Type 1 muda comprises activities that don’t help in any way and are only performed out of habit. These activities can simply be stopped, with no downside impact.
Type 1 muda could be, for instance, preparing three different status reports about the same tasks in three different formats for three different managers, or entering the same information about hours worked into four different time tracking systems. (But those examples are absurd, of course. Who would do that?)
Type 2 muda comprises activities that are necessary to get the job done, but that don’t directly add customer-defined value to a product. The goal here is to minimize the overhead involved in carrying out these activities. This could include, for instance, governance review procedures to ensure information security standards were followed in developing an application, or functionality built into an application to track data for auditors. Bake the security standards into your development process, and you can dispense with the review step in the delivery pipeline. Build logging into your reference architectures, and you can dispense with any extra effort to satisfy auditors.
The process of the braces falling away piece by piece naturally involves the organization and the teams within it learning to satisfy all the ancillary requirements surrounding the product with a minimum of effort, time, and cost. As these requirements become ingrained in the delivery process, overhead activities to double-check them become less necessary.Full circle
As an example, let’s home in on one of the factors that Scrum addresses: Predictable delivery. Business stakeholders in the 1980s and 1990s were constantly asking IT organizations “How long will it take to deliver X?” IT professionals came up with various ways to estimate the time they would need to deliver X. Some are formal and some informal, and may be based on experience, calculation, statistics, heuristics, empiricism, or a combination.
Customers won’t place an order for an estimate. They may want to know how long it will take you to deliver a solution, but they don’t expect to pay you just for the estimate. If customers aren’t intentionally buying estimates, then the time you spend preparing estimates is muda.
During the years when estimation was regarded as a core competency of software development rather than as an overhead activity, delivery performance continued to be unpredictable. Sure, some teams boasted that their estimates were always within 5% of actuals, but this was almost always gamed; they padded the estimates enough that they could make their numbers look the way management wanted the numbers to look.
Scrum as such doesn’t define an estimation method, but teams tend to use certain methods more than others with Scrum. A novice Scrum team may estimate User Stories in terms of clock time. This doesn’t do much to improve predictability, but it does help the team get into the habit of decomposing work into small pieces and thinking about what’s involved in delivering the pieces.
As they gain proficiency with Scrum, the team may estimate in terms of ideal time, applying a load factor to their planned capacity to account for interruptions such as meetings and production support issues. Usually, they begin to see some improvement in predictability.
As they progress, the team begins to understand what their Scrum coach meant all these past weeks or months when she told them to stop thinking about time and to think about relative size instead. They shift from time-based estimation to relative sizing of User Stories based on a scale of arbitrary points.
Initially they may peg points to time (e.g., “One point is half a day”), but sooner or later they drop that. Now they see significant improvement in predictability, because they are planning their work based on their own demonstrated delivery performance in the recent past. This is empiricism, consistent with the Scrum approach.
Throughout these early stages, the discussions surrounding estimation serve another purpose: They help build shared understanding about the problem space, the solution space, design considerations, and acceptance criteria. These are among the things a team must learn to do in other ways before they can dispense with story-level estimation.
Continuing to mature in Agile thinking and practice, the team gradually learns to decompose and structure User Stories into reasonably same-sized chunks. Eventually they discover most of their stories seem to be of the same size. They stop using relative points and just count stories instead. This reduces their planning overhead without sacrificing predictability. (They couldn’t have dispensed with estimation in the beginning; at that time, they didn’t know how to achieve predictable delivery without it.)
At this stage, everyone can see approximately how long each User Story takes to deliver. The team has gone full circle, and can now answer the question “How long will it take to deliver X?” directly, in terms of clock time, just the way stakeholders need it to be answered.
A piece of their braces—story sizing or estimation—can fall away naturally. In Lean terms, they have reduced the planning overhead necessary to deliver customer-defined value. Similarly, teams can learn to deliver effectively without other pieces of the braces, too. It may not be intuitively obvious how to achieve this, and that’s why it’s helpful to work with guides who have been there and done that.
Is it done, is it done done, or is it done done done?
I bet you’ve asked that question before, if you are in the business of application development. When asking the questions, it is important to note who you are and your level in the organization. Delivery teams, program teams, and portfolio teams define done differently. For certain, we need is a clear definition of done at each level of the organization.Definition of Done
The definition of done (DoD) is when all conditions (acceptance criteria) that a software product must satisfy are met, to be accepted by a user, customer, team, or consuming system. We must meet the definition of done to ensure quality. It lowers rework, by preventing user stories not meeting the definition from being promoted to higher level environments. It will prevent features not meeting the definition from being delivered to the customer or user.User Stories
The most common use of Definition of Done is on the delivery team level. Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the done user story will contributed to the team velocity. Meet all of the defined criteria or the user story is not done.
The below examples might be included in the User Story DoD:
- Unit tests passed
- Code reviewed
- Acceptance criteria met
- Functional Tests passed
- Non-Functional requirements met
- Product Owner accepts the User Story
Done on this level may mean it qualifies to add to a release. Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity. Meet all of the defined criteria or the feature is not done.
The below examples might be included in the Feature DoD:
- Acceptance criteria met
- Integrated into a clean build
- Promoted to higher level environment
- Automated regression tests pass
- Feature level functional tests passed
- Non-Functional requirements met
- Meets compliance requirements
- Functionality documented in necessary user user documentation
Done on this level may refer to a organizational strategic priority, portfolio plan item, or some other collection of features that satisfied a market need. Not all user stories or features need to be completed. Rather, the epic may be sufficient to satisfy the need. Once accepted, the done epic will contribute to throughput calculations to see if the supply is in balance with demand.
The below examples might be included in the Epic DoD:
- Non-Functional requirements met
- End-to-end integration completed
- Regression tests pass
- Promoted to production environment
- Meets defined market expectations
Just as the definition of ready is super important, so is the definition of done. Never start work on something until you have agreed on the definition. Be consistent. Be clear. Have a shared understanding.
The legendary swordsman, Miyamoto Musashi, understood the Lean/Agile mindset perfectly 400 years ago.
Here is an excerpt from Musashi’s Book of Five Rings. Two translations are given, as each brings out different nuances of the original text.
Translation by Victor Harris. This translation is commonly available as a free download from many online sources, most of which do not credit the translator.The gaze should be large and broad. This is the twofold gaze “Perception and Sight”. Perception is strong and sight weak. In strategy it is important to see distant things as if they were close and to take a distanced view of close things. It is important in strategy to know the enemy’s sword and not to be distracted by insignificant movements of his sword.
It is necessary in strategy to be able to look to both sides without moving the eyeballs. You cannot master this ability quickly. Learn what is written here; use this gaze in everyday life and do not vary it whatever happens.
Translation by Hidy Ochiai. I find this translation to be clearer, although in this case the translator does not explain the meaning of kan and ken (perception vs. sight). It’s published in the book, A Way to Victory: The Annotated Book of Five Rings.Your eyes should be able to focus on a large and wide area. There are two kinds of seeing: kan and ken, the former being the most important and the latter less essential. In martial strategy it is crucial that you be able to keenly see objects at a great distance and that objects in close proximity be viewed with a broader perspective. In a combat situation, you must see your opponent’s sword in the context of his strategy as a whole rather than observing each physical movement.
It is important to be able to see on both sides of yourself without moving your eyes. You will not be able to do this suddenly in an emergency situation. You must try to cultivate this method of seeing in everyday life and maintain the same type of eye focus at all times.
The spirit of this advice is consistent with the saying, “Think globally and act locally.” We should apply craftsmanship and precision to each little thing we do, but without losing sight of the larger context in which the thing exists. This may be harder to do than it sounds. Most people I meet tend to be big picture thinkers or detail-oriented “do-ers,” and few are comfortable with both perspectives simultaneously.
In Ochiai’s analysis of Musashi, he notes:Ordinarily one imagines that one’s mind-set when having a cup of tea is different from one’s mind-set in combat. Not according to Musashi. He feels that when one trains and disciplines the self physically and mentally according to the Way, the mind becomes calm and stable at all times, not preoccupied with any preconception or prejudice. This state of mind, which is attained after serious and hard training, Musashi calls heijo-shin. It is not the mental attitude of an ordinary person but of one who has gone through extraordinary training and self-discipline. The everyday mind of an ordinary person is not called heijo-shin, for it is not based on the true inner strength that can be attained only through a hard and authentic training.
I see many connections here. Connections with behaviors that I observe in the field. Connections with LeadingAgile’s pragmatic approach to organizational transformation. Connections to the mountain-climbing or “expedition” metaphor for driving organizational improvement.
The common element in these connections is expressed nicely by Musashi’s description of the warrior’s gaze. It comes down to a holistic perception of the small and the large, the near and the far, the immediate and the deferred, and the ability to maintain consistent focus on what is significant on all those axes.
Behaviors I observe in the field suggest this mindset is not so easy to cultivate. Tell-tale questions include:
- “Whose job is it to refine the backlog?”
- “As we combine technical job functions, who will test my code?”
- “Why should I consider security issues in my design if they aren’t explicitly mentioned in the User Story?”
- “How can we convince business stakeholders to give us permission to refactor our code?”
- “If we’re tracking delivery performance by team, how do we assess individual performance?”
Questions such as these suggest the person sees but does not perceive; they see rules, and do not perceive meaning. They have not cultivated heijo-shin.
In all these cases, and countless others, people are considering one specific job-related task in isolation from its larger context, and they are hoping to find a recipe to dictate what they must do in every situation that may arise. The “task” may be of relatively large scope—something the CTO does, or something a Portfolio-level team does—or of relatively small scope—something an individual programmer or tester does—but there is always a single, overarching organizational context, and it is within that context that people make judgments about what to do from one minute to the next throughout the day. It isn’t a question of rules, although you might benefit from a few rules initially to help you find the path forward.
Such questions would not occur to a person who had cultivated heijo-shin. They would perceive the whole and do the right thing in context naturally, without strain. But cultivating heijo-shin is a challenge that requires mindful practice. Musashi is clear on this point: Reading isn’t enough; you must apply the ideas. Whatever you practice every day is what you will do when the heat is on. Therefore, it’s important to practice the right things. How does one know what to practice? With guidance and a compass, you can find the right path.
LeadingAgile’s approach takes into account three levels of abstraction in the organization, which we call Portfolio, Program, and Delivery Team. Each has its own broad set of responsibilities and scope of work, but all are part of a single cohesive whole. One can view this as an example of Musashi’s notion of perceiving the near and the far in a spatial sense. What we do at the Delivery Team level is part of what we are doing at the Program and Portfolio levels. What we do at the Portfolio or Program level must be done in a way that doesn’t impede Delivery Teams. Each task must be done with high quality but does not exist in isolation.
The LeadingAgile roadmap, which is based on the expedition metaphor, comprises five Basecamps. These represent milestones of improvement. One can view this as an example of Musashi’s notion of perceiving the near and the far in a temporal sense. What we do on the journey from Basecamp 1 to Basecamp 2 will set us up for reaching Basecamp 3 in the future, and Basecamp 4 after that. Each Basecamp is a milestone but not an end state. The real end state is that people no longer think in terms of an “end state” at all, and instead they practice continual improvement as a habit.
I recently spoke at a corporate community of practice event. My session presented a useful model to identify indicators within a system to predict its failure. First, we started by applying the model to everyday systems everyone could relate to. Next, I asked the attendees to map a system of their own. As I walked them through my model step by step, I used Scrum as my example system. Upon completion of the worksheet (see my completed sheet below), attendees were able to see if there were any “gaps” in their systems. The gaps provided an indication that a respective system was at risk of failure.
To clarify, on a delivery team level, I see the Scrum Framework as a solid method for managing product development. But what about Scrum in the context of the entire delivery organization? Using both The Three Things You Need To Know To Transform Any Sized Organization and my model, I look at Scrum in a broader context. With that, I note 5 major gaps.
What are the 5 gaps in Scrum?
My model will segment any system into 5 areas: Clarity, Commitment, Ritual, Progress, and Habit. The gaps that I will note below are those things not mentioned in the Scrum Guide.Gap 1: Clarity
What does the structure of the organization look like (Portfolio, Program, Product) above the Scrum Team? We need a shared understanding. What does the governance of the organization look like (Budget, Dependencies, Risks, Quality,…) above the Scrum Team? What are necessary metrics and tools of the organization above the Scrum Team? Some organizations are very large and heavily distributed. How will you measure the health of the entire delivery system?Gap 2: Commitment
In Mike‘s 3-things talk, he calls this accountability. Given the broad applicability of my model, I prefer to call it commitment. Commitment can be any resource. So, what money and time may be required for Scrum training of all leadership and Scrum teams within an enterprise? What money and time may be required for procurement, installation and training of tooling used to manage and report on the health of the delivery system? Lastly, we need agreement from the Leadership team to follow the Scrum Framework (or more particularly respect that the Scrum team is following it).Gap 3: Progress
As I noted in my post on Productivity Patterns, if you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system. Those who are funding the efforts (those outside the Scrum team) need to know progress is being made in a way that is important to them. What is the Time to Value? Is the Scrum team predictable on a release level (Release Burndown/Burnup chart)? Are we even building the right things? (Product Fit) Are we building things right? (Quality)Gap 4: Rituals
Rituals can be event or meetings, as part of your system of delivery. First, let’s start with product vision. Scrum teams have a horizon of a few weeks (the sprint). Vision is viewed or realized in months, quarters, or years. Read the Scrum Guide and you won’t see Vision mentioned once. Also absent from the Scrum Guide is the notion of portfolio or release planning. Unless you have a delivery capability that allows you to release at the end of every sprint, I can’t champion release planning enough. In addition to that, good portfolio planning ensures we have a balanced system of delivery and ensures we have capacity to make commitments against a roadmap.Gap 5: Habit
Given the rituals I outlined above, you should make it a habit to have periodic Vision Reviews, regularly scheduled Portfolio Planning/Reviews, and ensure you’re consistently doing your Release Planning.Conclusion
I’m not suggesting you abandon Scrum. But after you look at the highlighted gaps I listed above, in a system of delivery larger than a single Scrum team, you should consider more than what is in the Scrum Guide.
I once used a hammer and it didn’t work. Therefore, people should never use hammers.
If you find that reasoning satisfactory, then you may also appreciate the following statements:
- We tried pair programming and it didn’t work.
- We tried test-driven development and it didn’t work.
- We tried Scrum and it didn’t work.
- We tried User Stories and they didn’t work.
- We tried Personas and they didn’t work.
- We tried Specification by Example and it didn’t work.
- We tried continuous delivery and it didn’t work.
- We tried baseball and it didn’t work.
There is a notion of logical validity. An argument may be logically valid even it if is untrue or unprovable. Validity is a question of structure. The following structure and example are taken from the Rational Wiki page about logical validity.
- If X then Y
- Therefore, Y
And the example:
- If there is creation there must be a creator.
- There is creation.
- Therefore, there is a creator.
So, is there a creator? Maybe. We can’t tell just by looking at the sample argument. We can tell that the argument is structurally valid.
Logical validity is prerequisite for an argument to be considered logically sound. To be sound, an argument must be valid; but a valid argument is not necessarily sound.
With that background, what do you think of the opening assertion of this post? “I once used a hammer and it didn’t work. Therefore, people should never use hammers.”
I think the argument is logically valid:
- If hammers don’t work, then people shouldn’t use them.
- Hammers don’t work.
- Therefore, people shouldn’t use them.
But I question the logical soundness of the argument. The part of the statement that stands out for me is the phrase “it didn’t work.” What is the definition of “it works?”
My first impulse is to consider the possibility that the hammer did not function properly as a hammer. This could occur due to a fault in the design or manufacture of the hammer. Even so, such a fault would not condemn all hammers categorically. By this definition, as long as a hammer does what hammers normally do, then it “works.”
If we assume the hammer did what hammers normally do, then what might the speaker have meant by saying “it didn’t work?”
Most likely, they meant they did not achieve the result they expected or wanted when they used the hammer. That may be so, but is it reasonable to conclude from that experience that hammers are categorically useless?
A hammer is a kind of tool. A tool is something that aids in accomplishing a task. Hammers are designed to aid people in accomplishing the task of driving nails.
If “it didn’t work” means “I didn’t accomplish my task,” then is the tool to blame? Setting aside faults in design or manufacture, we can assume a hammer always does that which hammers are designed to do: They apply blunt force to a target. We can further assume that a hammer has no goals, hopes, fears, intentions, or ulterior motives. It just strikes whatever you swing it at, whether or not you’ve selected an appropriate target and whether or not you’ve swung the hammer with skill. To say that a hammer “didn’t work” is meaningless.
One can also consider the following to be tools, in the sense they are things that aid in accomplishing tasks:
- pair programming
- test-driven development
- User Stories
- Specification by Example
- continuous delivery
If we want a tool to help us accomplish a task, it seems to me we need to follow a two-step process:
- Choose the right tool for the job
- Use the tool properly
Otherwise, it won’t “work.”