Why Agile Transformations Can Fail: Sense of Urgency

At Polaris Solutions, we work with a number of customers that are looking to become more agile in their software development practices. We often help them move in that direction through adoption of new practices, tools, and roles within their organizations. Scale (the number of people/teams affected) and Scope (the degree of change involved) are the two largest variables that go into planning such a change. The bigger the scope and scale together tend to require more effort in order to ensure that the change will be successful and our customers will realize more value. In order to be successful at agile transformations you need more than agile knowledge and experience, you need to be experienced at managing change.

Over the years, as we’ve been involved in numerous transformations, we’ve noticed several patterns for success and many anti-patterns. In this post, which is the first in a series of posts that I will write, I want to deal with one common way that these efforts can go sideways or fail: Not establishing any sense of urgency.

The first question to ask – is why the transformation is needed? Is it actually an urgent need? Does your team or organization feel compelled to change now or is continuing standard operating practices considered generally acceptable? Before a team or organization is going to change, they will need to recognize the pain of not moving. It has been suggested that human beings change behavior only in response to pain (either emotional or physical), therefore, the greater the actual perceived or actual pain, the more the higher motivation to fix it. This is true for agile transformations as well.

Providing strong focus and investment in “the case” for an agile transformation in the enterprise will pay off many times over. The following are some suggestions to ensure that a transformation gets off to right foot that we’ve gathered from our experiences:

  • Ensure Awareness – I’ve seen too many organizations hope to enact change after 2 weeks of training and never talking again about agile. There are many degrees of education and experiences you can provide a team to illustrate the value of moving to agile. Giving awareness and knowledge can help make the case for agile as it largely makes sense to most team members. “Early and often” is a good rule of thumb when communicating in larger organizations.
  • Identify Champions and Hold
    Outs – The United States military would like to ensure that it has overwhelming force when engaging in battles, and you should as well when endeavoring to change a company’s culture towards agile. You have friends and allies that can be helpful – do not try to lead a change like this by yourself.
  • What Will Happen if We Don’t Change – Answer that question for yourself and for your team or organization. Perhaps the answer to this is “quality issues are causing us loss in customers or contracts.” You can use a combination of logic and reason and emotion to communicate this concept, but I have found that if it can be tied back to metrics and numbers – most people will understand and align with you.

None of these items really have to do with technology or agile in particular, but the people in our industry that help lead these changes need to consider these concepts if their engagements are to be successful.

Release Management’s Traffic Overview Explained

I wanted to write another post to help clear up some functionality in Release Management (for Visual Studio 2013). Many teams that I have opened up Release Management (RM) to see the traffic overview page and wondered how that data is actually calculated. What are App/Traffic/Fail metrics to be watching and why is this important. The pro-tip here is that if you hover over these numbers in the tool, you can see a better description.

Each of your Release Paths (pipelines) are listed down this page. Each of your stages is shown for each pipeline. You can get a sense of how many steps are required for an application to reach its ultimate destination (in this case “prod-client”), which is the right-most stage for any given pipeline.

Under each stage, you have:

  • App – which are the number of apps that have been released to that stage (all time). Note, you can have multiple applications going through a shared release path. If you have two applications that follow the same approval chain and environments, have them share Release Paths.
  • Traffic – Number of releases in the last 5 days to have been released to that stage (or have failed to get to that stage, but attempted)
  • Fail – Number of failed releases in the last 5 days to have been released to that stage.

You should probably see higher numbers on the left than you do assuming you’re like most development shops.

So what can you do on this screen?

If you double click on any of the stages, you’ll get more details about the apps that have been transitioned through that Release Path. It will show you the all-time traffic through each of those stages (more than the last 5 days).

Release Management Approvals Explained

Microsoft’s Release Management for Visual Studio 2013 has a lot of great functionality around authorization and security for releases that are being promoted through environments within the enterprise. One of the great strengths of Release Management is its ability to track actions being performed around deployment in an auditable fashion. Every single approval and manual step performed by humans is captured by the tools (assuming you’re respecting the rules of the game), and every single automated action has an owner that is tracked as that automation is performed in a company’s IT environments.

A Release Path in Release Management defines the environments by which applications will be promoted. It contains the definition of which environments are relevant and who will be participating in that promotion process. The release path below is simple one that contains only a Dev and Prod:

For each environment below, one can define relevant approvers in the workflow. I’m highlighting what I think is the most important of these:

Acceptance: This person or group of people is responsible for accepting a new release into that environment. During the release process, Release Management (RM) will optionally email everyone that is named in that box. And if any one of them approve it, then Release Management will start the automated deployment process.

Validation: This person or group of people is responsible for indicating, generally, that the automated deployment worked. Perhaps as part of the process, the team decides to run a quick smoke test against the environment before considering it “validated.” The team has the ability to define what “validated” means and it could vary by team and environment. It could mean that the QA team has run a regression test, or perhaps the developers have performed a quick smoke test. In this case, as in the case of Acceptors, if any one member of the group approves, then the release is considered validated for that environment.

Approvers: After an environment is validated, then there’s another step called Approval. This is a separate from validation in that – it’s not indicating that the release is working in some fashion, but rather this is the chance for a person or team to approve that the release can be considered “worthy of being promoted beyond.” For a development environment, the development team may be signifying that the release is worthy of moving to QA or PROD. This Approval step is different from the other two kinds in that multiple people or groups can be added. All of the ones listed must approve before the release is considered “Approved” in that environment.

 

Below is an example chart that I’ve used to map out roles and responsibilities in the release process. This chart was created for a traditionally managed IT organization with separate QA and DEV teams.

Environment

Development

Testing

Production

Acceptance

[All Developers]

Recommend leaving automated to lower friction of deploying to a development environment.

 

[Testing Leads]

Recommended a small group make this acceptance to prevent any loss of work from testing team due to errant releases to the Test environment.

[Infrastructure Team Leads]

Team required to indicate that production was ready for a release and the change management process was respected.

Validation

[All Developers]

Recommend leaving this automated to prevent friction of deploying to development team.

[All Developers]

Likely, the developers would do a quick smoke test on the QA environment to ensure it’s in working order before testers start performing their tests.

[All Testers]

Whomever has the skills to indicate that the release successfully made it to the environment.

Approval

[Development Leads]

 

Agrees that the release is good enough for QA to begin testing.

[Testing Leads] and [Product Owner]

 

Required both sign offs before the release is readied for production.

[Product Owner]

 

Someone that signs off that the release was a success and new features are working as expected.

 

I have a few patterns that I’ve noticed that seem to be worthy of reminding:

  • Validation and Approval can be confusing. They both take place after the deployment, but I like to suggest that they mean very different things. Validation is something that happens to suggest that the release is good for the “current environment” while “approval” really indicates that the release is good enough for a “future environment.”
  • Acceptance or Approval both are gatekeepers to prevent the releasing of a build to a new environment. When teams use both of these, it can be confusing which one is going to be used for tracking “ready for next.” I’d suggest “Approval” to be used particularly between Test and Prod as the “this is ready” as opposed to acceptance is “the environment is ready” for the new release.

I’d be curious if you have any other patterns of approvals/disapprovals or if you have used these states in other ways that defined above. Please comment and share.

Recreating TFS Shelvesets in New Environments

Invariably, when you work in the ALM field enough, you get your share of source code migration projects. Lately, I’ve had a few of those, and many of them between two separate Team Foundation Server instances. In the world of source code migration, often consultants will look to recommend either tip-only migration or the use of automated tools to essentially play-back all the changesets/checkins from the old system into the new one. The tip-only migration means to get-latest the code from the old, and check that latest version into the new system. Although typically far simpler, this approach of checking in a single latest version does have its complications. Lately, I’ve worked with several clients that have had invested in shelvesets that need to be brought over. In those cases, the teams had access to both the old TFS server and the new one at the same time. I had written up some instructions on how to do this easily for the developers so that they could bring over their own shelvesets at their convenience before the old system was taken down.

This approach is not-automated and requires the users’ participation, but is a decent option for small teams.

What you need is a developer’s local workstation with workspaces mapped to both the old and the new TFS servers.

  1. Ensure that a local workspace for the old environment is mapped and up to the version of code that your shelveset is based on (often this is “latest”). At this point, TFS believes that the local workstation has the latest version of the code.
  2. In Windows Explorer, navigate to that location and Delete everything under the workspace mappings to that the folder itself is empty. TFS may detect that as a bunch of deletes, but that’s okay.
  3. Unshelve the shelveset to be migrated. At this point, the old workspace’s folders should only have the shelveset files in it.
  4. Paste that set of files into the new workspace in the right place in the folder structure.
  5. If using VS 2012 or VS 2013, Open up the Pending Changes Window and ensure to promote those changes that should show up now as Pending Changes.
  6. If your original shelveset included any deletions, the developer will need to go perform those deletions in the new workspace as well.
  7. Shelve the changes.

At this point, you should have a shelveset mapped to the correct folder path in your new environment ready to be used by the developer.