Our Experience with the  Web

Web Management

Running a web delivery department teaches you a lot about all aspects of IT, from the level of representing your department at CIO and business leader level, through individual programme management, people management, requirements analysis, testing, strategy, development methodology, training, coaching, product maintenance, customer satisfaction, and so on.

The skills and experience developed in our successful execution of this responsibility gives us the credentials to slip into any one of the roles above, either in a (interim) managerial context, or for coaching and change management

We have experience running organizational change, off-shoring and web legacy system upgrades

Lessons from this:

• Clarity of Purpose. Send clear, succinct, messages out to senior IT and business, on a regular and predictable basis. Focus on what is changing, and what is under control. Have detailed evidence handy, but don't start with that. Listen to what they say - they are your customers.
• Look after the People. Spend quality, regular time with all members of staff. Make it a habit. Coach senior staff to do the same. Make it an expected area for the appraisal. People are important. Happy workers are more productive.
• Manage with presence. Do not expect to be able to manage by sitting in an office in front of a laptop. The management role is personal, and it is a service (not dictact) for the staff who, like you, are supporting the business. Do it with understanding and humility.

---

Web Product Upgrades

We have presided over big upgrade programmes for publicly facing financial websites, which had to deal with legacy systems with inadequate documentation and the requirement for the new one "to do the same as the old one".

We approached this by freezing development on the existing webs as soon as possible, allowing only essential maintenance (break-fix etc). Then we delivered the first phase of the new web as soon as possible. Thanks to some clever architecting, it was possible to have the two working together, but it was not ideal. Key to the ability to do this was a very early step in implementing the new authentication infrastructure.

Eventually it was possible to remove the old web (minus some non-changing legacy), and the new system was as complete as it was going to be, until the next upgrade.

Lessons from this:

• Cover yourself with tests. If you are upgrading from an old system, start by writing the tests, and test the old system first. Only then can you be confident about refactoring.
  
• Limit your changes. Replace only that which needs to be replaced first. It is possible to keep some (not frequently used) pieces as is. Upgrade the popular areas of the website first, with high quality. The less used pieces may eventually die off naturally...
• Don't drag your feet. Be very conscious of the time you are taking to go live. Agile helps to focus on delivery. Take too long and you are already out of date, since nothing stays still for long.The great new system may otherwise be an old system, given the pace of web technology.  So use agile to deliver small changes often.
  

---

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 from this:

• 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!

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 from this:

• 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.