Daily standup? It depends. Is everyone’s update actually relevant to each other? Does it routinely run longer than 15 minutes? Does everyone need to be there? Can it be a threaded message?
This is the hill I will die on. You need threaded messaging. They make a noticeable impact on your ability to organize communications. No one wants to track what’s happening in a botched deployment or prod outage over loose messages or emails.
While we’re on the topic. Emails. Try keeping them short and on topic. Most folks are gonna skim them. With some nuances, the same rule applies to chat. Short is good, but please don’t be one of those people who’ll send a “Hey.” or “Hello.”.
We’re not prescriptive here about tools, that’s not the important part. Many of you are probably using Jira. My condolences.
We want to compile a list of every task that needs done. Don’t be scared about adding and modifying tasks, what’s important is that it accurately captures something that needs done to meet the expectations.
But what about points? The t-shirt sizes!? Stop trying to make me play the worst kind of poker, I don’t want to argue over arbitrary numbers to measure “complexity”.
Hours, Days, Weeks, Months, Years. You’ve been around the block, we can estimate a ball-park. Can it be done in a couple hours, within a day? Will it take multiple days? If you’re getting to weeks, maybe it can be broken up into smaller units? Some tasks can take Months or Years, attempt breaking them down first before committing. Those long tasks have a high potential for burnout.
Speaking of burnout, look, end of the day, people want charts, we’re not gonna avoid time-tracking, so we might as well try to paint the clearest picture we can.
What paints a more complete picture? Tracking the state of every task. It is okay if all of them don’t make it across. Remember, don’t be afraid to change them, drop them and add them. The important thing is meeting the expectations. Now you have some rough math to measure the volume of what needs done, what’s getting done, what’s blocked, and what’s done. Personally, I like a Kanban board, it’s simple and effective.
Demo frequently, whether it is to the team or your client, I’ll repeat, demo frequently. Show them what has been done, any problems you faced, and what’s on the roadmap. This is one of your best opportunities to gather feedback. Less is not more in this case. Ideally set a routine (hate to say it, but kinda like a sprint). Gather it and incorporate it. We’re all adults here, lose the ego and be flexible.
Retros? If you want to pay someone to make pretty boards in Figma or Miro that no one looks back at, and then set up an elaborate recurring meeting to fill it out as a group. It’s a free country, be my guest. Refer back to Chapter 02, meeting expense scales. It doesn’t need to be that complicated. An informal team chat and a document or collection of notes to track a few metrics is ample: what went well, what went poorly, what can change, and what needs to change. How frequently? Refer back to Chapter 01, use your best judgement. A good rule of thumb is when you can’t remember when the last one was, it’s a good time to review the old notes and add a new entry. Retros aren’t a bad thing, just drop the fluff.
There is nothing inherently wrong with creating project artifacts. But we are not getting paid to create a museum. It is an exhibit though, we need useful artifacts that retain attention and serve a purpose. Let’s be specific. When did expectations change? Why did they change? Who changed them? What was the feedback from each demo? Are there any routine impediments for the team surfaced in the retros?