• All
  • Agile
  • Agile Adoption
  • Agile Organisations
  • Coaching
  • JAFAC
  • KanbanFor1
  • Product Development
  • Product Owner
  • Retrospectives
  • Scrum Master
  • Self-Selection
  • User stories
Read More

How we measure output and productivity

 

… getting more stuff done

 

At Trade Me we want to measure the overall health of Tech (that’s our team of 125 designers, developers, testers, BAs, and Squad Masters) to identify trends and to know if we are getting better (or worse!). We know that when we measure something it is a strong way of saying “This matters” which is why we put a lot of effort into deciding which metrics to collect.

 

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.

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 …