A Tale of Two Projects

It was best of times, it was the worst of times…  

There were two projects – Project “A” was a greenfield project, with highly motivated, highly skilled Software Architects & Developers who either had a lot of experience with Agile Scrum or were very open to learning about it.  

The Product Owner was fully engaged and worked diligently to create a well defined set of User Stories that could be easily broken down into Story Points.  As this was a greenfield project, we were not distracted by support issues.  In addition, the project had, albeit after some convincing, good management support.

Whereas Project “B” was the Spaghetti Monster project that was the result of years of mismanagement, misunderstandings with patches patched on top of patches, poor source control and deployment processes and poor engagement between the software development team and the client.  

To make it even more interesting, Project “B” was a core, mission critical system with a large user base (who were not happy or no longer engaged), and suffered frequent outages, slow performance and provided a poor user experience.

Project “A” was every Software Development Manager’s dream project.  

Sure there were challenges, as there always are with any project, but the team worked well together and worked to overcome issues – as any high functioning team does.  There was a strong sense of pride in the work that was being achieved, plus a willingness to collaborate and to help each other out.  Planning meetings went well and we regularly (mostly) hit our Sprint deadlines. 

Project “B” seemed to limp from disaster to disaster.  

The system’s instability meant that Developers were frequently being dragged into whatever catastrophy had just happened. Consequently, it was extremely difficult to plan work as the team never quite knew what was coming around the corner.

In addition, the Development Team was disillusioned after years of lurching from crisis to crisis and there were large differences in experience and ability between team members.  For some Developers, this was their first job out of university and they had little or no experience of working on well functioning projects or in a well managed Agile project.

 

Lesson 1 : Stakeholder Management

Any system that is in this much trouble – particularly a mission critical system that is core to a businesses success –  will have a very nervous senior manager somewhere who is wondering if they will have a job this time next week.  This is the person who is probably responsible for the balance sheet, pays salaries and probably hired you to help fix the mess.

Keep this person as happy as possible!

 

This is more difficult as it sounds.  The temptation may be to roll up the sleeves and get stuck in with the team to fix the technical issues.  As productive and as worthwhile as this is, you need to keep the main Stakeholder (or Stakeholders, as there could be a couple) well informed about:

• Where we are;
• What we are doing;
• How much progress have we made.

Make sure you are incredibly clear on the following:

• What are the Stakeholder’s key priorities;
• What are the Stakeholder’s key issues;
• Define what the Stakeholder would consider to be “Progress” or “Done”.

Understanding where the Stakeholder is coming from will help in prioritising work and determining which crisis needs to be dealt with first.  This is not to say that the Stakeholder has a compete mandate on the truth and understands what issues “should” be fixed first.  However, a good Stakeholder will have a strong sense of the bigger picture and what will most positively impact their business.

Lastly… always keep your Stakeholder “in the loop”.  That doesn’t mean CC’ing them on every email but it does mean daily or weekly summaries of the three (3) key “Where, What and How” answers above.

[Note: If you do not control the conversation between yourself and the Stakeholder then others may!]

 

Lesson 2 : Stabilise

Sometimes you’ve got to step back before you can walk forward.  Do everything possible to stop the bleeding.  If necessary or possible, dedicate all resources to fixing bugs and getting the system to perform within the acceptable parameters defined by your Stakeholder (see Lesson 1).

It may not be pretty but you have to create the space within which the Development Team can function without continually dealing with crises and support issues.

Analyse the support calls and figure out what is causing most of them.  Sometimes you get lucky and a large number of support calls are generated by a relatively small number of issues that frequently happen.

If the issues are performance related, determine if you can use the “Brute Force” approach – throw infrastructure at the problem by spinning up more servers, adding processing power or increasing network bandwidth.

Remember, the purpose of stabilising is to generate the space to allow the Dev Team to do their jobs properly.

 

Lesson 3 : Educate

Not all Developers are equal. Some will have more experience in their chosen technical field, or more experience in general as a Developer.  Others will know more about specific parts of the system (particularly if the system is BIG).

Foster an environment of learning and education.  Implement strategies to allow Developers to share knowledge with one another.  Start a Wiki. Hold lunch time “Brown Paper Bag” sessions where Developers bring their lunch (not mandatory that they use brown paper bags) and one or more informally present on a topic of interest, either related to the system or related to their skills.  

Particular emphasis should be placed on improving technical practices for all team members and ways to automate builds, deployments and testing. 

Get Developers to work in pairs, so that senior Developers can show and mentor junior Developers with what they do and how they do it.

Provide training to the team on, for example, Agile/Scrum or their technical skills.

Foster a Team culture – take them to the pub, buy them pizza, have meetings away from the office.  Get them to like or, at least, appreciate each other.  Develop a “We’re all in this together” mentality. 

 

Lesson 4 : Rotate

No one likes being the fulltime Support Developer.  Split the Development Team and the Support Team so that the Developers can focus on development tasks without having to face the distraction of support calls or adhoc bug fixing.

However, make sure everyone does their time working on the support queue.  As much as possible, make sure there are no exceptions.  Having favorite or indispensable “guru” Developers who get the plum work can foster resentment and can stunt development in less “valued” Developers.

 

In Summary…

There are no hard rules here – each project and system will teach their own lessons.  The above may be useful for yours.

Feel free to download the PDF version of the “low tech” slides from here.