Yes.
…
However, you have to make sure you go all-in on agile and do it properly. If you were entering a marathon you’d commit to training for it, wouldn’t you? If you half-arse it you’re going to look like an idiot when you can only manage to run the first mile and you have to crawl the final 25. It’s the same for agile working. If you want the best results, don’t half-arse it. Whole-arse it.
What the hell even is agile working?
Basically, it streamlines the hell out of everything, making it an effective and unconvoluted method for team communication.
If you want the boring ins and outs, it’s communication from the perspective of project management describes the formal and informal trajectories of address and the varied ways in which people convey information to one another within teams. Like all traditional approaches, good communication underscores, and is necessary, for agile working projects too. It differs somewhat in principle and praxis, the tone for agile communication foregrounds simplicity, direct communication, and the importance of face-to-face discourses.
Teamwork makes the dream work
To get the most out of an agile working environment, it’s important that everyone works together and understands how their role affects the overall goal. To help keep you focused, take time to get to grips with the following:
- The shared understanding that, for the sake of efficacy, the superior method of conveying information, particularly during the developmental stages, is face-to-face conversations.
- That working software takes centre stage as the primary means of measuring progress.
- An active pursuit of maximising the amount of work done and reflecting on the amount of work that has not been done. Sounds a bit bleak granted, but once in full swing it can allow for a consideration of time that shaves days and weeks off projects in the long run.
- Peer and team feedback at regular intervals during which time all involved reflect on how to become more effective, then work to fine tune and adapt behaviours accordingly.
- The agile working comms manifesto addresses the value of working software over heavy and comprehensive documentation. That is not to say that extensive documentation doesn’t have value, but working functionality is at the top of the pyramid when it comes to importance in an agile project.
On the surface, this may sound like it’s been typed out by the leader of a hippie commune. But it can be a truly effective way to work and add a layer of purpose that becomes motivating (does wonders for team morale and complexion). It also encourages group cohesion as a sense of team-spirit and working towards something as a whole emerges. Far out, man.
Who’s on Your Team and the Roles They Play
When working in an agile team there needs to be a hierarchy, not in an overbearing let-them-eat-cake way, but explicitly labelled tasks that allow the cogs to roll smoothly. The development team will traditionally comprise the people who do the legwork in creating the product. The scrum team (of which the developmental team is a subsection) also contains the product owner/client, and the scrum master. The project team (scrum team within) has the wider project stakeholder. Everyone within the scrum team is responsible for self-management and working to their brief. This Russian doll model creates a dense nucleus of communication and shared direction, allowing for nothing to slip through the net. Where traditional teams rely on command-and-control models, agile communication driven projects allow for self-managing, self-organising, and servant-leadership.
The myths and the reality
1) Agile comms descends into chaos
The lack of official structure that exists in traditional modes leads to fears of descents into madness. This has never happened in our experience, in fact a structure does exist, but one that encourages and bolsters the individual; where traditional modes may refer to human resources, agile comms uses terms like talent, people, or simply team. Similarly, the Russian doll model, instead of a linear approach, emphasises the team aspect and how integral the individual is within the greater whole. A polite and respectful term of address is the real difference.
2) It’s inflexible in size
It is, and it isn’t. Agile comms teams have a minimum of 3 and a maximum of 9. This is because we are pack animals best suited to smaller working units. When you have 10+ the most vocal emerges and the quietest can disappear. Having a ceiling on people ensures communication is at the sweet spot between dominating and getting lost in a crowd. If the project demands significantly more people – breakdown the tasks, divide into agile teams, and go forth and conquer.
3) A lack of documentation is a problem
Traditional approaches often drown members in large amounts of complex documents and status reports that don’t consider the actual need. Agile documents, or as the already agile among us like to say – artifacts – are intentionally minimalist, working more as a top-liner that conveys project status at a glance. This show, don’t tell mode streamlines hours wasted on absorbing information that doesn’t translate into action, and instead time can be spent actually working towards the project’s goals. Of course, documentation needs to be stored and accessible if questions arise, but in general we see and absorb more than we need.
Perfect trilogy
We’ve already written two other blogs on agile working, one on what agile working actually is and one on what agile solutions actually look like. Over the course of our ‘Agile Working Trilogy’, we’ve hopefully covered a lot of bases. For more information, get in touch with us. Or read some other blogs because three blogs is enough.
