Far too often we feel like charlie brown trying to kick a football. In spots where we might not have the clearest direction, teams decide on our own what to do. Then maybe a stakeholder comes along, sometimes towards the end, and tells a team to throw it out and start over. The message is that the team is bad and they should feel bad. The message is that leadership doesn’t trust them. The message is that it doesn’t matter what they do, because someone will come along and move the target (football).

Thousands of four-panel daily strips were used to create this image of Lucy and Charlie Brown

This can be less of a problem in service organizations who provide service and tools for mainly internal use. Their customers probably sit right next to them. Often these service groups do not have the constraints of early marketing and sales programs they need to fulfill. Often they don’t have deadlines and scope at the same time. They can often have a problem really finding the core need of their customer, but Product Management generally has this problem, even if they are fortunate enough to have a fully engaged and self-reflecting customer.

But service orgs still run the risk of undermining those who know most about the problem space right when they are ready to solve the problem.

In that regard, team kickoffs and charters can be a help. The purpose is two fold. One fold is to roadmap with the team. The other fold is to allow the team to understand that they are in control of what their priorities are, within the constraints of the organization. And most importantly that they, and they alone are in control of how the opportunities get addressed.

One can often start by allowing the team to align their goals with the group goals and corporate goals for the quarter and year. Without planning out too far, we discuss what to do first. Low hanging fruit and high value. Not an MVP. A steel thead. A through and through usable implementation from end to end. What is the earliest testable thing we can deliver?

On one team we were delivering once a release. We decided to try to deliver and demo sprintly, and get feedback.The team, of course, found a serious bug, but it was way easier to fix so early in the process and so soon after the code was written.

During a recent kickoff we discussed and iterated upon how we get work done. We documented our Definition of Done. We streamlined our scrum processes and removed columns on the Jira board. We later refined our merging process by enabling the github for hipchat plugin to get in-room notifications on PR comments. We created action-based and blameless sprint retros, where the goal is to get feedback from users, and report issues. We defined the initial structure for the long-term roadmap. And we discussed the opportunities for H1 and H2.

We huddled in a large conference room outside of our normal work areas. We brought in food and joked around. This has the typical benefits of additional focus, but also a break from the routine, and a team-building opportunity without the need for trust-falls.

The team is happy about our roadmap and fully engaged.

Soon we’ll have a kickoff for Q2. You should too. We do exercises like this whenever work completes or we’re gearing up for new work. We do this whenever the team changes by members coming or going.

Tell me what you think of me and my silly ideas in the comments!