What are the Business Benefits of Being Agile

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

Lots has been written about the benefits of Agile methodologies and Scrum for the development team. Articles about the agile manifesto and scrum have encouraged developers to think about iterations, user stories, backlog items and delivering value with rapid defect feedback, but at the end of the day, what’s in it for your business?

Agile has Many Benefits for the Business
Agile has Many Benefits for the Business

In this article I am going to think from the businesses point of view. What’s in it for your business? They don’t really care about iterations, continuous delivery, unit tests and all the other good stuff us developers love. They care about their business and competitive advantage. Especially if there is a danger of a young start-up being disruptive and stealing market share from under your feet.

Technical Debt Analogy

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

I was reading a book called ‘Software in 30 Days – How Agile Managers Beat the Odd, Delight Their Customers, and Leave Competitors in the Dust‘ by Ken Schwaber and Jeff Sutherland , and there was a fantastic analogy that summed up technical debt, which I wanted to quote for you here.

As technical debt grows it becomes harder and more expensive to fix over time.
As technical debt grows it becomes harder and more expensive to fix over time.

In cold climates, when the temperature drops, the pipes in houses often start knocking. Whenever you turn the water on at the tap or use the washer or dishwasher, whenever the heating system starts up, the pipes start banging against one another, against the framing, and against the walls. Sometimes they sound like a jack-hammer, especially when they start knocking in the middle of the night. Knocking pipes are hard to fix. They rattle because they weren’t properly secured. When they become loose and knock, precisely locating them is difficult.

The knocking may be happening at a different place from the insecure pipe. Over time, they become looser. It is difficult to find the exact place where they should have been secured, as the noise may be located a short distance away. Frequently, you have to make a large hole in the wall, remove any insulation, and start looking. Then, with a little luck, you can secure the pipe properly. The cost of securing a pipe correctly when it is installed differs minimally from securing it incorrectly. The cost of securing it once the building already has been constructed is much higher.

There is a powerful lesson here in that you should try to build your software as best as possible from the start. If you start making compromises in the design and testing, then you will create technical debt which you will have to pay back later, but you always end up paying it back with a lot of interest.

Velocity is Not a Goal or Target

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

I was listening to an episode of the DotNetRocks podcast about Agile Metrics. There was an interview with Michael ‘Doc’ Norton about his experiences figuring out the right metrics to measure for the productivity of a development team. The basic issue discussed was that Velocity is a dangerous metric to rely on as a goal or target.

Agile Velocity is a Dangerous Target
Agile Velocity is a Dangerous Target

Velocity is a measure of units over time, so in an agile iteration or sprint, that would be the number of story points completed in the iteration. This is a dangerous metric because it is misleading to management. One week, your team may complete 10 story points in the iteration. Management may then say,

“Well, that’s great, if you can better that to say 12, we might finish early.”

The team, then starts their next sprint, aiming to complete 12 points, but they end up only completing 5. This is like a red rag to a bull to management, but this could be a valid scenario. The velocity of 12 from the previous sprint may have been achieved because all the development tasks where contain within the development team. If as part of the next spring you need input from other teams or departments, then this could affect your ability to get work done as planned. This just one example of an external influence affecting velocity, you could have people go of sick, on holiday, or anything else that can happen that is out of the teams control.

It is because of these external influences that the velocity metric becomes a bad metric to rely on. There is just too much variability in the numbers from sprint to sprint. This doesn’t mean you should ignore velocity completely, but managers should not ask teams to hit targets based on velocity.

High Level Overview of Agile

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

The following video is a really good high level overview of Agile and Scrum. The video is by Ken Schwaber (One of the originators of Scrum). There are lots of Agile and Scrum overviews out there, but this one was particularly good. The video is only 20 minutes long, the sound isn’t great, but the content is spot on.

If you are trying to convince your manager / company / colleagues that Agile is a software development methodology worth following, then this is a good video to show them. The video talks a lot about responding to changes in a market place and how being Agile can help you maintain a competitive advantage.

Post Deployment Smoke Tester Version 0.02 Released

Smoke Test Config Editor
Smoke Test Config Editor

I have released an update to the Post Deployment Smoke Tester Tool. This version mainly includes new test types. The new tests added are:

    • MSMQInstalledTest : This test checks whether the MSMQ messaging service is installed on the server you are running the tests from.
    • MSMQLocalQueueExistsTest : Check if a local MSMQ private queue exists.
    • MD5ChecksumTest : Check an MD5 digest of a file. This is for file integrity checking.
    • SHA1ChecksumTest : Check an SHA1 digest of a file. This is for file integrity checking.
    • SHA256ChecksumTest : Check an SHA256 digest of a file. This is for file integrity checking.
    • WindowsServiceExistsTest : Check that a windows service exists in the machine the tests are running from.
    • WindowsServiceStatusTest : Check the Status of a windows service, Running, Stopped etc.
    • WindowsRemoteServiceExistsTest : Check that a windows service exists on a remote machine.
    • WindowsRemoteServiceStatusTest : Check the status of a remote windows service, Running, Stopped etc.
    • IISInstalledTest : Check that the IIS web server is installed on the machine the tests are running from.
    • IISRunningTest : Check that the IIS web server is running on the machine the tests are running from.
    • IISVersionTest : Check the version of IIS that is installed.
    • IISDoesWebsiteExistTest : Does a website exist in the instance of IIS.
    • UserInActiveDirectoryTest : Check that a user is in Active Directory for a domain.
    • NetworkPingTest : Ping a network address.
    • AssemblyVersionNumberTest : Check the version of a names .NET assembly.

The Smoke Tester Solution Structure and your First Test

Recently I open sourced a very useful tool called the Post Deployment Smoke Tester. The Post Deployment Smoke Tester is a tool that allows you to run a suite of tests on your environment after you have deployed a piece of software. These tests are invaluable in a large corporate enterprise as more often than not, the people who are doing your deployments are not the original developers.

Out of the box the tool contains many tests that should be immediately useful to you, but you may wish to add in your own. It is early days for this tool so we wont have provided everything that is possible out of the box. If you do need to add in a new test type then you can do so very easily.

If you do want to add or amend any of the tests, then this short article will help you navigate around the Smoke Tester solution structure.

The Smoke Tester tool is split into 4 main components. TestConfiguration, InstallationSmokeTest, ConfigurationTests and CommonCode. The relations-ships between these 4 modules are shown below.

Architecture Diagram for the Smoke Tester Modules
Architecture Diagram for the Smoke Tester Modules

Both TestConfiguration and InstallationSmokeTest are your test editor/runners. Generally you won’t have much need to change these unless you want to add some extra functionality. You main areas of interest will most likely be the ConfigurationTests and CommonCode assemblies. This is where you modify or implement new test types.

Post Deployment Smoke Testing Open Source Project

I have just released a new open source project called the Post Deployment Smoke Tester. This project has been a collaborative effort between a number of fellow developers in response to a typical enterprise software development problem, getting rapid feedback on the success of your deployments into production.

This tool has literally saved my teams bacon a number of times, and maybe it can help you too.

The credits for this toolset are as follows:

Open Source Release : Stephen Haunts

Original Author : Hugh Phoenix-Hulme

Contributors : Stephen Haunts, Jon-Paul Flood, Daniel Steele, Oliver Sintim-Aboagye, Mark Jones

The all Familiar Problem

For anyone working in an Enterprise Software environment, I am sure you have all encountered the same problems. You finish your development and testing. You package up a release and prepare all the release documentation for the operations team and submit the change request into your Change Request system for approval. Then the release is deployed during your standard outage/change window, normally at an ungodly hour of the night.

Smoke Test Config Editor - Results
Smoke Test Config Editor – Results

The people who do the deployments generally have no knowledge about what they are deploying, they will just follow the change instructions that you have written. You will normally only really know if the release has been a proper success once your users get their hands on it the next day. In some businesses that can be a big risk if an outage or problem with the system has a financial or customer service impact.

%d bloggers like this: