Posts Tagged ‘ Scrum

Management Communications

Time to take a deep breath and teach the MD Scrum. The MD’s perspective is not unusual: development is always late and product owners are frustrated because they don’t know when a developer will get chance to look at their requirements. My perspective is tangential: development is sometimes late as we can’t always judge the complexity of a project accurately, requirements change as our customers understand better what they want and priorities change as the winds blow. I’m improving the way we work by introducing agile methods (Scrum, test driven development, continuous integration, and so on) and making better use of teamwork; the MD wants to increase individual responsibility and micromanage. How to square the circle?

First take a step backwards; it’s easy to forget when you work with someone on a daily basis that they don’t fully understand what you do. It’s hard to explain to a hyperactive managing director why a developer may sometimes sit looking at a blank screen or that banging out a few thousand lines of code in a day probably isn’t a good use of time. Or that development is fundamentally hard. Or that very few requirements can be met by creating a new table and adding an index.

Introducing Scrum brings an opportunity to do some basic communication with the senior managers. And an opportunity to communicate is an opportunity to recap the basics (development is complicated and difficult to predict). Scrum is mature enough to be taken seriously, with plenty of case studies and is designed to manage complexity and changing requirements.

The basics of the communication need to cover:

  • What Scrum is, what problems it solves – with particular emphasis on the problems that affect us most – and who uses it.
  • The benefits that Scrum brings: it’s hard to quantify a reduced error rate in monetary terms but straight forward to show how sprints will make our development cycles predictable.
  • Sashimi – perfect slivers of  completed functionality. When a requirement is ‘done’ it is tested, integrated and could be shipped.
  • The effect empowerment has on the developers
  • The increased understanding that the product oweners get of non-functional requirements and any trade-offs that are needed.
  • The benefits of prioritising requirements and not trying to do everything at once.
  • How better communication between developers and product owners results in better product development.

The tactics are:

  1. Send an email to the senior management team and other stakeholders briefly what Scrum is and why it is being introduced and take the opportunity to indirectly address a few of the MD’s concerns.
  2. Attach a longer Powerpoint document covering the points above – this hopefully will get flicked through and different people will pick up on different themes.
  3. Make time to talk informally to everybody who gets the email, find out what they think and give them chance to highlight any concerns.
  4. Pull together a face to face briefing for all the stakeholders to run through a summarised version of the Powerpoint and address the concerns that have been raised.