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.
Last year I wrote a short article explaining what Agile development was about and how some people generally miss the point and assume that to be Agile you have to follow something like Scrum. This article pointed out that Scrum was merely a project management tool for helping you to be agile. With this in mind, there are still a lot of misconceptions about what it is to be Agile, so I thought I would list down some of the ones that I have heard and counter argument them.
Agile is ad-hoc, with no process control
To be properly agile you need to adhere to the agile manifesto, but following the manifesto doesn’t mean you are using a defined process. The manifesto describes a set of ideals. There are various different processes and project management templates that you can apply to your projects to help you become agile. Extreme Programming (XP) and Scrum are the most popular.
When you try to implement the manifesto items you generally need to apply a lot of common sense and pragmatism to get to your goal, but if you want to wrap a more formal process around the ‘How’ of agile as opposed to the ‘Why’, then you would apply something like Scrum, which gives you more formal processes like epics, stories, iterations, stand-ups, demo’s, retrospectives , test driven development, pair programming etc.
Build the right Product – Using a continuous deployment model helps to ensure you develop the right product by ensuring you get rapid feedback from your business partners and stakeholders.
Earlier Benefits – Continuous delivery enables you get benefit out to your business/customers earlier so they can take advantage of features sooner rather than later in a big bang deployment.
Ability to React Quickly and Respond to Change – If youhave a continuous delivery system set up and are used to deploying continuously you can respond to changes in requirements more quickly or fix and deploy bugs sooner.
Innovation – The continuous delivery process enables you to work closer with the business. This closer working relationship means you have different kinds of people and skillsets working closer together. This can lead to different perspectives on problems which can lead to innovation.
Reliability and Stability – If you release your projects continuously you are repeatedly exercising your deployment process. This continual deployment and the fact you can react to change quicker leads to more reliability and stability.
More Efficient / Save Time –By automating your deployment process you can make your development team more efficient as they don’t have to deal with deployment issues as often leaving them more time to work on the good stuff, writing code!!!
Strategic Impact – A combination of all of the above gives you a strategic advantage over competitors as you can release more features sooner and fix problems sooner.
I can’t stress the benefits of getting continuous delivery working. If you are working on a new project and don’t have to deal with legacy code/systems then this is easier to achieve. If you have to deal with a huge knotted legacy estate like my developers have had to do, then getting a good continuous delivery pipeline running is harder, but can be achieved in stages.
This is what we did. We got automated builds going, and then had installers being built at the end of the builds. Then we worked on the tools for deploying to different environments. We have continuous delivery working into test environments but our next stage is to get this working for production deployments.
This is made harder for us as being part of an American Financial institution we are subject to the Sarbanes Oxley regulations which mean we have to have clear separation of concerns between development and production system, but we are looking to tackle this.
There is a very good book about this subject that I highly recommend reading. The book is called Continuous Delivery by Jez Humble and David Farley. Currently with the team I work in we are using TFS and its built in tools to manage our continuous delivery process with an auto deployment tool written by some of the guys on my team, but we are considering moving to just using TFS as a source repository and using Team City + Octopus Deploy to manage builds, packaging and deployment.
Recently, I have been doing lots of recruitment for .NET consultants. Each of the CV’s we receive all stress that they are experienced in working in agile development shops. This is great. We are an agile development company so these people sounds like a great fit.
So we get them into an interview and ask them, ‘What does agile mean?’, ‘How do you know if your team is truly agile?’ It’s at that point we get the standard list of responses:
We do Test Driven Development.
We pair program.
We use continuous integration.
We use SCRUM, KanBan, XP etc.
Use work in iterations.
We use story points.
We calculate team velocities.
These answers are all well and good, but they don’t describe what an agile team is. These are all just facilitators to being agile. What’s even worse is that these interviewees seem to have not heard of the agile manifesto.