Startup founder: Building a self-improving team of developers
Posted on Oct 2, 2019
Project management is dead as we used to know it. There’s no need for project manager anymore, thanks to the concepts of self-managing agile teams, user-friendly process automation tools and lively online collaboration apps. Project manager used to take care of splitting the activities into roadmap, providing status reports of progress and simply spanking the team to perform by giving daily reminders and inviting everyone to time-consuming status meetings.
Now, as I have explained during the last two blog posts about agile development (“How to get your ideas organized for software developers" and “How to turn your ideas into fully functioning software"), it’s just a matter of getting automated processes running with developers. When the agile development engine is humming, all you need is a goal and input in the form of ideas and specifications.
As a manager you should always choose from two options when managing development projects and thinking about you own management activities: Automate the activity, or delegate the activity to your team members. This way your team becomes fully aware of all processes and understands how projects are executed. They should not need you to stand next to them as long as goals are defined.
A good team is like a jazz band in a live performance: One might take a lead, but not because of the positional authority. Rather, it happens because of the personal authority and capability to improvise. The one who dares to improvise the team to the next level should take the lead, and pass on the torch to the next one when situations change.
In this kind of self-managing team the bigger question is how to become self-improving so that the team would always aim to build a better world instead of just repeating blindly the processes and workflows. In agile development we work naturally in iterations or sprints and each sprint should have two goals:
- Deliver the agreed outcomes
- Learn from your work and adapt
Every time when we execute an iteration, we have an opportunity to learn how well we are performing. Was it well communicated with customer? Did we use our resources effectively? Did we have the right tools? Could we improve our architecture to make similar features easier next time? All these and similar other questions should be answered at the end of the iteration. In Scrum for example this is called Retrospective meeting, and it’s always closing the sprint.
The key is in the encouraging conversation and systematic execution. Each team member should be free to express pains, challenges, best practices or ideas overall. To improve the teamwork, everyone should think: What should we continue doing? What should we stop doing? What should we start doing? By answering to these three simple questions you start forming a list of improvement activities that can be systematically executed on the upcoming sprints.
And remember, it’s not your task as a manager to gather these lists or provide ideas. Rather, you should simply enable the whole team to do these self-improvement practices on their own even if you weren’t there. Routine is important.
The challenge is not typically in execution, but rather in ideation: Identifying the questions and creating a lively conversation. That’s where a good agile coach can help by creating right atmosphere with interesting conversation, stating out fresh ideas and improvements based on experience, and simply challenging developers to talk about bottlenecks and best practices. An agile coach can become the improvising “jazz band" leader of the team for a moment, thus taking your team to the next level. And then passing the torch to the next one when the team has become fully self-improving.