The Art Of The Rally Cry

Often at start up companies there are make or break efforts that a development team need to get done by a certain date. Senior leadership will gather and agree that its the most important priority and someone will set a date (or the date is set by an outside party). In an Agile environment with release planning its possible to set a date as long scope is somewhat variable, the backlog is known/estimated, and the team has a velocity calculated. These components are often incomplete and/or missing when the date is set.

So lets say for argument sake that your gut tells you its close. It will be tight but the team will and I hate to use this term need to “work harder”. I hate to use it because it implies that the team doesn’t always work hard which as a developer can be quite insulting. It also goes against a key Agile tenant of Sustainable Pace, the idea that developers should be delivering at a constant pace indefinitely. Having said that in the start-up world there is often a need for a Rally Cry.

To be clear I’m not talking specifically about overtime. It might be necessary but what I’m really talking about is the “energy” the team has in its day to day process. Anyway, here’s what I’ve found is useful:

Delivered by a tech leader

I’ve found it useful for the initial delivery of the message to be handled by a tech leader, someone the team trusts and works daily with. From there communication should be done by all leaders but I think there’s something special about that first message delivered in a team setting where tactical questions can be asked/answered.

Must be special

There can’t be a constant Rally Cry, teams will just get worn down and end up highly dissatisfied. You might have a goal that is 4–6 months out but I assert that a Rally Cry can’t last that long. For long projects it could be the final stretch run or an important 2 week stretch at any point in the project.

Lead by inspiration and example

I find that when there’s a high amount of trust between engineers and leaderships its easier to inspire. Seems obvious but its something that is built up over time. Sometimes its really tough to do. When CEOs “do the rounds” and get to know engineers regularly (not just at crunch time) it really helps. Personal connections mean more than people realize.

Tech leaders should be rolling up their sleeves and contributing. Pairing and ad hoc question sessions should be expected. Shake it up a bit and do something not normally done like be available for questions during lunch. Its a special time, small changes to the regular process are ok.

Kill the scope creep beast

Leaders at all levels need to show restraint on scope creep. Personally, I’m most inspired when I see senior leaders perform ruthless prioritization and acknowledge that not everything can be done. I really think its a matter of respect of the team. I’m not against shooting high but unrealistic goals can demoralize a team.

Physical artifacts

It may sound silly but I’ve found this to be super useful. Post something on a wall that everyone sees (preferably near the stand up meeting). I find it really helps guide the team to be able to actually point to something while discussing implementation details. Makes it less abstract, more real.

Recognize completion

It can’t last forever so it has to end. I purposely did not use the word “success” in the headline. It could be that the end goal was not met or that the external result desired (e.g. funding, new contract) didn’t happen. Hopefully that’s not the case, hopefully things worked out. Despite the outcome I think leadership should recognize the team for the increased “energy”.

Personally I’ve never felt that monetary recognition is ever that impactful. I’ve always felt the most impact has been recognition from leadership for a job well done.