Karol Sójko - To-Do: Team!: Simple productivity techniques for improving your team & making software that matters

To-Do: Team!

Simple productivity techniques for improving your team

&

making software that matters.

Copyright 2015 by Karol Sjko

All rights reserved.

Many teams, in their development process, tend to focus on answering the question how instead of why. This leads to many misunderstandings which can in turn decrease your productivity and take the pleasure out of work.

This books answers burning team productivity problems in an easy to implement way. To-Do: Team! is designed to help you improve your teams effectiveness and communication in a few simple steps. This book is for team leaders and lead developers who suffer from ineffective software development processes.

As a team leader and behavior-driven development practitioner, Ive read and tested hundreds of methods on the subject of project management and software development.

Team leaders, software developers, and project managers have already gained tons of benefits by implementing the tips and tricks found in this helpful how-to guide.

Jack, a team leader from Gdask, Poland, says, The best thing about this book is that it helped me improve my teams communication and increase client satisfaction within a week."

I promise that if you follow the simple steps included in this book, your teams productivity will improve drastically. Your clients will become more involved, helping you and your team to efficiently and effectively reach your goals. Your team will find additional time for personal development and improvement.

Dont be the passive team leader whose team is not performing their best. Be the person who puts the team back in team work. Be the person who creates the most productive work environment. Be the proactive person every team will want to follow.

The tips and tricks youre about to read have been proven to create positive, long-lasting results. All you have to do to improve the way your team works is to keep reading. Each chapter will give you new insight into the world of effective software development. Take control of your team now; make it productive and start to enjoy working on every project you create.

The Solarians have given up something mankind has had for a million years; something worth more than atomic power, cities, agriculture, tools, fire, everything; because it's something that made everything possible (...) The tribe, sir. Cooperation between individuals.

- Isaac Asimov, The Naked Sun

Communication Breakdown

What lies in the foundation of today's teams is a problem with communication. When developers try to give this more thought, it always comes down to business users not effectively expressing their needs and business goals.

On the other hand, managers always complain about developers approaching every problem with too much technical detail. This situation makes developing projects very hard. In this kind of environment its always difficult to calculate the risks and estimations behind introducing a change in the software.

Moreover, it is commonly said that the customer doesnt know what he or she wants. However, I strongly believe that it is not a part of the customers job to know and fully express his/her needs. Our duty is to help our clients be precise about what they need. Complaining about people you work with has never helped any team.

This kind of environment often turn out to be highly unproductive. Unfortunately, most teams dont take action to improve their organization. This kind of work environment can cause team members to stop caring about their work. What happens next is everyone starts accusing other team members of not doing their job properly.

The Blame Game

What you commonly see in teams doing agile methodologies is the blame game.

Its a game that takes place after a feature was implemented late, youve missed a sprint deadline, and/or something didnt turn out as expected.

What happens is that managers, leaders, or owners accuse the developers of not being able to deliver, and developers accuse them of not specifying their requirements clearly, making constant changes, and not being consistent in their demands.

There are two kinds of teams. Those who do retrospective meetings and those who dont have the time to reflect on their actions. If youre in the latter kind of team, then the blame game is your natural environment.

Of course there are teams where everyone is nice to each other and fulfills everyone elses expectations. For most of us, though, that isnt the case. Teams that dont want to look back on what they do can be described as rotting.

Were only human, and as developers we do a very intellectually demanding job, so its natural to feel the need to blow off some steam from time to time. If your team doesnt have a controlled environment to do that, youre going to observe how rotting spreads.

I fell into this trap myself many times. When the tension starts building up it gets too easy to accuse someone of not doing their job properly. When this happens, the team cant work effectively, and more importantly, loses passion. One thing that can help your team is to organize retrospective meetings.

Developers are people who tend to always look forward and have a mindset for the future. I consider myself a developer, and one of the main reasons why I dont like to look back is because it feels awkward and like a waste of time.

However, believe me when I say its worth your trouble. The main goal of retrospective meetings is to stop the accusations from flowing and work on your team dynamics. The sooner you realize that the problem wont fix itself, the sooner your team can progress and benefit from the constant improvement process.

Rambo Developers & Colonel Trautman Managers

Communication problems arent the only issue that many teams experience. Another problem that dysfunctional teams have is the fact that they modify the behavior of their key assetsmanagers and developers.

In many companies there is always a developer who knows everything about a given system. The guy is irreplaceable. Hes the guy who never takes a vacation, knows the answers to every little question about an implementation detail (even if you woke him up at 3 a.m.), and never takes a sick leave. Does this sound like someone you know? I hope not. If it does sound familiar, youve got yourself a Rambo developer.

Just like the action movie hero, he treats everything like a one man job and most often he can take on a project single-handedly. If this guy was gone, the project would fail. Just like the US Army wouldnt have made in Afghanistan or Vietnam without Rambo, this developer is absolutely crucial to your company.

The problem with Rambo developers is that they are the bottleneck of every company. The reason that they dont take vacation or sick leaves is that theyre too crucial to the process. This is a first indication that the company has a dysfunctional team.

The reason why developers like this arise is a lack of cognitive diversity. Its always the same one guy or girl who analyzes, designs, and/or implements the software. Everyone else is just there to do monkey work.

If there was a better communication flow then the product knowledge would be widespread through every team member. This would mean that instead of having one Rambo developer and a couple of monkeys, we would have a team of properly functioning Green Beret soldiers.

On the other hand, we also have managers who are responsible for creating these kinds of environments. Just like Colonel Trautman was proud of Rambo, these managers are proud of their creation when the project is in boot-camp mode. When projects are in early greenfield stages its very natural to use and abuse special individuals to get things done. Its just like in the movie, when the Colonel says God didnt make Rambo. I made him.