I’ve just finished reading an excellent article on Continuous Deployment. This is the way of the future. Now that Continuous Integration has become (almost) mainstream and as expectations for services to be “always on” becomes the norm, the interest and demand for practices such as Continuous Deployment (CD) will increase. With CD, the cost of rolling out an update is very nearly zero* because deployment and releasing is fully automated.
I first had a discussion about Continuous Deployment with Rupert Perry the CEO of Pirum Systems. Rupert is a first rate developer and wrote the first version of their systems with the CTO. While we were discussing some of the advantages of Continuous Deployment, Rupert told me a story. He was in a clients office trying to make a sale and was demonstrating the live system to the potential clients. The client wanted to sort by a particular column. Not having worked directly on that particular function, Rupert said “Let’s try it.”
The function failed … but here is where the story becomes interesting. The developers who were monitoring the system noticed the failed function. It wasn’t a lot of work on fix the problem, so they coded, tested and deployed a solution. Knowing that Rupert was seeing a client they gave him a call and asked him to demonstrate the function again, which he did successfully. The elapsed time for all this was in the order of 15 minutes to 20 minutes.
Oh, and Rupert made the sale!!
* It’s not quite zero because there’s a cost involved in initially building and configuring the CD system.
Filed under: Agile Software Development, Patterns, Technology, Web 2.0 , Agile, Agile Software Development, CD, CI, Continuous Deployment, Continuous Integration, Extreme Programming, XP
Personal Comment: I started this article about 5 months ago and it’s just been sitting in my queue. I’ve been undecided about publishing because I’m not especially fond of it. But rather than let the bits rot, I thought I’d share it in the hope that someone will get some benefit out of it. If you find this interesting or helpful please leave a comment. Thanks.
The concept of “dog fooding” your own products has been around for a long time, and has been made famous my Microsoft who are rumoured to practice “dog fooding” their products as a regular part of their culture. What is dog-fooding?
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Technology
This article is about my further understanding about Agile software development. As I my understanding of Agile software development has increased, so has the conflict between my established ideas and what I now see happening in the real world. The latest casualty was my belief that having repeated code or components is bad.
I was greatly influenced by Bertrand Meyer’s [1] book Object-Oriented Software Construction [2] where he presented the case of reusable software components. It could be argued that reusable components are with us now in the form of large frameworks, but my understanding of his vision (reuse of fine grain components) never fully came to pass.
The original impetus for this article was a conversation that I had with Ken Everett. He described the logging scenario that I use as the example for this story. His argument was that for a large team using more than one logging framework was not a bad thing provided that the code quality was good and that it met the business functionality. I absolutely agree. I also wondered, when was the latest responsible date at which point a decision needed to be made?
Read the rest of this entry »
Filed under: Patterns, Technology
The Enhanced (or Alternative) Release Burndown graph [1],[2] is a great tool and one of my personal favourites. It demonstrates several things very clearly. It demonstrates:
- The rate at which work is being completed by the team
- The rate at which new work is being added to the product backlog
- And, it can be used to determine a date range for completion.
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
This first appeared on the ScrumAlliance.org website on October 30th. It is presented here in its original unedited form.
Burndown graphs are commonly used in Scrum projects to give the team an understanding of the amount of work remaining for the Sprint (or iteration). In Ken’s own words:
“As a team works together, it develop its own style of creating and maintaining the Sprint Backlog. It also demonstrates unique work patterns, some working consistently, some in bursts, some at the end of a Sprint. Some seek pressure, while others seek regularity. Across time, the backlog charts of each team develop predictable patterns. They stabilize as the team learns the technology, the business or product domain, and each other. These chart patterns are called Sprint signatures.” – ControlChaos.com [1]
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
Selenium [1] is a nice tool for testing browser based user interfaces. It’s simple to install and with the firefox IDE plugin, it’s even easier to use. But there are some tests that are just not accessible through a UI. Should you even test functionality that’s not immediately expressed, and if so how?
Read the rest of this entry »
Filed under: Patterns, Selenium, TDD, Test Driven Development
This is the second article that I wrote for the Scrum Alliance [3]. It was orginally published on July 24 and can be found here. The article presented below is the original unedited version with all my grammar and spelling mistakes!
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
Personal note: I started this article about 9 months ago. Although it’s quite a fun article, I have become increasingly critical of the use of analogies to describe software development. My feeling is that analogies lead to assumption that may, or may not, be valid. So, rather than talk about building a bridge, a house or cooking Thai food I’d rather talk about software specific problems or situations.
After some personal doubt I finally decided to complete the article because it is amusing, if not insightful. I hope you enjoy the article. In the future I’ll endeavour to keep analogies far, far away.
Mae Phim is a small Thai restaurant in Seattle [1]. I went there with my colleagues last year and we were impressed with their speed of operations. Within the space of a few short minutes, we were able to place an order and received a hot, freshly cooked meal.
Despite the short duration, it was sufficient time for us to wonder if there were any lessons here to use in Agile software development. After all, if we were able to deliver software as rapidly and with the same high quality as Mae Phim delivers food then that would surely be a good thing.
An interesting observation was that the business model for Mae Phim is common to the business model of other Thai restaurants [especially those that cater to the lunchtime crowd who present their own set of unique challenges]. This article discusses some of the characteristics of their operation and discusses the applicability (or not) to developing software.
Read the rest of this entry »
Filed under: Agile Software Development, Cultural Change, Organisation Change, Patterns, Planning, Project Management, Scrum
When introducing Agile/Scrum practices to a new team it’s common for the team to have very chaotic or drawn out meetings. Often the daily scrum will degenerate into a long conversation over topics that are of little interest to the team.
Long daily meetings are insidious for Agile teams. If the the team spends more than 15 minutes in a daily meeting they are more likely to stop having them. It’s important therefore to keep the meetings short and to the point.
Read the rest of this entry »
Filed under: Agile Software Development, Cultural Change, Organisation Change, Patterns, Project Management, Scrum
In my last blog I descibed the Iterative Waterfall anti-pattern. I described what the problem looked liked, a variation of the problem (the Staggered Iteratvie Waterfall anti-pattern) and some of the reasons for how these anti-patterns evolve.
This week I would like to discuss how to avoid these anti-patterns and, if avoiding them is not an option, how to move a team from this model of software development to a model that is more closely alligned to Agile methodologies [such as Extreme Programming (XP) and Scrum.]
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
Foreword: This blog entry was originally intended to be a single article. In writing it I found that I had trouble trying to communicate all the information in one sitting. As a result I’ve decided that this will be a 2 part article. The first part (presented here) discuss the Iterative Waterfall pattern and the reasons why this pattern of software development process is detrimental. In the second part I’ll discuss possible approaches to moving away from this pattern.
Update: Dave Nicolette has written a great article that provides more context, from the both organizational and team point of view. It’s well worth reading and you can find it here.
Over the last 3 years I’ve noticed a reoccuring anti-pattern amongst companies trying to implement Agile. This has happened with development teams that are particularly experienced with RUP [for reasons that I'll discuss towards the end of this article].
There are two variations of this anti-pattern, which I’ve called Iterative Waterfall and Staggered Iterative Waterfall. The Staggered Iterative Waterfall anti-pattern is simply the Iterative Waterfall anti-pattern taken to it’s extreme. Throughout this article I’ve used the term Iterative Waterfall to refer to both variations except in situations where I need to distriguish between the two.
So, what are the characteristics of these anti-patterns?
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
Recent Comments