Agile Track Record

Agile Transformation

We have introduced agile methodology in large-scale roll-out engagements, and in point projects, coaching exercises and capability assessments. 

We found that in order to get agile methodology adopted, you need to sell not only the good bits (less panic, higher quality, predictable delivery dates, flexibility to change, happy people, etc) but also be clear about the hard work required to get it right (team ownership, peer pressure, product owner, TDD, continuous integration, definition of "done", higher short-term cost, not getting all you want, etc).

Lessons learnt

• Don't assume anything. In this type of engagement we have been both horrified (at lack of understanding and unwillingness to participate) and happily surprised (by the resonance and feedback from both developers and the business).
• Keep explaining, keep repeating, keep on. You need to make the "new way" of doing things a "normal way": it needs to turn into a habit.
• Keep it simple. The temptation to get complicated is high. People are like that. It is not always easy to see the simplest solution. But only simple will ever get "done", and work.

Installing Agile Methodology

We were responsible for training teams to use eXtreme Programming (XP) to support an entire business area. This involved teams doing not only web front-end development but also the operations end of the business.

The teams were scattered across the US, so we also had to sort out remoteness and collaboration issues. We achieved strong business buy-in, with the product owner spending much time in the agile pod area. BAs were also used as proxies to the business, to provide continuity.

The adoption of the new processes was a success, and the deliveries were excellent, with the business fully convinced of the power of agile, and the developers wondering how they enjoyed their jobs before it all came along.

Lessons learnt

• TDD is hard. It is such a shift from the normal inclination of development ("try it and see it work, later build in some tests") that it has to be drilled in very well, becoming a habit.
• Business buy-in is crucial. Without participation and constant feedback about how well things are going, you become your own appraiser, which is not a fair measure.
• Different locations are tricky. We dealt with the regional spread of teams by loose coupling. So a team mostly needed to talk to its own members often and with remote sites less frequently. Shape the work distribution to reduce the strength of cross-regional dependencies.
• Iterations rule! The iterative approach to scope determination and ongoing estimation by the team was tough at first, but really brought rewards for both business and developers

Agile: One Size doesn't Fit All

In another engagement, which was agile within DSDM, the XP process had to be adapted somewhat to fit in with the traditions and culture of the company.

Although this sounds scary, you do not need to lose the power and magic of agile in doing this. What it came down to was complying with the way project information/status gets fed to management, and turning the certainty of "on d/m/y we will deliver something, but we dont know what yet" into a more "predictive" statement like "phase 1 of company-product will be released on d/m/y, containing all must-have reqs and some extras".

Once we got over the temptation to be too loose about what was going to happen when, allowing the customer to decide, it was straightforward to join up with existing process.

Lessons learnt

• Allow people to adopt their roles, and take ownership. Coach rather than stipulate, let them become the master of their craft. Watch the magic spread...We found that many people, coming out of their comfort zone doing this, grew to prefer their new roles, and helped others to do the same
• Done is powerful. The benefits of TDD and "done" stories are immense. They are jewels worth digging for, despite the pressures from everywhere else that say "we need it now, and don't ask what it is".
• Automation is your friend Don't underestimate the power of test automation: sometimes it is all you have left to backup the correctness of what you have done. An automated suite is golddust, however incomplete it is, so start building it right at the beginning!
  

Agile: Leveraging Scrum

Scrum is now the primary flavour of agile used in most companies. It is easy to understand, but also easy to do wrong. It needs mastering.
The key to Scrum is adherence to the few simple rules, and the strength of character of the Scrum Master in ensuring the team understands how to follow them. But the notion of "done", TDD, automation, estimation and velocity of a team are still as hard to cope with as ever, and therefore it is vital to have the right guiding force behind it.

We have experience using Scrum in

1. A software upgrade project
2. Testing a system to be rolled out using three team locations
   
3. Guiding a change programme
   
4. Managing many disparate pieces of work

We have also coached and provided assessment of capabilities in Scrum.

Lessons learnt

• Scrum is easy to do, but it is easy to miss the agile benefit. The Scrum Master role needs to be played diligently, and the other roles (Product Owner, technical lead, QA) also need to be there, with each taking ownership for the roles' integrity
• No Product Owner, no Direction. If the Product Owner role is half-hearted or not a business engagement, the Scrum team loses both direction and the ability to react to events. It is vital to have this role and empower the business.
  
• Scrum is really flexible. Use for any task list: the concept of a "product" defining what needs to be done, and a set of "sprints" scoping for work for a fixed period of work-time is so powerful. It is of course basically no different from other agile approaches, but it is much easy to adopt the habit of agile using Scrum.