Establishing Trust to Make IT Development Process Changes

As someone who’s done projects for over 30 organizations in my career, I’ve run across a wide variety of development methodologies. Most folks know by now that when an organization says they are “doing SCRUM” or “doing Agile” what they really mean, is that they are cherry picking practices that work for them, and avoiding those that are uncomfortable.

As a consultant, it is often not possible to help organizations with their development methodology without some initial wins. Who would trust their guitar technician to restore their 1960s Martin without first making sure the person can do basic repairs? It is during this initial first effort, whether as a technical lead at a product company or a consultant where we have an opportunity to lay the groundwork for future development process improvements. This post is about some key interpersonal skills that when used well on even small projects, will hopefully help you win the trust needed to move on to higher value process improvements.

Establishing Authenticity

If we want the best chance of organizations we do work for getting the most value from us, it starts with establishing an authentic relationship. This means from your initial conversations all the way through the conclusion of the project, you should get to know the people you will work with on a personal level. If you don’t show any interest in people outside of the work, it’s less likely that they will come to you when something’s really bothering them. And it is often personality conflicts, or issues in a person’s life, that block progress more than any technical hurdle.

Setting Expectations for Change

In 20 years of software development, I have yet to see a single SCRUM team get into a sprint and not have changes be necessary. The User Acceptance Criteria may have had some holes. The test plan wasn’t robust enough. The team didn’t think about compliance regulations. The list of opportunities for this to come up is endless.

Rather than bringing this up for the first time as it happens, I communicate at least once a week, in front of my entire team, a reminder that we as a team will run into issues. I remind them that we are humans, and humans can’t be expected to remember everything needed about a system through conversations.

I’ve spent heaps of a client’s money that insisted on a fixed bid design before starting development (no, I was not involved in the statement of work on this one), only to find that when engineering went to build it, 30% of the feature set that the product manager thought was part of the “minimum viable product” was still missing. This one’s solved by releasing early and often, but that’s another topic.

The key takeaway here is to be “real” with your client or immediate supervisor, and not leave them with rose colored glasses, thinking the process on your team will eliminate having to deal with changes.

Establishing Your Role

Whether you are a consultant or in a permanent position at an organization, how you work with those who you report to has a huge impact on the success of projects. In Peter Block’s famous book Flawless Consulting he outlines three roles in which one can interact with their “customer” on a project:

  • Expert: The expert swoops in, does something for the client, and then vanishes.
  • Pair of hands: The pair of hands mindlessly follows the client’s instructions regardless of whether they actually make sense.
  • Collaborator: The collaborator partners with the client to define the problem and create and implement the solution.

You want to get to the collaborative style, and start there if possible. I usually get an idea of how well this will go by bringing it up at the beginning of the project. Educate your client or immediate supervisor on these three roles and help them to understand the value of collaboration. If you get pushback, be prepared that what they probably want is an expert or a pair of hands. If you allow yourself to be relegated to this role, it greatly diminishes your impact.

Establishing Change Management Procedures

When changes do arise, as a technical person it can be tempting to bark “nothing new gets added in the sprint!” and I’ve certainly been there. In reality, new work often has to be added to a sprint to complete scheduled work within it. It is here where you can show leadership, helping the team to make the decision on when to add the new work and get it done in the current sprint, and when to push it to the next one. It is essential to establish change management procedures at the beginning of a project when other leaders at the organization are under the least pressure and most willing to hear advice on how to proceed.

Demonstrating Honesty

When you make a mistake, communicate it to those it will impact as soon as possible. But this too should be taken with a grain of salt. There is a right way to admit a mistake, where it is simply stated along with some possible ways forward, and a wrong way. The wrong ways I’ve seen this done (and done it myself!) is to admit the mistake, but either blame it on someone else, or to use positioning statements to trivialize the mistake. The first one is a problem because unless you are very careful, you can leave the dependent party feeling thrown under a bus. The second one is a problem because it leaves your client or immediate supervisor with a feeling in the back of their mind that you will not want to let them know about your mistakes. Both are bad for the relationship.

Positively Reinforcing Behavior Changes

When other people on your team begin to change their behavior to follow a process better, be sure to thank them publicly. If you are a consultant, thank people in front of their peers. If you are an employee, thank them in the most public way possible. This doesn’t have to be some big schmooze fest – just give credit where it is due.

Increasing the Regularity of Celebrating Progress

Insist that your team celebrates their releases in some way. If releasing multiple times a day, get together at least once a week! That’s one great team that deserves to celebrate progress! When people are reminded that they are doing a good job by getting out of the office and spending some time together (on the organization’s dime) it helps keep morale high as inevitable challenges are encountered. Especially if you are a consultant or someone new to the team, doing this will help other people accept you into their inner circle. This one is more important than you might think.

Have you used some of these approaches in establishing trust before making big changes with your company or clients? Leave me feedback below! Thanks for reading.

Burn-Down Charts: The Silent Value Killer

Spend any time with Agile development and you’ll come across the burn down chart. The premise is simple – if a team committed to delivering 15 planned innovations (features, user stories, or whatever you want to call them), a little gets done over time so the remaining work should “burn down” to zero at the end of the sprint.

While burn down charts are effective tools for tracking how a team is progressing towards finishing planned work, there is a sinister effect that happens in many organizations that learn to use them. Managers begin to primarily focus on the number of innovations delivered per sprint. Though they may be tracking other metrics, it draws their attention because it is simple to understand, and easy to communicate. It also feels like producing as many innovations as possible is getting the most value out of a team – common sense right?

Unfortunately, the goal of a business is not to do work. The goal is to grow and create economic value. As anyone who’s read Continuous Delivery or The Lean Startup knows, most of the innovations you plan and deliver do not produce value as expected. Though market and customer research, usability testing, and strategic planning are all useful tools; the only proof of value is whether customers actually use your innovations.

To find out which ideas are good, you’ve got to release them and be prepared to throw away the innovations you had that didn’t meet their needs. If you’ve invested in releasing in small batches and using a deployment pipeline, the delivery process is optimized for getting feedback. If you stop there however, you’ve fallen victim to process ceremony.

Once you start releasing more often, you also need to optimize for changing course based on what you learn from the increased feedback. The bad news is it doesn’t look as good on a chart.


The chart above depicts some of the effects on value for a team focused on innovation throughput as a primary goal. As each sprint progresses, the percentage of value is about the same. The industry standard being less than 1/3rd of the ideas you release will provide useful value to customers in established markets, much less in new products. If the theories businesses have about what their customers want before they deliver them were usually true, we’d see more successful startups.

Since what was planned at the beginning of the project above doesn’t change from one sprint to the next, there are no opportunities to course correct until the end. And each new feature that is released increases the maintenance cost since complexity goes up along with feature count.

In this sad state of affairs, the trends should be obvious: an appalling rate of value, decreasing innovation throughput, and increasing maintenance costs. In situations like this, it is alarming to experience how teams will subconsciously game the numbers so the number of story points (effort towards features) looks like it is going up. This is an unfortunate behavior that is unlikely to change with the motivation for measuring performance focused on innovation throughput.


The chart above depicts a more typical set of activities for a team focused on value instead of rate of innovation. The highest throughput of new features occurs at the beginning, when you don’t know how your customer will receive the minimum viable product. The team can focus mostly on delivering the first few new features.

During the second sprint, the first release is available to customers and they are providing feedback. To prepare for the change in direction that is inevitable with listening to this feedback, it is more important at this point that the features that were already delivered are of high quality. If any corners were cut, now is a great time to remedy that.  The team might do some refactoring, and plans for what features they deliver next will need to change to accommodate the feedback that was gathered.

When the third sprint rolls around, the team got rid of some ideas we delivered that weren’t right based on what we learned, made sure that what was in the prior sprint was stable, and are now working to deliver features that are closer to what the customer said they wanted. If the feedback we got was reliable (customers ask for things they don’t really want all of the time!) the value produced during this next sprint will potentially be higher.

At the fourth sprint, the team has a steady stream of feedback, and is working on a combination of new ideas and enhancements to adapt what was released to the customer’s desires. The number of features delivered is still lower than when the project started though because some refactoring may need to be done to keep the quality of features high since potentially dramatic changes to the design may have been made to release the most valuable ones. From here on out is a see-saw of increased value from releases, and intermediary releases where the team vigorously realigns the priority and structure of work to accommodate what they are learning. That’s right folks – finding market fit is messy. But this is what needs to be done to make real money in the industry.

Now some of you might be thinking “Can’t I just measure the time spent refactoring and maintaining so we can combine these together and have a clean burn-down chart? I need to show that our resources are fully utilized!”. And yes, you could do this, but why would you want to? I will tell you why – a lack of trust. When management overseeing a new product or initiative wants to micro-measure all aspects of the delivery process to ensure they are getting the most throughput there is an assumption that someone is not working as hard as they could be, and that this can be identified on a chart to “save money”.

The problem is that any process measurement system can be gamed. The only true measurement of progress in a business is profit, and the way to arrive at these moments of high growth is through the adaptive, difficult-to-quantify, collaborative approach in the second chart. Having a team able to work towards value in this way requires brutal honesty about what didn’t work, variation from one sprint to the next, and above all – trust.

So go ahead and estimate features you will deliver each sprint, and use the burn-down chart to see how the team is performing so they can do better at estimating. But stop penalizing teams for delivering a different number of features (or user stories) each sprint. You just might figure out the ideal features for your customers – and keep your staff around for the long haul ahead.

How to Evaluate Application Architects

About 3 years into my career, I was promoted to the coveted “Application Architect” at a manufacturing software subsidiary of a Fortune 500. At the time I was a force of youth and passion – but I hadn’t developed the skills necessary to really shine in the position. I was successful in many ways, but I also lost many opportunities that are crystal clear looking back at that early period of my career.

I served as an Architect in several positions after that, but it wasn’t until I started working for Catapult as a consultant that I learned the soft skills necessary to really be effective. In my 9 years of consulting I’ve had the benefit of working alongside architects at clients that were both great and in need of some help. Though the industry still has no standard definition for what an Architect should do (don’t believe what those certifications try to tell you), there are a few considerations that lend themselves to great outcomes in the position.

Catching Process Breakdowns

Any architect who has worked with a team to deliver a product or service will have stories to tell about what makes a great process for delivering software, and what doesn’t. When talking to a potential Architect, I look for how they used technology to prevent low quality deliverables from getting further down the release pipeline.

We’ve probably all worked on a project where the team established a process for testing, code reviews, and managing configuration changes in each of the environments the product gets deployed to before customer eyes see it. It all sounded dandy until someone realized team members weren’t following the process – but that was too late. How does the individual use technology to cause deliverables to fail fast if they aren’t acceptable?

A Realistic Estimation Mindset

One of the hardest things about being a developer is estimating. The more experience we have with a technology, and the better we understand what constitutes acceptable deliverables, the more accurate the estimate. Most projects allow some user stories to be given to the team with too much uncertainty in the technology or holes in acceptance criteria – how does the individual deal with this? A common response to this situation is to get clarification from the product owner – but what happens when there is still significant risk? I like to hear how individuals communicate timeboxes for research or prototyping of an aspect of the unfamiliar technology and how they would determine when too much time is spent on it.

Sharing Pattern Decisions

We’ve probably all worked with a technical “leader” of some sort who has to be the person to set the pattern that will be used for error handling, validation, messages on a service bus, or a host of other common needs in modern applications. Architects are called to lead – otherwise you end up with the “rockstar” personality who can’t scale and becomes a bottleneck, poorly utilizing the whole team. While a good Architect will show the team patterns during decisions and help them think through problems they might see with them, a great Architect inspires team members to propose patterns themselves and then helps them champion these, giving full credit to the team members.

Mastery of CRUD

The vast majority of modern applications are heavily backed by data; and an application with a poorly designed data model can exhibit poor performance, high cost to introduce new features, and excessive business logic. Great Architects can understand requirements of products as they emerge and help the team to make sound decisions about how to model relationships between data and modify it. They also understand REST not as a technology, but as a principal. I run across a surprising number of Architects that have not developed this skill.

Making Time for the Team

An experienced and effective Architect will not allow themselves to be assigned too much work to support their team. They know that quality deliverables require support and that this has a cost – and will argue it to the folks approving budget with appropriate vigor. As a leader of one or more teams, an Architect cannot be effective if they are annoyed by questions from more junior team members. Rather, some of the best Architects I’ve worked with love to teach and know that by building up the value of their subordinates they can improve the velocity of the team more than focusing on themselves.

Expert Communicator and Facilitator

Almost any Architect can create a PowerPoint presentation or write a blog post, but is what they convey at the appropriate level of detail for their audience? Ask an Architect questions about how they explained an aspect of their implementation of a product to customers and other non-technical personnel. How did they get consensus when stakeholders disagreed?

Evaluate their face-to-face communication style – many architects have a hard time listening because they are already trying to design what’s coming out in the conversation. A great Architect takes notes during conversations and strikes a balance between too much detail and not enough. Evaluating this during an interview or conversation is difficult, but most Architects who know how to do this will mention it when the topic is approached.

Patterns as Necessary

The ivory castles Architects build can become wonders of intellectual masturbation at times and lead the rest of the team to ruin with abuse of the single responsibility principal to an excessive level. I look for Architects who know how to select the simplest possible way to meet the requirements while introducing new patterns only when absolutely necessary. I’ve run across one too many projects where the Architect is the only one following a pattern they set. When I talk to other team members, they just don’t understand the pattern, and don’t have time to follow it. If an Architect cannot write a simple Wiki topic and communicate the value of an aspect of the architecture, chances are it may be unnecessary.

Courage to be Honest

The pressure to agree to deadlines, estimates, and functionality from the business on most Architects is incredibly high. While the best Architects I’ve worked with have an affinity for the business and immense respect for the company’s business model, they aren’t “yes men”. Saying yes to an unreasonable ask simply to avoid confrontation is not only irresponsible but also earns you a reputation for being out of touch with the true effort to complete work. The best Architects set appropriate expectations for sustainable paces of work – and spend the time necessary to argue why their methods are important for the better of the products. They help explain why they cannot make progress on a task in terms the business understands.

Hopefully some of these topics will help you when evaluating your next hire or partner who will be architecting one or more of your applications. What other key traits make individuals successful in this position? Share your comments below! Thanks for reading.

IT deployment standards: why now?

Much like what is happening in the “big data” space, challenges with interoperability in the IT deployment tool market are converging to create an opportunity for standardization. Before I go any further, let me introduce two terms that have no official meaning in the industry but will make this article easier for you to read:

Deployment Providers – These are command-line utilities, scripts, or other self-contained processes that can be “kicked off” to deploy some single aspect of an overall solution. An example might be a code compiler, a command-line utility that executes database scripts, or a script that provisions a new node in VMWare or up on Amazon Web Services.

Deployment Orchestrators – These are higher level tools that oversee the coordinated execution of the providers. They often include the ability to add custom logic to the overall flow of a deployment and combine multiple providers’ activities together to provide an aggregate view of the state of a complex solution’s deployment. Some open source examples of these are Puppet, Chef and Powerdelivery; and there are many commercial solutions as well.

With those two definitions out of the way, let me begin by describing the problem.

Do we really need deployment standards?

First, as more companies are finding that they are unable to retain market leadership without increasing release frequency and stability, having deployment technologies that differ wildly in operation as personnel move between teams (or jobs) creates a significant loss in productivity. Much like ruby on rails disrupted the web application development market by demonstrating that providing a consistent directory structure and set of naming conventions leads to less variability in software architecture and reduced staff on-boarding costs, so too is the IT deployment space in need of solutions for reducing complexity in the face of economic pressure. As developers and operations personnel collaborate to better deliver value to their customers, having a consistent minimum level of functionality necessary for Deployment Orchestrators to deliver the technology stack they’ve chosen provides the opportunity to reduce IT delivery costs that impact both of these job roles.

Secondly, as the number of technologies that need to be deployed increase exponentially, more organizations are struggling with having a means to get the same quality of deployment capabilities from each of them. While Deployment Orchestrators often include off-the-shelf modules or plugins for deploying various assets, the external teams (often open source contributors or commercial vendors) that create the Deployment Providers rarely have the financial incentive to ensure their continued compatibility with them as they change. This places the burden of compatibility on the Deployment Orchestrator vendor. These vendors must then constantly revise their modules or plugins to support changes originating from the downstream teams that deliver the Deployment Providers, and this coordination will grow increasingly difficult as the technologies that they deploy are also released more frequently through industry adoption of Continuous Delivery.

Standards create their own problems

Whenever one speaks of standardization, there are a number of legitimate concerns. If history repeats itself (and it often does), the leading Deployment Orchestration vendors will lobby hard to have any emerging standards align best with their product’s capabilities – and not necessarily with what is right for the industry. Additionally, as standards are adopted, they must often be broken for innovation to occur. Lastly a committed team of individuals with neutral loyalties to any vendor and a similar financial incentive must be in place to ensure the standard is revised quickly enough to keep pace with the changes needed by the industry.

Scope of beneficial IT deployment standardization

What aspects of IT deployment might benefit from a standard? Below is a list of some that I already see an urgent need for in many client deployments.

Standard format for summary-level status and diagnostics reporting

When deployment occurs, some Deployment Providers have better output than others, and having a standard format in which these tools can emit at least summary-level status or diagnostics that can be picked up by Deployment Orchestrators would be advantageous. Today most Deployment Providers’ deployment activities involve scripting and executing command-line utilities that perform the deployment. These utilities often generate log files, but Deployment Orchestrators must understand the unique format of the log file for every Deployment Provider that was executed to provide an aggregate view of the deployment.

If Deployment Providers could generate standard status files (in addition to their own custom detailed logging elsewhere) that contain at least the computing nodes upon which they took action, a summary of the activities that occurred there, and links to more detailed logs this would enable Deployment Orchestrators to render the files in the format of their choice and enable deep linking between summary level and detailed diagnostics across Deployment Providers.

More Deployment Orchestrators are beginning to provide this capability, but they must invest significantly to adapt the many varying formats of logs into something readable where insight can occur without having to see every detail. A standard with low friction required to adhere would encourage emerging technologies to support this as they first arrive in the market, lowering the burden of surfacing information on Deployment Orchestration vendors so they can invest in delivering features more innovative than simply integration.

Standard API for deployment activity status

When Deployment Providers are invoked to do their work, they often return status codes that indicate to the Deployment Orchestrator whether the operation was successful. Deployment Providers don’t always use the same codes to mean the same thing, and some will return a code known to indicate success but the only way that a problem is determined is by parsing a log file. Having a consistent set of status codes and being able to certify a Deployment Provider’s compatibility would improve the experience for operations personnel and reduce the complexity of troubleshooting failures.

Standard API for rolling back a deployment

Deployment in an enterprise or large cloud-hosted product often involves repeating activities across many computing nodes (physical or virtual). If a failure occurs on one node, in some situations it may be fine to simply indicate that this node should be marked inactive until the problem is resolved, while in other situations the deployment activities already performed on prior nodes should be rolled back.

Since rollbacks of deployments are typically executed in reverse-order and need to provide each Deployment Provider with state information needed to know what is being rolled back, today’s Deployment Orchestration vendors don’t make it easy to do this and significant investment in scripting is necessary to make it happen. A standard API that Deployment Providers could support to allow them to receive notification and state when a rollback has occurred, and then take the appropriate action would allow for a consistent behavior across more industry solutions and teams.

Standard API for cataloging, storing, and retrieving assets

When a failed rollback occurs, Deployment Orchestrators must have access to assets like compiled libraries, deployment packages, and scripts that were generated during a prior deployment to properly revert a node to its previous state. Additionally, it is often desirable to scale out an existing deployment onto additional nodes after the initial deployment already completed to meet additional capacity demands.

Depending on the number and size of the assets to store, number of revisions to retain, and the performance needs of the solution; anything from a simple network share to dedicated cloud storage might fit the bill. A standard API abstracting the underlying storage that Deployment Providers can use to store their assets and Deployment Orchestrators can use to retrieve the correct versions would enable organizations to select storage that meets their operational and financial constraints without being locked in to a single vendor’s solution.

Standard API for accessing a credential repository

In addition to Deployment Providers needing to publish assets as a result of deployment activities, they also often need to access security credentials that have been given permission to modify the infrastructure and components that are configured and deployed to when they execute. On Linux and OSX this is often provided by SSH keys, while on Windows a combination of Kerberos and (in double-hop scenarios through Windows PowerShell) CredSSP. Rather than each deployment needing to implement a custom method for locating keys on the correct servers, a credential repository where these keys can be stored and then securely accessed by trusted nodes would simplify the management of security configuration needed for Deployment Providers to do their work with the right auditability.


With these standards in place, Deployment Orchestration vendors still have plenty of room to innovate in their visualization of the state of nodes in a delivery pipeline, rendering of status in their own style and format for the devices they wish their users to support, and the coordination of these APIs to provide performant solutions across the Deployment Providers that would adopt such a standard. As a team bringing a new Deployment Provider to market, it would improve the adoption of the technology by having the option of adhering to a standard that would ensure it can be orchestrated consistently with the rest of the solution for which their technology is but one part. When standard APIs such as these are made available by a single Deployment Orchestration vendor without first having been established as at least a proposed standard, it is very difficult to motivate the broader community that creates Deployment Providers to do any work to support proprietary APIs themselves.

What do you think? Has the industry tried various aspects of this before outside of a single vendor? Has the market matured since then where the general audience might now see the value in this capability? Would it be too difficult to provide an API in enough languages and formats that orchestration could occur regardless of the platform? Let me know your comments below!

Photo: “lost legos 1/3” © sharyn morrow creative commons 2.0

Selecting a Deployment Pipeline: 10 Considerations

While a team must adopt a customer-guided, acceptance criteria-driven culture to begin releasing IT assets frequently and with high quality, eventually an investment needs to be made to create a Deployment Pipeline. Put simply, this is a technology that enables an organization to use automation to eliminate manual processes necessary in the release of their IT assets. The industry is full of automation tools and many organizations will need to use a combination of several to achieve one-click release of assets into an environment, enabling Continuous Delivery.

In no particular order follows a list of considerations I encourage you to take into account when selecting technologies for building your pipeline. These considerations are rooted in guidance outlined in the Continuous Delivery book.

#1 – Does it work with your source control systems?

When engineers check-in IT assets to a source control system or some other asset repository, the delivery pipeline should automatically trigger some actions. These actions might be things like compiling code, running unit tests, configuring servers and deploying assets. If you have one team that uses Github and another that uses Team Foundation Server and both teams’ deliverables are combined to produce the final product – you don’t want to get into a situation where someone needs to manually push and pull code between the two repositories.

If one deliverable is a dependency of the other, create a pipeline where the production environment of the first team’s deliverable is a located someplace where the dependent team can consume it. This might be a UNC drive, rubygems, NuGet, or Chocolatey repository (public or private), or a host of other options. This allows the first team to make changes in their own development environment, do their own acceptance testing, and then choose when they feel they have a build solid enough to push to the other team. The dependent team can then move their own assets and the associated dependent team’s assets through their own pipeline and eventually into the production environment where users will consume it. This technique is sometimes known as a cascading deployment pipeline.

#2 – Does it move assets between environments without recompilation?

One important principle of Continuous Delivery is to never deploy different binaries to different environments. If you compile or generate assets that are deployed to production differently than the copy in the UAT environment, you open your team up to an unnecessary risk of defects. Your deployment pipeline should be able to deploy the same assets to multiple environments with the only difference being their configuration.

#3 – Is it approachable by operations personnel?

To achieve the organizational alignment of bringing development and operations personnel together through DevOps, operations personnel will assist in the creation of and ongoing change to the delivery pipeline to support the value needed by the IT offering. If your operations personnel are not object orientated programmers well versed in polymorphism, domain-driven design, functional programming and other product development skills; you will have a challenging time getting them to adopt and contribute to the pipeline if those are the skills needed to work with it.

I recommend considering the selection of automation technologies that use scripting languages such as Windows PowerShell, bash, or ruby to automate. These languages have a lower barrier to entry, can execute without needing to be compiled first, and don’t require purchase of an expensive Integrated Development Environment (IDE) to modify. A good list of powerful tools that are built on these languages to start investigating might be Puppet, Chef, Capistrano, Rake, Powerdelivery, and PSake. I can’t honestly recommend MSBuild, Maven, or Ant for the pipeline (though they are fine for compiling things) because XML tends to be too fragile and difficult to comprehend for building even the simplest of conditional logic.

#4 – Are deployment assets versioned along with deliverables?

Because the deployment pipeline will be undergoing change, it will contain configuration and logic meant to deploy the assets of a release at a given moment in time. To enable rollback (I’ll talk more about this later) and reduce surprises, it is preferable to find a way to version the pipeline’s actions along with your deliverables. This is fairly easy to do with most of the technologies I cited above, but there are some other tools on the market that don’t lend themselves well to this important tenet.

#5 – Is it possible to write rollback procedures should aspects of the deployment fail?

Automating the “backing out” of changes made during a deployment, also known as a rollback, is an important step in gaining the confidence necessary to release to customers more frequently. This is the process of returning a deployment to its prior state if a failure somewhere along the way occurs. If your rollback process is manual, you introduce the chance of errors and troubleshooting an improperly performed rollback while the production system is down can cause immense levels of stress.

Look for technologies that keep track of actions performed and if there is a failure, either have “hooks” to let you write your own rollback logic or perform the rollback actions (in reverse order of when deployed) automatically. There’s a good chance you will need to create some of the rollback functionality yourself.

#6 – Does it prevent skipping of environments when deploying release candidates?

The reason teams create dedicated development, staging (or user acceptance), and production environments is to isolate changes being made from their customers and staff performing acceptance testing. One of the highest costs in deployment that kills a team’s ability to release more frequently is when the configuration and deployment of assets to these environments is manual. This is because it is simply too easy for a person to forget to make a change consistently in all environments.

Look for a technology that keeps track of which releases have been deployed to which environments, and will prevent a build that has not been tested from being pushed into production, for example. This is one of the reasons I created powerdelivery, because there isn’t a tool in the Microsoft ecosystem for putting quality in gates into automated deployments between environments, and the Windows Workflow Foundation technology upon which automated builds in TFS were created is too unwieldy and slow to keep up with the needs of a team that is frequently releasing.

#7 – Is it possible to use security to control who can initiate deployments into each environment?

Most teams put a policy in place that determines who is allowed to deploy releases into each environment. This is still a good practice, and should be agreed upon and communicated when planning to begin continuously delivering any IT offering. To help meet Sarbanes-Oxley (SOX) regulatory compliance and prevent mistakes, it is often not enough. Look for technologies that allow configuration of who can promote a build from development to test (often a QA resource) and from there into production (often an operations resource).

#8 – Does the technology provide access to compilers, deployers, and test frameworks you use?

You may have read some great story about how a darling start-up in silicon valley implemented Continuous Delivery using javascript, but if you can’t use it to compile, deploy, and test YOUR code you will end up fighting it. Look for technologies that include support out of the box for the tools and frameworks you use, or have a low barrier of entry to integrating them in.

#9 – Does the technology provide access to infrastructure automation for the on premise or cloud platforms you use?

Continuous Delivery is more than automated deployment – you also need to be able to spin up servers or virtual machines on premise and in the cloud depending on your requirements. If you are using Amazon Web Services, Windows Azure, Heroku, or any of the other popular hosting platforms; make sure your pipeline technology can utilize the best APIs from these vendors. If your technology allows you to deploy a website or mobile application but not harness the rich features of your hosting platform for example, you might be missing out on the ability to automate your entire infrastructure and benefit from things like automatic scaling of your application based on demand.

#10 – Is it possible to replay activities consistently across multiple nodes?

As more IT offerings are able to scale out their processing and storage across multiple physical or virtual computing nodes, deployment technologies that enable Continuous Delivery need to have first class support for parallel activities. If your ASP.NET MVC or Ruby on Rails website will be hosted on a cluster of nodes, look for a technology that can accept the DNS names or I.P. addresses of these nodes and perform deployments seamlessly across them, rolling back the nodes that were deployed to if one fails. If your projects are automatically compiled every time a developer checks in code but the deployment process requires repeating manual steps across multiple nodes – you are in for a long road of troubleshooting configuration mismatches and surely will have a way to go before you can reduce your release cycle time to be more agile in your market.

Hopefully this list of considerations helps your team think objectively about some of the hype out there around deployment pipeline technologies, and you can better take into account some of the additional costs of development and maintenance necessary to get them to work for your particular IT offerings.

Have you read the Continuous Delivery book or are you starting your journey towards reduced cycle times? Let me know some of the struggles and successes you’ve had around deployment pipeline selection and implementation below!

Continuous Delivery is about failing faster

If releasing to customers once a month, once a week, and even several times a day were easy – everyone would be doing it. Getting IT assets that generate revenue released faster is clearly an advantage. However, the biggest return on investment of Continuous Delivery is a little more subtle.

If you build it, they don’t always come

When a business has an idea for an investment in IT, they do market research, calculate costs and return, forecast customer adoption and get stakeholder buy-in – but often wear rose colored glasses without even knowing it. This isn’t any different from a start-up that is pitching its first business plan. Even with conservative estimates, many assumptions are made and there’s really no way to know how the investment is going to pay off until it gets delivered. There are no sure bets in product management.

As a product manager or business owner several of the ideas you have for your customer will turn out to be useless to them.

Over the 19 years that I’ve been working with companies to deliver IT products and services, I’ve never been satisfied with the waste I see in the processes that many organizations use in bringing ideas to their customer. So much time is spent prioritizing, evaluating costs, scheduling, and tweaking the efficiency of resources but a healthy dose of humbleness is often the key ingredient missing from the equation – and the most costly to ignore. When sure bets turn into failures, the cost of the investment and decisions of engineering are often where the finger is initially pointed. The reality is that as a product manager or business owner, several of the best ideas you have worked out with your customer will turn out to be useless to your larger audience. Customers may even tell you it’s the best thing they have ever seen, sign up to be early adopters, and give you positive feedback on what you’re thinking of charging. But by the time you release it to them, you’ve spent heaps of capital and it can cost you your job (or your equity) to find out you were wrong.

Taking risks in the market is necessary for a business to thrive. Innovation in small businesses drive the economy of the world, despite what larger corporations would have you believe. When a tiny idea explodes to have a big impact, we all benefit as new opportunities are created that result in exceptional economic growth. But even large organizations can have innovative, disruptive ideas flourish as pockets of entrepreneurial spirit win internal support to try something new. The barrier that must be overcome is risk aversion. With the biggest opportunities for growth requiring us to take some chances, why would anyone want to go about delivering their IT offerings using a process that penalizes change and the risk of unexpected outcomes?

Stop the bleeding

“Mr Corleone is a man who insists on hearing bad news at once” – The Godfather

The good news is that it doesn’t have to be this way. When a product that requires physical manufacturing is getting ready for market, everything has to be solid in the design and any changes along the way can bankrupt the idea. If a design change is needed in a new mold for carbon fiber parts that costs millions and the first one has been manufactured, the entire cost of the mold is lost. IT assets aren’t at all like this, though companies continue to think in this mindset. The inventory in an IT asset is information, and information is cheap and easy to change.

Despite the low cost of information as inventory, the time invested to create and change that information is still a concern. If an IT asset is delivered to the customer and found to not have market fit, the more that was invested in that idea, the more that is lost. Knowing this, we should seek delivery processes that let us know as soon as possible that what we’re delivering is not on target and enable us to make changes with the lowest possible loss. Many organizations employ usability studies and surveys to give them validation that an idea is viable before delivering it, and this is certainly a great practice. However I’ve seen customers rave about a design on paper, or a prototype – and then hate the product once it was delivered to them. You really need to deliver an actual, working idea to measure adoption in the market and get feedback.

The challenge

To deliver IT assets more frequently requires organizational change, relentless communication, investing in some technology, and the ability to handle the increased volume of customer feedback that comes with doing so. This isn’t something that can be done all at once, and a challenge I deal with when helping clients is to balance keeping momentum going with the changes needed and not being too disruptive to existing business. When I’ve seen teams attempt to do this without outside help, the politics and lack of experience with cross-functional collaboration can doom it to being looked at as just another pet project of an ambitious employee who didn’t understand “our culture”.

So many ways to fail (and be profitable)

When a team uses Continuous Delivery to move towards frequent releases for their customers, they invest in the creation of a deployment pipeline – which is essentially an automated release process. This is more than an automated build, which may compile some code and deploy it somewhere. Does someone ping the web servers every time you do a release, to make sure things are up? Automate it. Does someone change a setting in a configuration file to publish a mobile app to the right store? Automate it. Do a group of three people have to approve a build before it goes into production? Automate moving the build further downstream with their electronic approval.

With the pipeline in place, there are dedicated stages that each build of your IT assets go through prior to being released to customers. Along the way, an increased level of automated scrutiny is placed on it to fail as soon as a problem indicating that this version is not ready for prime time is found. Here are just some of the ways a delivery pipeline can help you be more profitable by causing failures to occur earlier in the release process.

Failure Cost Remedy
Defect found in production Must rollback system to good state, interrupt new work, and repair customer confidence. Automate acceptance tests in deployment pipeline that run in environments prior to production
Flawed design pattern identified All assets that used that pattern must be changed and re-tested. Initially release a small number of assets that use the pattern to customers.
Reduced desire for feature Lost investment in what was built. Invest only in a minimum viable feature before releasing to customers.
Slower output from team than expected Must adjust forecast delivery dates, must improve capability of team. Don’t commit to dates for sprints far in advance, measure team output more frequently, get training or make hires.
Insufficient performance at capacity Must purchase new hardware, optimize IT code or assets. Automate performance acceptance tests in a capacity testing environment.

These are just a few examples of how a delivery pipeline, and a team that has been organized to continuously deliver IT assets while aligned with their customer, can save money by failing faster. You can see here that the cost of finding a defect prior to production is less than if it were. The cost to change a design pattern that has low penetration in the overall architecture is lower than if it were identified after applied broadly. The cost to find or train resources to better support the needs of a team is less than not knowing they need this help and utilizing their low throughput over the lifetime of a product’s development. All of these early identifications of failure lead up to dramatic savings in the overall cost of finding that critical market fit, and working in a sustainable fashion to support the needs of the business.

By reducing the cost of failure, the ability to handle risk goes up and the opportunities for efficiency are numerous. If your organization is not taking steps towards a more fluid release process, it is only a matter of time until your competition’s agility will enable them to blow past any market advantage you currently have.

Tips for Estimating Continuous Delivery

Ahh, estimating. We all hate to do it, but it’s critical when releasing more often. The good news is it’s not nearly as important to get it “just right” for an entire effort, but it is important that the current sprint is estimated well. The following article should help you understand what’s different about estimating a sprint (release) when you use Continuous Delivery as apposed to using a SCRUM/Agile process where the work is done in small iterations but not actually released.

Because delivering IT assets is a highly variable process (if it weren’t every task would take the same time just like creating parts on an assembly line), it is highly likely that one or more estimates will be off by some amount. When your team starts a sprint of work using Continuous Delivery, the goal is to actually release something at the end. Because of this focus, we need a way to accommodate variability.

The problem with “buffers” in tasks

Most folks remedy variability by putting “buffer time” into their estimates to account for unknowns. If you put buffers into tasks, there are two problems that occur. The first is that psychologically, those assigned to the tasks have a misplaced sense of “extra time” left to complete their tasks. You do not want individual tasks to be scheduled to take any longer than what’s expected. If your team doesn’t understand a user story well enough to describe verifiable acceptance criteria to demonstrate it works, don’t put it in the sprint! If you do this, you are making it highly likely that you won’t release at the end.

The second problem with putting buffers into individual tasks is that you have just scheduled all of your tasks to essentially be as costly as they can be. You can’t track to a realistic estimate and are essentially planning on each task taking as long as possible. I can’t stress this enough – don’t use buffers in task estimates for sprints when you want to release the work at the end.

Why high capacity utilization is dangerous

Because the goal of most IT value chains is to deliver value as efficiently as possible, it can be tempting to load resources to high capacity utilization. Because we don’t want buffers in our tasks but the work is highly variable, the proper place to accommodate this is by scheduling resources with excess capacity. By leaving excess capacity, resources that finish tasks early are freed up to help others with theirs and it is more likely that having multiple people working on a problem will still get it finished on time than asking a single, highly utilized resource to “just work faster”. The risk of any one member blocking the entire release by variability encountered in getting their task done goes up exponentially as you pass 70% utilization. If you don’t leave extra capacity for resources, you are all but ensuring that you will not be able to release the work at the end.

Sprint “Zero”

The first sprint of an effort that will employ automated continuous releases is the place to estimate and complete tasks that are hard to do once the entire team has started work. The following is a list of some things to consider scheduling for the first sprint (or several depending on the size of the effort to be worked on) to prepare for the entire team coming on board.

  1. Time to setup infrastructure like servers, security accounts, and opening of ports
  2. Time to setup source control for any change controlled assets
  3. Time to build an initial website, database, business intelligence data mart, mobile application, or whatever you will be delivering that is either empty or has just one page or set of data
  4. Time to create an automated deployment process for deploying changes through your various environments (development, UAT, production etc.)
  5. Time to create a policy for who will approve release candidates to be promoted from one environment to another
  6. Time to populate and prioritize the backlog and do business analysis necessary for agreeing on the acceptance criteria for the first sprint where the team will work on functional deliverables

Functional Sprints

Once the larger effort gets underway and the team is brought in, the list below includes some things you should consider when estimating work that will be released at the end of the sprint. This is by no means a comprehensive list but includes some things you might normally put off until the end of a larger “iterative waterfall” project where the team builds functionality in sprints but doesn’t release it until a stabilization phase at the end.

  1. Time to implement new features or changes
  2. Time to test features or changes
  3. Time to fix any defects found during testing
  4. Time to change anything about the automated deployment or testing process needed to support the features being delivered
  5. Time to update user documentation that describes the new features or changes
  6. Time to hold the sprint review meeting, accommodate feedback, and release to production
  7. Time to hold a sprint retrospective to capture what went well and what actions will be taken to remedy problems found

Hopefully this article helps you to consider some of the changes needed when estimating work to release more frequently. The team will complete less functional volume than you might be used to, but the trade-off is that at the end – you can release it. As a parallel effort to the ongoing sprints of releasing new IT offering functionality, Product Management can work with early adopters of the new system or customers to integrate their feedback into the backlog to make adjustments keeping the team’s efforts in line with their needs.

How frequent releases help you satisfy and retain your best employees

Think back to the last time you released to your customers. There was probably a brief feeling of satisfaction, hopefully a validation from the customer that you delivered what they wanted, and your team learned a thing or two about how effective they are at deploying and testing the changes that were delivered with the release. Soon afterwards, the team gets to start all over again and these lessons are forgotten.

If you think about a long term relationship, when two people haven’t talked for a while they can get nervous. “Does he still remember what I said about what we were going to do?”. “I wonder if they still feel the same way about me?”. This phenomenon is also present in product development, and the longer your team goes before releasing, the bigger impact these psychological (and measurable) effects have on the profitability of your business goals.

Keeping delivery staff satisfied

When a change is delivered to the customer that meets their needs, the team gets a big boost in motivation. The team is thanked and hopefully rewarded for their efforts, and sales and marketing have a great new story to tell. During this period of “delivery afterglow”, staff are intrinsically motivated to work harder as they feel a responsibility for and purpose to their job. After a while however, staff can revert to their instincts to question how important their job really is, leading to the “I’m just a cog in a wheel” mentality. “Was what we delivered really that big of a deal?”. “I wonder if we can repeat that success again?”.

When release cycles are short enough, this feeling of satisfaction becomes constantly present and creates the environment where people love to do their job not just because of their compensation, but because of the satisfaction they get out of doing it through regular positive feedback. An environment like this is contagious – staff outside of the successful team want to learn their methods and repeat their success, and staff on the successful team are happy to talk about it with friends and potential customers.

What have you done for me lately?

From the customer point of view, they also experience similar emotions that have an impact on the profitability of your delivery efforts. If a long period of time has elapsed between when the customer got a release with changes, they may begin to wonder if you still understand their vision. “Do they know what’s changed in my market since last time we met?”. “I hope they understood what I said!”. “I wish I could talk to them more without bothering them!”. When release cycles are long, this risk of changing priorities and incorrect assumptions has a higher cost. When a manufacturing plant releases a part on to the next station that has a problem, it is often caught via quality gates when assembled as part of the next process to stop the line from moving it forward. In product development information is our inventory, and our customers are the quality gate that matters most.

If an incorrect assumption is made about a change or feature and not validated with the customer early, hundreds of other changes can be based on this incorrect assumption and they are all impacted if the customer finds them to not be valid once released to them. Engineers can lose motivation dramatically if they release a big feature that took a long time to implement only to find that it all has to be reworked. It makes both economic and behavioral sense to release more frequently to ensure that the relationship between the team and its customers is aligned as often as is reasonable.

Practice makes perfect

When releasing changes to the customer, there are delivery costs that are only incurred at the time of release. These usually include things like deployment, user acceptance testing, updating user documentation, and gathering feedback. When release cycles are long, these activities are infrequent so there is low motivation to getting better at them. If a team only releases to their customer once every 6 months, they feel the pain of these activities infrequently and so they are willing to see it as such – a necessary evil that isn’t worth the time to improve. When releases are more frequent, the cost of manual or inefficient delivery processes is more apparent and staff can more clearly see the need for making them as efficient as possible.

Optimizing release process costs is doubly profitable as it both reduces the cost of performing the process, and reduces the time for return on investment due to enabling more value to be delivered per release since a smaller percentage of the effort that goes into a cycle is taken up by these processes. It also increases staff job satisfaction because more time is spent delivering value that is the direct result of the innovation inherent in the creation of IT assets, not simply drudging through excessive process overhead that hasn’t been optimized due to low motivation to do so.

Motivating for excellence

A final important consideration that impacts staff retention and job satisfaction is the opportunity that frequent releases create for evaluating competence. When releases cycles are long, staff are able to report being done with tasks but this is not truly verifiable until it is released to the customer. Many organizations realize the inherent value in retaining top talent but struggle to know how best to help them grow. One of the best ways to help our employees be more effective is to have regular checkpoints during which to measure both quantitative and qualitative outcomes. An IT asset release is a perfect time to do this.

The SCRUM methodology encourages teams to hold a sprint retrospective meeting during which the team can be candid about their successes and opportunities for improvement since the last iteration. When iterations of effort are reported as “complete” at the end of each sprint but not released to customers, unchecked problems with deployment and missed alignment with customer needs is not caught and can leave a team with a misplaced perception of success. This perception is then aligned when the release actually occurs, and the reset between what was perceived and what is reality can be harsh and demotivating.

Rather than delay the inevitable, by releasing to customers more often before starting new work, leaders that evaluate their staff have a better gauge for where staff are doing well and where their skills may need help. An effective manager will use this period to both reward and compliment staff on their improvement and be courteous in helping them see where they need to improve. Though this increased confrontation with competence can initially be met with feelings of uneasiness, it soon becomes a regular part of work and employees begin to expect honest feedback and to be complimented and rewarded when they improve.

Top 5 business myths about Continuous Delivery

When a team decides to try reducing the time it takes for their ideas to get to their customers (cycle time), there are a few new technical investments that must be made. However, without business stakeholders supporting the changes in a SCRUM approach that delivers frequent releases, decisions and planning are driven by gut feel and not quantifiable outcomes. The following is a list of the top 5 myths I encounter (and often address when I provide coaching) to help staff that are not solely technically-focused when they begin adopting Continuous Delivery.

#5: By automating deployment, we will release more profitable ideas.

Automating deployment of IT assets to reduce low value activities like manual configuration and deployment (with risky error-prone manual human intervention) certainly can eliminate wasted capital as part of the process of releasing IT offerings, and is a key practice of Continuous Delivery. However, if the frequency of releases is long, the cost of delaying the availability of those releases to customers adds risk in that their viability in the market may no longer be what was theorized when it was planned.

Once release frequencies are improved, measurement of customer impact and proper work management (specifically appropriate capacity planning and calculating the cost of delay for potential features) must be done to ensure that ideas that turn out to be misses in the market stop stop being worked on as soon as they are identified as bad investments. It is this harmony of smart economic decisions with respect to investing in the idea combined with the technical benefits of building an automated deployment pipeline that transforms the profitability of an IT value chain.

#4: We must automate 100% of our testing to have confidence in automating releases to production

Utilizing automated quality checks to ensure that changes to IT assets do not break existing functionality or dependent systems is certainly a good practice. A long manual test cycle is doubly problematic: it delays releases and adds risk since many teams try to get started on new work while testing is underway. When issues are found with a release candidate build or package being tested, engineers must stop what they are doing to troubleshoot and attempt to fix the problems.

On the flip side, automating the entire testing effort has its own risks as the team can cost the business large sums by having to change and maintain tests when they make changes to the design which happens frequently in Continuous Delivery. Deciding on an appropriate test coverage metric and philosophy should be treated with importance and not included in work estimates as separate line items to discourage removal in an attempt to cut costs. Cutting quality is often the final dagger in the throat of a struggling IT offering.

#3: The CFO requires us to release everything in the backlog to report costs

Many businesses treat IT investments as capital expenditures since they can take advantage of amortization and depreciation to spread the cost of that investment over a longer time period. However, this assumes that the value in the investment provides a consistent return over the lifetime of it being used to generate revenue. A SCRUM process for delivering IT assets aligns better with being recorded as operating expenditures since a minimum viable offering is typically released with a low initial investment in the first few sprints, and the business makes ongoing “maintenance” changes to the offering as the priorities of the market and customer needs change. This is especially true today with everything moving increasingly to cloud based models for value consumption.

#2: We need a “rockstar” in each role to deliver profitable offerings

Many IT offerings that start with an idea are initially implemented with an expert in a particular technology or aspect of delivery, and the team leans on them early on for implementation and expertise. As the complexity of a solution expands, the biggest drain on the profitability of a team is no longer the availability of experts and the high utilization of people’s time – it is the time work to be completed spends waiting in queues. There are several ways to reduce wait time when work with a high cost of delay is held up in a queue. The two methods I see with the most value are to reduce the capacity utilization of team members, and to enable staff to work on more than one discipline.

When team members are highly utilized (their planned capacity is over 60%) this leaves no room for the highly-variable process of delivering IT offerings to account for unknowns that were not identified during planning or design of a cycle of implementation. If the cost of delaying the availability of an idea is high, the cost increases when the date planned for release is missed. Rather than loading resources up to a high capacity, leave them with reasonable overhead to collaborate, tackle unforeseen challenges, and help each other if they finish early.

When team members are specialized, the probability of one member being blocked from continuing by another goes up dramatically. Work to be completed spends more time in a queue wasting money and not moving closer to being made available to customers so it can realize a return. Though you will always have team members that have expertise in specific areas, resources that are willing to test, make informed product priority decisions, and help with deployment and automation are more valuable as part of an IT value stream than specialists. Use specialists when the work requires it, but scale more of your resources out across multiple disciplines for sustainability.

#1: Until we release everything in the backlog, we won’t succeed with our customers

This myth is driven by the manufacturing mindset of looking at IT offering delivery as though all features must be identified up front and misses the point of agile methods entirely. The backlog is a set of theories on what customers will find to be valuable at any given point in time. Any offering that takes more than one release to complete will have a working minimum viable product available to some audience where feedback can be gathered before it’s done.

Since the point of frequent releases is to get that feedback and let it impact the direction of the IT offering, planning to release everything in the backlog leaves no capacity for taking action on that feedback. If you only plan to release everything the business thinks is a good idea at the beginning of a project before letting customer feedback influence priorities, you are simply releasing milestones of planned up-front work – which is a classic waterfall delivery process.

Powerdelivery extension for Visual Studio 2013 released

I’ve released a version of the Visual Studio extension for using powerdelivery on Chocolatey. This extension allows you to connect to Team Foundation Servers, see which builds are present in each of your environments (Dev, Test, Production etc.), open the appropriate scripts and config files for developing the pipeline, and kickoff builds.

To install it, have Powerdelivery and Visual Studio 2013 already installed. Then run the following from the command prompt (with Visual Studio closed):

cinst PowerDelivery-VSExtension-2013

Remember you can also install this extension for Visual Studio 2010 or 2012 as well using the appropriate package.

%d bloggers like this: