They communicate through code. Company politics and gossip isn’t their activity of choice. They’re not known as the most social people. Yet, despite these prevailing assumptions about software developers, hackers or geeks, it is the culture of software development that contains values every single business should learn from.
Perhaps you’ve already heard about Agile – an approach used predominantly in software development. Agile isn’t just a methodology allowing prototyping, developing and launching products to market faster than using any other approach. Far less talked about, however huge benefit of Agile is the way it shapes workplace culture.
During my work with development teams I came across a number of priceless information that no one talks about in relation to Agile development. My experience has motivated my so much that I began helping businesses transform their work environments towards geek inspired ones. A couple of gems, which earn the highest response in workplaces is what I’d like to share with you.
In a principle, Agile culture is defined by three elements: team, project plan format and rituals.
Agile builds on principles of rugby game. One of the most successful Agile frameworks called Scrum has been named after rugby. This kind of team is defined by two things: a single shared goal (which is more important than putting too much emphasis on individual tasks) and flexible roles.
Individual skills of team members are recognised and the work they do is based on these skills; however, it’s important to acknowledge that goal is the absolute priority. In Agile practice we can often experience scenarios in which people with complementing skills get together and approach challenges together rather than waiting for one person to tackle their task. A sign of needing help isn’t considered to be a deficiency or a failure. Quite the opposite. This model fosters group learning and knowledge sharing amongst employees and indeed, it speeds us work. Culture of such team is not looking for winners. It’s not a race towards praise and it doesn’t incentivise people to hide their weaknesses in order to avoid punishment. It rewards the whole team.
Sprints, pizza and peace
It equally works the other way round – the whole team takes the hit together. They say a team is only as strong as its weakest member. Many teams, with higher Agile maturity tend to begin their projects with setting shared rules. For example: if one team member has to work overtime, the whole team stay at work late. Agile team usually comprises of 3-9 members. At Amazon, it’s called a “two pizza team” – i.e. a team that can be fed with two pizzas (I suppose their American size pizzas). This guarantees that everyone is actively engaged, heard and able to see results of their work.
Project format is defined by time framed stages called sprints. One sprint usually lasts two weeks. This time is sufficient enough to produce tangible output, yet it still gives enough opportunity to review the process, revaluate circumstances and assess results, giving a way to a change of direction. Every sprint’s objective is to produce an output which becomes a functioning and self sufficient part of the final solution. To achieve functionality, we naturally need to build teams with people who can collectively generate such output, even if it’s just a prototype. Thanks to this rule everyone involved in the project, whether as a team member or as its stakeholder, has a clear idea about what’s being built at that very moment. It is however paramount that the team isn’t disturbed throughout the sprint – no new requirements or changes should be introduced. The time for evaluation and review is reserved for after the sprint, before the next one starts.
Imagine how great it would be to simply focus, have equally focused colleagues around you and work together towards achieving a goal. The short timeframe of sprints and their collaborative nature doesn’t give chance to long term isolated work and building of one’s own success on the shoulder sof others. Life in a workplace without politics and undermining is beautiful!
The whole team gets together once a day ina so called Stand-up meeting that takes about 5-10 minutes. Here every member talks about what they achieved yesterday and what they’re going to do today, including any blockers that could prevent them from accomplishing their work today. This meeting without chairs doesn’t encourage people to sit back and get comfy, but rather people spell out what’s on their plate, often holding their morning cup of coffee in their hand, and return back to work.
Stand-up is the shortest but the most important ritual as it ensures transparency, it gives the team a feeling that progress is being made and most importantly, it provides opportunities early on to identify obstacles and give everyone an opportunity to get involved in solving them. Any obstacles that are identified are however never solved during Stand-up meetings. Team members who are involved in solving them take them offline, saving other people’s time.
Yet another interesting ritual is retrospective – my favourite. At the end of each sprint and eventually at the end of the project, the team meets for an hour of open constructive debate in a safe and trusted environment about what went well and what didn’t quite follow expectations. The attention isn’t directed at people but towards events. No finger pointing or taking things personally is a norm here. The focus is on improving general conditions and circumstances that can be collectively controlled, and thus improved. Retrospective might not only uncover opportunities for improvement for the team, but as it gets more sophisticated, it can also serve as a dedicated place for regular revision and improvement of the process.
This is only a taster of Agile. Once we begin to actively notice the impact of software engineering on the world around us we realise that its influence is tremendous and in many places it can betoken an unprecedented progress. Selflessness and collective benefit were the values of the origins of internet. It’s not a coincidence that these values are deeply rooted in the way digital products are built. The code itself develops thanks to the fact that majority of engineers publishes keys to their work because they know that somewhere out there in the wide world there’s someone who might find the code useful whilst at the same time, there’s someone else who can improve and develop the code further.
Many companies have noticed advantages of geek inspired approach and began applying Agile, for example in their marketing teams. Agile is going though a renaissance, it’s no longer a secret code, it puts geek culture out there as an extremely inspiring approach to business management. It’s one of a few methodologies which considers both product, process and culture at once.
Do you have experience with Agile or any other product development approach?
This article was originally published on Forbes.sk.