Read More

Release sprints

To get our code to production what is left to do is to turn the “potentially” releasable product into a releasable product. To do this a number of activities are required: Which ones and how much effort they require varies greatly between types of organisation. 

The fastest way to perform rollout activities is to do them within the development team and to automate as much of the process as possible. While I envy and respect teams that are mature in terms of test and deployment automation and operate in an organisational context that allows them to easily move code from environment to environment I find that this is very often not possible within larger organisations. 

Often, among other activities, someone outside the team has to be instructed as to how to deploy code, other parts of the organisation have to be informed about the changes (eg. end users, operations and maintenance teams, etc), and manual regression testing has to be performed. 

For the kind of large organisations Mike Cohn refers to in his description of a bank with COBOL code and no automated regression testing or large organisations new to Scrum and Agile I, too, find this is best done within a so-called release sprint.

How story points work

One of my clients is a small software development house that does custom development in the form of development projects for clients . I helped them to successfully introduce Agile (Scrum with XP) and both the team and business managers are really happy with it. 

As they liked our methods of planning and estimating (story points and velocity) the account managers and sales team were discussing the options to relate story points to dollar values. 
 
To explain why I think this is very risky and not advisable I wanted to give them some background.
 
“How big” vs. “How long”
Story points are units that are used to size a piece of functionality or work. Sizing in this case means that story points indicate “how big” a piece of work is. 
 
This is often confused with “how long” it takes to implement it but in fact “how big” and “how long” are very different things:  

  • The “how long” is highly dependent on which developer is performing the work 
  • The “how big” bears no relationship to who is performing the work

 

When the red bus hits: Agile when things go wrong

There’s a saying in software development “If someone gets hit by the red bus … “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project. 
 
Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions. 
 
But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money. 
 
In this case one of two things normally happen:

  1. The project goes on with fewer team members
  2. The project gets canned or put on hold

 

Waterfall

This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology:

How to pick a Scrum team

I was recently asked by a friend how to pick an Agile team. 
 
My friend is a project manager within a New Zealand government department and to deliver an important project he was given complete freedom of choice with regards to project methodology and people.
 
He chose Agile and Scrum as a delivery framework and needed 8 people to form his dream team. The big question was which people to pick and which skills to focus on. 
 
I’ve never been fortunate enough to pick my own scrum team. Normally, I get a certain degree of choice and then a combination of who happens to be available and people who I really, really fight for. And sometimes I fight to avoid getting someone on the team. 
 

Tools: Mingle – the new kid on the block


 

Mingle has received a fair bit of attention lately and the latest version, 2.1, has just been released.
 
I’m quite happy with Rallydev but as Mingle is made by Thoughtworks themselves and the guys at Silverstripe keep raving about it I thought I’d better check it out. Also, as much as I like Rallydev and VersionOne – they’re both a bit weak on the usability side. 
 
Below a list of what I like and dislike about Mingle:
 
Things I like:
 
1. Installation & Support

  • Free web/phone conference with a Mingle representative to guide you through configuring the system after you have received a free hosted trial. Very helpful!
  • A breeze to install the downloadable version
  • Runs on all operating systems (incl. Max OSX, Linux and Open Solaris) and most database systems incl. Postgres

When not to run Agile

People keep asking me whether I’d run all projects using an agile framework such as Scrum. 
 
When I answer “of course not” they often not only expect but gently try to steer me towards an answer that excludes certain type of projects: “You certainly wouldn’t use it for a mission critical system, would you? Or a compliance project? Or an infrastructure project? “
 
Actually, yes! I have used Scrum for business critical systems at a major mobile phone manufacturer, have implemented mission critical systems for a publicly owned European Rail Cargo company, a friend of mine has successfully delivered a compliance project and another one has even developed fighter jet control systems for a European Air Force using scrum. 
 
It’s not about the type of project. It’s not even about the size of your project. It’s about whether you’re willing and able to create a setup that allows agile projects to succeed. To me the rather vague terms of organisational and cultural readiness can be narrowed down to a list of primary show stoppers: 
 
I’d NOT run agile if …