The Minimum Viable Non-Digital Product v1.0

MVP of organisation structure

While starting a previous post, I speculated about specifying MVPs for non-digital solutions. In an idle conversation with a colleague recently, I suggested that the approach being used for their department’s latest reorganisation was much like past examples of over-scoped IT projects - Complex Sprawling Disappointments (CSDs).

The current reorganisation arose from a frustration that the department was not creating enough new products. The approach to restructuring the department has been to try to duplicate the structures applied in other organisations. However, after a year (many more than U.S. Digital Services Playbook’s “no longer than three months”), the reorganisation is only just being rolled out. In the mean time, staff have been unsettled (some have quit) and work is being impacted.

There is a sense of incongruity with this way of restructuring and the fact that “Agile” is identified as the new chosen work culture throughout documentation created about the restructure. Therefore, it was with little satisfaction that I read in Schwartz’s Introduction to A Seat at the Table (2017):

“rhetoric that says, ‘We need immediate cultural change so that we can become Agile!’ … is strangely non-Agile”

Instead, Schwartz recommends that we should “experiment and learn about how an Agile approach to IT works within the broader business context that is the enterprise”. We should perhaps start with a Minimum Viable Team. Indeed Greenway et al.’s Transformation at scale alludes to a Minimum Viable Team:

“Your first digital team will define the working culture and how things are done”

They describe the roles, recruitment and working patterns. However, I was a little disappointed to not find any much iteration over these to determine what works best for each organisational setting. It may be possible, however. Mergel et al., 2020 propose Agile as a way of governing but recognise that there is still a great deal of learning required for the implementation of these practices. In 2014, Godbout and Kunin of 18F describe approaching hiring using an open, user-centered Agile approach. I’d love to hear of more examples of organisational change using Agile processes - especially implementation in an organisation that seems unable to relinquish waterfall practices such as onerous requirements gathering exercises and de-risking using stage gates.

PhD by Agile

I have the privilege of supervising PhD students. Doctoral training and doctorate theses are rarely smooth processes and we have noted the number that haven’t completed has risen just lately. The PhD is a lonely experience. By definition, the research has not been undertaken by anyone before and so there is rarely any blueprint to follow. Often the best I can do as a supervisor is to sit in a mobbing session with my student and make motivational noises. Is there a better way?

Mark, who did a similar job to me in the very-before-times, and is now a Scrum Master, suggested an iterative approach to a PhD:

• If you had two days to do this PhD what would it be?
• Write every part needed in the PhD but spend a couple of hours on each. So after a couple of days there’s a first draft with most of it missing
• Get feedback and write it again. But every bit
• Find the missing bits - increment it
• Improved the bits you have - iterative
• Hand in the two week version. Then the one month version. Two month. Four month. Eight month. But every version could claim to be a PhD. Even if it is not great.

I love this and wonder, could it work? Changing to this approach takes quite some commitment, not least from the supervisory team who would need to be present for every review. It would be hard work but the student would have guidance and feedback from the very start and, maybe best of all, no thundering great thesis to write at the end.

MVP of a blog post

For that earlier post, I attempted to apply a Minimum Viable Product (MVP) approach to writing. I did find that identifying what the whole ‘product’ (the post) should do (the user story) did help me structure my writing and as a result it was relatively fast to produce. (That said, I also spent many hours in the night thinking about the post before writing it). I’ll be honest - I haven’t stuck to this approach, preferring to keep a mental picture of some of the structure and write within this. On several occasions, the end of the post has been quite different to what I expected when I started. You are, of course, welcome to look at the version history and decide for yourself how Agile I am being.

Also, I would love feedback, please pop your thoughts in the comments box at the bottom!