This is the seventh post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. I’ve seen several projects that started well, but after about one year into the project problems arose. The developers started to do software archaeology before adding new functionality. They simply weren’t sure any more what happens inside their software. So they went from method to method and from class to class to guess what a change would do...
Effective teams: Good ideas take time
This is the sixth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
A lot of Scrum teams work Sprint per Sprint. They seldom look further ahead than a single Sprint.
While they really tackle problems just in time, define requirements as late as possible to eliminate waste, they still suffer from a big problem: Good ideas take time.
Finding a good solution to a hard problem takes normally more time than a single Sprint.
Effective teams: Always releasable
This is the fifth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. Your code prevents doing the right thing I often see teams that want to do the right thing but can’t. Their software won’t let them. This is caused by lots of loose ends in the source code. Everything is begun but nothing is finished. There are simply too many open tasks. Or there is a lot of technical debt present. Before the team can do what it...
Effective teams: Fits in my head
This is the fourth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
Not even remotely comprehensible
A lot of software is built today by adding feature after feature very quickly without considering understandability and maintainability.
The result is that new features find their way into the software slower and slower because understandability drops over time.
Effective teams: Start with minimal solution
This is the third post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. Big steps When we have a goal in front of us, we tend to think about how we can get there in a single fast step. However, most of the times in software development the goal moves while we are walking towards it. Either because our customer sees our progress and has a better idea, or because we understand the problem a bit clearer and find a better solution...
Effective teams: Plan the day
This is the second post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal. Bad coordination Bad coordination within the team is a major reason why teams are not effective. Things are done multiple times (“oh, you already did this? Me, too!”). Unnecessary work is performed because we just assume that this should be done. We miss opportunities to go live early, to add the feature with a simpler, cheaper solution or to act...
Effective teams: Free Jazz
This is the first post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
In free jazz, improvisation is an important part. But the musicians don’t just play whatever they like. If the Saxophonist takes over from the Trumpeter, he (normally) takes over a little part of the melody and then starts to modify it.
We should build software the same way in our team. We should build upon what is already there.