Lean Software Support OR “Lazy Developers are good Developers”

Recently an ex-colleague wrote a blog about support teams and their role in the world of Agile Software Development that used some rather emotive and denigrating language about Software Developers. He focussed on what he perceived as Software Developers lack of care and attention to what happens to their software after it’s released to production.

He added some emotive and unhelpful language which stated, that in his opinion, Software Developers in an agile development are:

  • focused only on coding, implying they don’t care about anything beyond ‘code’.
  • lazy
  • malicious
  • only interested in the next cool technology

However, under the distracting emotional language he was trying to make the point that he felt Agile teams adopt a ‘throw it over the wall’ attitude to production support.

His suggested antidote was more documentation, knowledge articles, embedding support team members in development ‘projects’ and, above all else, good old fashioned ITIL with a dedicated support team to look after software in production.

I would whole heartedly agree with this….ten to fifteen years ago this was a valid model for software support.

But it’s not 2000, or even 2005, anymore. Modern Lean and Agile development and support rely on a characteristic that he highlighted in developers and that I agree with and am proud of:

We software developers are lazy! And this is good!

Continue reading

Monthly Hack Day (Part 1)

I have recently employed two senior developers who are involved in developments run as projects within Opencast Software, either on behalf of clients or in partnership.

Up until this point the company has mainly employed staff for consultancy work i.e. traditional PM’s and BA’s. Although we have had the odd developer (in my case very odd!), they have mainly been consulting on how to develop/architecture/design or have been embedded in client teams.

When choosing these new hires the one thing I made a conscious effort to ignore was the acronyms on their CVs!

I looked at projects they’ve worked on, problems they’ve solved (and how), any contributions to Open Source projects, the range of technologies they’ve learned, and particularly, their attitude to working with new technologies and languages they’ve never been exposed to.

One of them was a .NET developer I know by reputation having worked in the same company but has a yearning to learn new languages and techniques, the other a Java developer of 12 years standing who has converted to Rails over the last 2 years and has some experience of Haskell.

Having established the core of my development practice I want them to ‘practice’ their skills and to stretch themselves.

To that end I’ve established a monthly ‘hack day’ during which they can work on whatever pet project they want. This allows the developers room to ‘grow’ and contributes to the company, either directly through a project or indirectly by learning techniques and languages that we might ‘sell’ in the future.

I am also treating this day as a ‘maker day’ i.e. a day when developers concentrate on making things and don’t attend meetings or other distractions.

The first of these days is this coming Friday (23rd May 2014). I’ve asked the developers to pick their own pet project using whatever technology they like. I’m toying with a Raspberry Pi based autonomous robot to fetch the coffee from the Cafe across the yard, possibly using Clojure or Python for the control/AI.

I will blog on the results of this day in part 2…..

Is everything coming up Roses on Quality Street?

During my travels through my own development projects and coaching others on theirs,  I come across that age old tension between delivery and quality. Someone screaming ‘ship it, ship it’ when the development team are yelling ‘it’s not fit for purpose yet’.

This balancing act is frequently encountered during fixed price contracts and sometime Agile developments when the customer doesn’t really understand the concept of minimum feasible subset. In both cases the problem is one of communication. How does the customer satisfy themselves they are getting faster but good enough and how does the team determine and communicate what is ‘good enough’ and what is not?

You can’t discuss what you can’t understand or see, so making the quality criteria visible to the customer enables the conversation of ‘do you really want to cut this corner?’ to occur.

So we need to measure what quality levels are, and determine what they should be. This provides an objective basis for a discussion around the impact of compromise between functionality vs quality. That’s why I endeavour to measure test quality, coding rules compliance, non functional qualities (performance, security, etc.).

However, I always think metrics are inherently dangerous as they can lead to focusing on only what’s measured to the exclusion of other factors. This leads to ‘sub-optimisation’ of the overall system. Sub-optimisation is not just a performance issue, the ‘system’ may be the features delivered and therefore sub-optimisation on quality criteria may lead, counter-intuitively, to the delivery of something that’s not fulfilling the customers needs. So we also need to measure customer satisfaction with the features delivered. This is more subjective but it’s where Agile processes can help with reviews and retrospectives to provide feedback.

So we need to measure quality and delivery not, however, to the exclusion of other aspects of the system. We also need to ensure the measurements cover the perspective of the full audience of the system, including support people, users of varying degrees to technical literacy etc.

This is a bewildering amount of information to gather and process even in the simplest one page dynamic web application. So one technique is to involve the wider audience.

  • For administrative functions, can you limit the scope to a handful of people that you involve in the testing process so they are trained by default and need little documentation?
  • Can your user representative (product owner/ambassador user) draft guides and documents?
  • Can you get technically literate users to write user documentation during Beta testing?
  • Can infrastructure and support people be involved early in the development to write support documents and automate support processes?

I’m not sure anyone gets the balance of quality versus delivery perfectly correct but recognising that measuring quality as well as delivery and getting other perspectives from the wider audience is a positive step in the right direction down ‘quality street’ and might tell you when you can stop walking!

Political ‘Scrum’

In my travel’s around clients I frequently see organisations trying to introduce agile or lean approaches. Sometimes this is driven by a real understanding of the issues and limitations of their current approach, sometimes it’s ‘new shiny toy syndrome’ (new? – this stuff has it’s roots in late 80’s or earlier). Sometimes it’s ‘keeping up with the Jones (or Howe-Jones!)’

Frequently these agile transformations struggle or fail for a variety of reasons. the most common is ‘politics’. Organisations, regardless of size, are full of people, and some people are inherently out for there own interests.

I frequently see Scrum teams behaving cooperatively and transparently but their message to other stakeholders gets filter and distorted by political animals who are living in their own culture of ‘fear and incompetence’.

How do these teams cope with these political influence? Make sure your metrics are in place, burn down charts, definition of done, test coverage, team velocity, etc. then PUBLISH THEM TO EVERYONE!

If the reality of the teams progress and actions is exposed to every stakeholder for them to see for themselves it’s not possible for the organisational politicians to distort the message.

Be open and transparent.