Serious play

Dave Rupert posted Play at work. The text is not about having a table soccer in the office and spending time playing during office hours. It´s about cultivating a habit of serious play at work, enjoying what you do, understanding the materials you have to handle, finding solutions that will serve your users best, exploring what´s in your tools, and having meaningful and responsible team interaction. You can even go as far to say it´s about growing individually and as a team.

I fully agree to the idea of serious play.

One thing that has served me well in my working life, and still does, is a behaviour where ideas are passed quickly back and forth from designer to developer and back to designer then back to developer for the entirety of a product creation cycle. Dave quotes The Hot Potato Process to give this way of working a name. The name is misleading. Passing a hot potato implies you want to get rid of it because it´s hot. I do not want to get rid of it. I want to get a hold on it, enjoy handling it and playing with it, then passing it to someone else for enrichment and getting it back. As a metaphor, soccer could be more suitable. Passing the ball back and forth to your teammates, enjoying the interaction while crossing the field to achieve a goal, is what I want. I want serious play.

Designing and developing should not be a waterfall process, where a designer has to get the design right in the first pass and the developer will pick up and simply build what has been designed.

The currently popular Figma has a tendency to push development teams into the waterfall direction and for that reason I avoid Figma in web development projects.I prefer to work with the materials at hand, HTML, CSS, and JavaScript (TypeScript). It avoids design handoff and allows to adhere to what lays in the materials.

Agile is a way of interpreting serious play. Collaboratively working in short feedback cycles to learn and improve is at the core of agile.

The first value of the agile manifesto says:

Individuals and interactions over processes and tools.

The first value of the agile manifesto

The agile team is encouraged to actively evolve how the work is done. If you look at it this way, a team role named Scrum Master can be an impediment and might hinder the team to evolve! I´m not saying Scrum is false or Scrum is not agile. Scrum is agile. Scrum can work. But practicing it by following the process rules without connecting to each other, without acknowledging the current situation, is theater communication. The members of the team will behave accordingly and protect themselves against the corporate bullshit. The team is then doing faux-agile. It´s agile names and rituals, but without the values. It´s waterfall with standups. Industries are making money with agile certifications and agile frameworks that do waterfall with new names.

Martin Fowler is giving guidance in his talk The State of Agile Software in 2018:

Martin is not promoting the idea of getting rid of agile! He talks towards doing agile like it is meant to be.

The State of Agile Software in 2018, by Martin Fowler. Martin, being one of the original signatories of the agile manifesto, is articulating the issues that come with the hype of agile, or should I say enterprise agile? Despite the talk being from 2018, the content is relevant and probably will always be. Martin states at 23:20 that Kent Beck wanted to give agile the name "conversational", and I like that very much. Suggestions by Martin:
  • Get rid of the agile industrial complex and let go of imposing agile processes on teams
  • Raise the importance of technical excellence
  • Organize around products and not around software projects
The transcription of the talk is on Martin´s blog.

It´s a pity agile has been taken over by corporations emphasizing processes over individuals and interactions, but perhaps it was inevitable. Once agile became popular, a way to make money out of it appeared, and money-makers were jumping onto it. The same managers who were claiming agile is Kindergarten software development, at some point where jumping onto it because it became the valid thing, because other corporations marketed their agile-named processes as well and they didn´t wanted to be left behind.

When you find yourself in a context where agile is being practiced by seizing power on developers, squeezing more features out of a delivery team in a given time, I´m sorry for you and I hope you find a way to change. But it doesn´t render the agile values false. Agile is serious play and it´s worth striving for this way of working - you don´t need to name it agile and probably it will not help you with your management to name it serious play either. Instead, try to find a way of doing what you came for, building and making something beautiful and meaningful together with your colleagues.

Dave ends with a sentiment, Maybe we need more play at work. This is not a question to me. In software development, it´s the way forward.

Comments