As you know, I’m a big fan of agile software development. But what exactly does “agile” mean? If you ask a room full of software engineers that question, you’re sure to get as many different answers as there are people. I’m not going to try to tell you what agile is, or what it should be – but a lot of people ask me how our team goes about implementing agile. We don’t practice any particular official brand of agile – like most good teams we’ve combined all of our past experiences to come up with something that works well for our project and team. So I’m definitely not claiming that this is the “right” way to do agile or that it will work for your team. However I’m also not going to accept any arguments that what we’re doing is “wrong” (since it works very well for us) – although constructive suggestions are always welcome!
To provide a bit of context, I’m working with a dedicated software engineering team that is part of Microsoft’s Solutions Development Centre in Sydney. We have been building a large new system for an external customer for the last 12 months or so. It’s largely a greenfield project, but there are a handful of external systems we need to integrate with. The application is in a new business area for the customer so their requirements have been evolving constantly, especially after development began. The project team consists of 2 project managers, 1 solution architect (me), 5-9 developers (the numbers have changed a bit over time), 4-7 testers, a build manager, a release manager (just for the last third of the project), and part-time SMEs focusing on infrastructure, security and database. We also have a full-time product manager from the customer, and around 3 other customer representatives that spend at least a day a week with our team.
The project began with an end-to-end analysis and estimation phase, which lasted a couple of months. While this does not fit in with many people’s idea of agile, I believe it’s a necessary step for commercial projects (and probably worthwhile even for internal projects). The goal of this period was to get as good an understanding as possible of the business requirements (as they were understood at the time) in a relatively compressed time period. During this period the team produced UI wireframes, flowcharts and very high level requirements and design diagrams. Doing this estimation allowed us to provide a reasonably good estimate of the schedule and budget for the overall project (even with the full awareness that many, many things would change throughout the project). It also helped us identify the most important and most risky areas so we could schedule them in the most appropriate iterations.
Once the estimation phase was out of the way we started our development iterations. We settled on 4 week iterations, involving 3 weeks of development and one week of stabilisation. Here’s how we tend to approach each iteration:
Hopefully this gives you an idea of the rhythm of our iterations. However we also have a daily rhythm within our team room:
I hope this gives you some insight into one way of using agile methods to deliver a complex project. As I mentioned at the start of the post, this isn’t textbook agile, and we’ve needed to constantly evolve our process to address various challenges and to suit the personalities and experiences of our team. However I’m very happy to say that this is the most passionate, energetic and productive team I’ve ever worked with, and despite the fact that the requirements continue to evolve at what often seems like a frightening pace, we’ve continued to hit all of our milestones and targets. So I hope some of this will be of use to your team as well, and of course I’d love to hear about what you do differently in your team and how it’s working out for you.
PingBack from http://www.markscottjohnson.com/blog/post/My-Current-Project.aspx
What an awsome story of agile by Tom Hollader he wrote " How my team does agile " He told about
You didn't mention TDD or pair programming. Do you do those?
Alex - we don't mandate either of these, but both occur to a limited degree. We do place a lot of importance on quality unit test coverage, but we don't make a big deal about whether the tests are written before or after the code.
Thanks for sharing Tim! I love real world applications of agile on large projects - which always requires a bit more customisation than standard textbook scrum.
A good read! I've always felt the 2 week cycle is too short, and the 4 week too long. So we settled on 3 week cycles. Although I think you’ve addressed the length of the 4 week cycle with the 1 week mini-iterations for developers.
“Bug Bash” is a great idea -nothing gets people involved like food and prizes!
I noticed you have a build manager and release manager – in my experiences usually the build manager is responsible for the release. Would that not work for your projects?
Arian - there are definitely overlaps between the build manager and release manager's responsibilities. However for this specific project the application is being deployed into a brand new environment, and the amount of work required is enough to justify a dedicated release manager. However I agree that this isn't going to be needed for all projects.
Great post.. thanks for going into such detail.
Another batch of Interesting Scrum and Agile Blog Posts:
Interesting implementation Tom. Can you elaborate how product manager confirm tested requirement?
Do you release to real customer every single iteration?
That's great to learn so detailed developing process, as I work as an in house developer I rarely have opportunities to work on projects which requires such planning and order. It would be nice if you'll drop some technical architecture details sometimes
Kulawat - we actually encourage the product manager to verify requirements as soon as they are built and tested, even if the iteration is not complete yet. Every daily build is deployed to an internal test server, which is used primarily by the testers and the product manager.
We do have a formal release at the end of each iteration. For this specific project the customer did not have suitable deployment infrastructure in place for most of the project, so the release is done in the form of a CD containing the software and docs. So while each release is "deployable", it wasn't actually deployed to the customer's environment for most of this project.
However in the more common situation where the customer does have a suitable environment it would be preferable to deploy each release so it can be accessed by a larger user community.
Great post! I'm about to start a greenfield re-development of a software application (so no legacy code is coming over) and we have used Agile for much smaller projects before. I have similar size / structured team as you have described but we are tasked with looking after the old one; whilst building the new one!
How would you see supporting a older version of product whilst running a productive agile greenfield development.