Image Credits: shutterstock.com
Have you ever been part of a software development team? Three years ago I have let the corporate world. Since then I advise large organizations but I am also involved in small companies. There, I have been increasingly involved in software development, e.g. for PresMaster.
Working with startup software teams I have learned several operational elements that are very different from the corporate world– but also potentially very useful. Here are three:
1) The focus on “shipping”
In the corporate world, often things (ideas, concepts, projects,…) can drag on: nothing happens for weeks and months, meeting after meeting with no progress. Sounds familiar?
In software development, and especially in the “agile” world, there is the concept of sprints. Short bursts of developments where the focus is on creating.
Sprint reviews with management are usually held 1-2 weeks after each other, and the focus is to create something concrete and tangible in between: to ship something, as Seth Godin calls it.
The ultimate culmination of this is a concept called the “hackathon”. There, software teams come together to create in one day a new tool/app/etc.
Very intense, very powerful.
Have you thought about creating your own hackathon for your organization? This does not necessarily need to be about software or apps. Also processes, reports, concepts can be tackled here and improved in one day.
I for instance have started to conduct my own “costathons” with large groups: one day intensive get-togethers to identify, map out and immediately staff cost savings projects– instead of huge and endless analysis, preparations meetings etc.
Maybe you can get together as well and create something in a day. It is also a very good teambuilding idea (instead of cooking together).
2) Prototype leadership
Connected to the concept above is a more operational item: how meetings are run in great software development teams.
The software development specialist I worked with for PresMaster was very powerful here. A developer wanted to start and share what he would do, was planning on doing etc.
He was immediately stopped: “Show us the working software – what have you created in the last week?”
And when the developer started again to talk about what could be done, he was stopped: “Let us only talk this once you have created something.”
Talk is cheap. Concepts are difficult to grasp. What is easier to grasp and discuss and improve on is a prototype.
I call this prototype leadership. This does not mean that you always create month-long full-fledged prototypes of products. It means much rather that you take the time to stick some things together on what the code, process, report etc. could actually look like or function. And then you discuss this and take it apart.
Diego Rodriguez, partner at the famous design agency IDEO, calls this “Boyle’s Law”: Never attend a meeting without a prototype.
It much rather means that you always discuss something visual/tangible etc. and improve it from there. This massively reduced the endless theoretical discussions and immediately focuses on real, concrete topics.
Examples of prototypes in this sense for meetings are: A working software; the outline of a new report; the draft concept.
Pushing people to have these ready makes meetings more efficient and concrete. The only watch-out – don’t punish somebody that the prototype is not yet perfect. That’s sometimes the point.
3) The power of user stories
I used to say to my co-founder. “I want this and this functionality”, “I think it would be good to have a button that does this”. And so on, and so on.
He would reply: “I need this in a different format – I need a user story”. In software projects, very often the following formulation is used:
As a user I want that__________________
For example: “As a user I want that I see presentation tips while my self-recorded video is being uploaded.”
Based on this objective, the developers can start doing their magic. It is clear in their head there is a clear guidepost. This is probably because we as humans are wired to stories.
It is a thinking that already in formulation of the objective puts the user first. It enables imagination over theory. It also makes it very easy to verify this question with the actual users (e.g. the general manager).
So for instance, if there is a new report being requested, let your team first fill out the above words:
As a user of this report I want that___________________
I continue to learn from the fascinating world of software development and I think also non-software teams in classical functions such as finance, legal etc. can learn from this.
Is there anything you have learned? I am happy to hear from you.
