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?
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.
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.
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.
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.
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.
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, ConfigurationTestsand CommonCode. The relations-ships between these 4 modules are shown below.
Both TestConfiguration and InstallationSmokeTestare 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 ConfigurationTestsand CommonCodeassemblies. This is where you modify or implement new test types.
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.
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.