Trim your Standup

Time to expand on my previous post. If you are going to do synchronous standups, which you should think about what is this achieving that is not available from a written format and how will you differentiate it from a status meeting.

I will summarize the original purpose of the daily standup.

• When you must get a project out with a hard deadline
• It is a call to action a verb not a noun or a historic document, what has happened is done. What needs to happen today, right now, and how it impacts others today. The documentation is important and should be done in a written format for search and archival accuracy

Historic notes on the standup practice

First it was never mentioned as a part of the Agile Manifesto as a practice, it just happened to be something they did to align themselves everyday in person. Second the situation that the software they were writing under was a complete outlier case to how almost any software product is written now. It was way behind schedule, over budget, and needed to get something released and they worked on the project till it was completed and then disbanded.

Now think of how the majority of SAFe is practiced under strict budgets, timelines, and with no real customers only internal "stakeholders" in a forever death march.

Alas I digress, but are you performing demonstrative actions for cargo cult compliance to what other larger or more successful software projects and companies have done before or are you practically using this as the last resort it was intended as.

Notable examples of cargo cult practices in programming are the open floor plan with concrete floors as the optimal programming environment. The reason that companies like Amazon or Google chose this format originally is they were broke and warehouses were cheaper to rent than offices and the furniture they could bring to it quickly for a lot of people were flat picnic style tables and so the cult of open floor plan got associated with software companies success and then everyone started copying the physical situation and hoping the same software success would be had. It did not happen.

Side effects in the Standup

The majority of programmers do not examine the political practices of their organizations as they wish to focus on code. A standup is a business practice, but all business practices are specialized political decisions by those within the business. This is usually the owners or executives making the decisions, but not always as a talking point of agile is empowering those that are writing the code to be empowered to make decisions on what that process looks like and that it is possible that the decision is to do standups to fulfill the goals of the organization are the best solution. Each situation should be examined and experimented on to get accurate and relevant information to acton.

Now thinking ahead to what needs to happen regularly is a difficult practice and takes some time and most standups are scheduled for the beginning of the workday when you have not had time to think over all the details of the day therefore people use Attribute substitution to show they are making progress and get back to working on their code issues.

I will quote out the important part of why I think the daily standup always devolves to a glorified status meeting without constant vigilance

Hence, when someone tries to answer a difficult question, they may actually answer a related but different question, without realizing that a substitution has taken place.

Conclusion

Status is important and perhaps you require it everyday there are many ways to get this information

• Automated commit summaries
• Written documentation emails, chats, other messages
• Written check-ins

Of all of the above the written check-in allows the person reporting to give context to the automatizable points proceeding it and should be the default option. That would leave if it remains the synchronous standup to be at first a place for callout actions to occur:

• As in issues and problems not statuses to be worked on
• Collaboration points that are exposed from the backing documentation of the written check-ins

Addendum

My opinions are not alone nor invalid