Continuous Delivery Pipeline
I was talking to my colleague Carl Bruiners about continuous delivery the other day and he drew me this diagram. It doesn't contain anything radical but I'd never really thought through how it should hang together and found this really useful. It also made me realise the importance of Config Management and that this area is often overlooked.
Source Code Management
SCM is the starting point for continuous delivery. Whilst keeping source code in a repository should be standard practice there are a surprising number of projects that mess around with clumsy solutions to the problem of sharing and storing code.
Continuous Integration
Continuous Integration servers monitor source code repositories for changes and trigger a build each time the change is made. As part of the build they can run any integration tests, unit tests and source code analysis. Having continuous integration allows software teams to work on fewer branches and to take away the risk of integrating code. Good CI should make the status of a build visible and a broken build should be fixed immediately by the team/person who broke it.
Config Management
Config management enables automated tests to be run in a consistent environment. The config can relate to both hardware and software and allows an environment to be spun up and for the build to be deployed to this environment.
Automated Tests
These tests are used to verify that the build works. They need to be run a consistent, stable environment. The tests should be repeatable.
Continuous Delivery
This step is pretty straight forward. Continuous Delivery is the process of taking a verified build and making it available to be deployed.
Continuous Deployment
Is the last step and involves automating the deployment of the verified build.
Dirty Words
I'm becoming really conscious of the language I hear myself and others use in conversations at work. I fear that certain words act to reinforce negative perceptions, behaviours and attitudes. In this post I'll discuss some of the troubling language that I encounter everyday.
- "The business" - How many times do we hear this each day? I often hear myself saying sentences like "Let's go and ask the business". The problem I have with this is the fact that I am also part of "the business" but using it in this context makes it sound like "the business" is some group with an agenda that is different to mine. In reality the whole business (myself included) should be united in striving to delight our customers. If this isn't the case then there is likely a problem and this language might be a symptom.
- "Resources" - So I'm not the first person and I'm sure I won't be the last to point out that people are not resources, that can be moved from here to there. squashed and bent to fit into a space, cut in half because they are needed in two places at once or upgraded at the click of a button. Unfortunately this doesn't stop business lexicon from replacing the word person with the word resource. Whatever the reason may be for the need to dehumanise our teams. I think dehumanising them is a mistake. If you are having problems with the moral of your resources it might be worth asking; are you treating them like people.
- Agile/Scrum/Zomblatt - Empowering self organising teams to frequently deliver valuable software by collaborating closely with customers and stakeholders, whilst getting ever better at doing it. Is a great thing! It doesn't need a name. It doesn't need preachers. It doesn't need certifications. It doesn't need standardising. Words like Agile mean different things to different people and I think this does a lot of damage to organisations. At the end of the day it doesn't matter how agile you or anyone else perceives you to be. What matters is that you get better at what you do and you focus on delighting customers with a constant flow of great software. Removing the buzzwords will allow people to focus on living the principles rather than fighting crusades.
This post will probably evolve over time. Please let me know some of the dirty words that you think we need to purge from our collective vocabulary.
Making technical debt the new rock and roll
My new team at ASOS are working from a backlog of technical debt issues. These are basically issues that are having an operational impact on the organisation. The problem with this work is it is largely thankless tasks concerned with refactoring legacy back office code. When faced with such work for a long period a team is likely to get demotivated and disillusioned. I've been trying to find ways to prevent this from happening.
My main approach is going to be to be making the value in the work extremely visible to the team. I've been working with the product owner to really understand the cost each issue has on the business. I've then put up a Blue Peter appeal style thermometer to display the value the team has delivered in the current release. The idea being that team can see that they are making a real difference to the organisation.
I think this is a good start and will help to prevent the team getting demotivated but for me the overall goal will be to find a way to make visible the impact the team's work has on our customers.
Sorry for going AWOL
So I've been a bit busy over the last few months and unfortunately not really had to much time to blog.
To give some idea of what I have been up to here is a summary.
- Changed jobs - I've left Experian and have also left the land of software development to take on the role of Scrum Master at ASOS.com.
- Moved House - We've moved to a great Victorian property with lots of space and bags of potential.
- Agile Cambridge - I ran a session looking at routes into agile coaching.
- Bathroom fitting - Our first project in the new house has been really challenging and fun. I've had the chance to learn lots of new skills and also to apply some agile principles to a different context.
Hopefully life is starting to calm down a bit and I can get back on the blogging wagon.
Embracing Change with Real Options
Embracing change is a phrase you here a lot in agile circles and indeed you should, it is at the heart of the agile movement. Lately I've been giving change some thought as I meander through fitting a new bathroom at home.
I used to think that change in software is easy compared to change in other forms of engineering and construction due to their physical nature, but when you think about this it doesn't make any sense. It simply isn't true that you can't change the design of a bathroom once you have started it. It also isn't desirable to make big changes to software once it is written.
So what do we do to cope with change? The answer is simple. We should try to limit changes by spending our time collecting options and only making a commitment when we absolutely have to at the "last responsible moment". When a commitment is made it will affect our current options and also help us to uncover new options. In short the best way to embrace change is to prevent having to make it in the first place.
This is summed up nicely by Chris Matts and Olav Maassen in their work on Real Options
Agile Detention: I must limit work in progress.
I was reminiscing over the weekend about my school days and the few times that I ended up in detention. Invariably this would result in a group of us being asked to write out lines. As I remember it there were two schools of thought in the play ground about the best way to tackle the block of lines. The first approach was to complete the lines a line at a time. So you would complete a line before moving on to the next. The second method was to work your way down each line a word at a time. For instance if you had to write out I must limit work in progress five times then you would start out writing I on each line before moving on to must and so on. I seem to remember this second technique producing lines that were very inconsistent in appearance.
This thought gave me an idea for a game to demonstrate some of the benefits of limiting work in progress.
Agile Detention.
Put two people on detention!!
Ask each of them to write out on a board "I must limit work in progress" 10 times. Ask person A to complete the sentence before moving on to the next one. Ask person B to write the first word of each line before writing the second word of each line etc.
When the person writing whole lines completes their 3rd line announce that you have changed your mind, that 10 lines seem a bit harsh and that they are free to leave after completing 5 lines.
When one of them completes five lines stop the exercise of follow up with a debrief.
Some good questions to ask when debriefing include.
- What was the lead time of the two approaches?
- When writing software do we often get interrupted before we have absolutely completed something?
- As the teacher how much confidence do I have in a student who has completed 0 lines in the same time one of their peers has completed 5 lines?
- What will happen to the words person B has written on lines 6-10?
- Compare the quality of the two sets of lines.
Having fun while learning about other teams.
I'm currently trying to bring together three dev teams from within our organisation. All three teams brand themselves as agile and all three produce products around the same domain. It therefore seems like a good idea to get the teams together to share ideas, understand what each team does, how it does it and to look at how our products could work together to improve the lives of our customers.
While this is a good idea, I do sense a real danger of two days packed full of dull, dreary powerpoints. So the challenge is to create an environment for the gathering that is fun, energetic, engaging and creative.
My first thoughts were to have each team present information about themselves and then to follow these presentations with an afternoon of open space which will hopefully follow on from points made in the presentations. The open space should tick the fun, energetic, engaging and creative criteria but I fear the presentations still wouldn't.
I then had the idea that instead of presenting about themselves each team could present about one of the other teams, about who they know very little. In doing this it would take people out of their comfort zones, ensure that each presentation was interactive, unpredictable, collaborative and focussed on extracting the information that the group actually care about.
I'll post a blog in the next few weeks to let you know how the idea develops and how the gathering goes.
The first rule of Agile.
"The first rule of Agile... is don't mention Agile." - John Stevenson
Looking for a Scrum Master? Check the ears!
This is Graham Rowntree or Wig and he is one of the top (rugby) Scrum coaches in the world. As a player he has won just about everything there is to win and is now enjoying life as the England forwards coach. Watching the way England dominated the Ireland scrum on Saturday I would suggest that Wig is pretty good at his job.
The question is why was he given the job in the first place? Was it down to him having a big shiny coaching certificate, was it down to his knowledge of the game gained through years of playing at the highest level(Check out the ears!) or was it down to the way he can develop, motivate and impart his knowledge to the rest of the team? I suspect that the answer is that all three points played a part in him being offered the job but I also suspect that the certificate was probably the least important.
For me a worrying side to the agile community is the ever increasing importance being placed on certification. We see not for profit organisations such as the Scrum alliance churning out trivial certifications that are losing value by the day. We also see the recruitment industry mandating certification as an essential part of being a scrum master, an agile coach or a trainer. With people assuming certification is a sign of quality we are on very dangerous ground and it won't be long before Scrum and Agile are dirty words through failed implementations and a lack of understanding.
I'm not arguing that certification doesn't have a value but I feel that practical skills, knowledge and experience hold more value. Now if only I had some kind of manifesto to pin it on to.
Crewing up – self organising bomber crews.
I recently watched the Ewan McGregor documnetary on the role bomber command played in the second world war. The program was shocking on a number of levels but an unexpected surprise was the revelation on how the crews were formed. I had never given it much thought but just assumed that teams would have been formed by the military hierarchy and team members would have had little to no input into the makeup of their team. It turns out that bomber crews were self organising, air men of different skill sets were put together in a hanger and left to form up into their own air crews. Listening to the veterans being interviewed it was clear that the bonds they formed with their team mates were extremely strong. It is not always natural to pull together in a team when placed in a hostile environment and I am sure that having been empowered to decide on who your teammates were helped the airmen to gel as a team and tackle the appalling situations they encountered during the war.
There is a good clip here from another documentary about "Crewing up".