3 Techniques that will instantly make your teams more effective
In a resource tightened environment getting the most out of your team is going to be a must
Once we all get back to business, as usual, there is going to be a rush to get back to peak productivity. It also gives us a chance to try some new ways of working. Maybe this break from the office has made you question some of the ways you used to do business and you are ready to try some new techniques to boost productivity.
I was recently recommended the book, Extreme Programming Explained by Kent Beck, by a coworker, and I’m glad he did. The insights in this book were profound and have changed the way I work. The book is tailored to Project Managers leading teams of developers, but the ideas I describe below could be used in any line of work.
If your job includes any project planning or managing employees, you won’t want to miss these tips.
Conquer & Divide > Divide & Conquer
We hear “Divide and Conquer” all the time when we are dealing with big projects. The reason being is because we think doing this will save time. However, more often than not, it ends up leading to a lot of waste because of a lack of planning.
How is that possible you may ask? By dividing the work, it should get done quicker, right?
Wrong. When a manager takes a project and divides the work without any planning, it will lead to waste.
Why? You may ask. Simple, dependencies.
One team is dependent on another to do their job. This situation will lead to one group being busy while another team is just waiting around for the other group to finish.
To avoid this scenario, Beck suggests the technique of Conquer and Divide. The goal of conquer and divide is to break up and assign the work so that there are limited dependencies in the tasks assigned. This planning strategy will limit the amount of time and effort spent coordinating and waiting.
Conquering then dividing allows teams to be independent. They do not need to wait for another team to complete their task before moving onto the next. They also do not need to spend time constantly having meetings to sync up with other groups.
Project > Role
In Extreme Programming (XP for short), employee roles are not fixed and rigid. Every employee is expected to do everything they can to contribute to the completion of the project.
Yes, I know that sounds obvious. But tell me, how many times have you been at work on a project, and you were up to your ears with work while another team member seemed to be doing nothing?
This scenario happens when people are more loyal to a job description than the project. If they are a programmer, and it is time to start preparing presentation material, they take a back seat because their part of the project is done. And vice versa.
Everyone has their expertise, but in XP, it is expected for every team member to learn from one another, which will lead to an increased breadth of contribution in future projects.
If a programmer has to create some PowerPoint slides, so be it. If a designer has to write a couple of lines of code, they should be open to that too. In XP role always comes second to delivering the project.
An easy way to tell if your employees are more loyal to their role versus delivering on a project is if you hear the words “that’s not my job” a lot around the office. If this is rampant in your office, institute cross-training sessions during slow periods in your schedule. This (finish)
Social Novice > Isolated Expert
XP has a massive emphasis on strong communication and collaboration. Yes, these are all corporate buzz words, but XP takes this to the next level.
A lot of the aspects of XP are very social nature; the most prominent example is in an exercise called Pair Programming. This is when two developers will pair up, and one will write code while the other observes and reviews each line of code.
Even if you don’t work in a software job, this same exercise could probably bring your group a lot of value. By having employees pair up, it will increase the spread of knowledge and best practices within the group.
This practice does not work; if an employee does not enjoy working with others. They might be a genius, but they do not enjoy or work with others. Beck recommends hiring the competent-but-social programmer over the extremely skilled loner.
I know that seems counterintuitive, but the reason being the skilled loner will not spread their knowledge to the rest of the team. However, a more social programmer will be able to learn quickly from the rest of the team and quickly become an expert.
There is a lot more that makes up XP than what is written above, but I think these three practices are ones that can be applied to any line of work, not just programming.
If you liked this article, I recommend reading the book. It is a pretty quick read.
Conquer & Divide > Divide & Conquer - divide the work to limit team’s dependencies on other teams
Project > Role - employees are expected to contribute all they have to a project, not just what their job description says
Social Novice > Isolated Expert - learning from and teaching team members is critical to XP, so being social is very important.
If you try out any of these techniques at work, let me know. I am in the process of trying to incorporating these practices at work and will definitely write a reflection after these practices have been implemented.
About the Author
I am new to this whole blogging game. I write about topics that I find interesting, and that can provide value to my readers. The recent topics I have written about are finance, business trends, and some self-help. If you have any comments or questions around any of these topics, feel free to email me at email@example.com. And if you like the articles subscribe to my newsletter to get all my month’s articles in one email.