Daily assessment stand-ups
More and more software development teams look into and adopting agile practices. In particular Scrum seems to penetrate deep into companies. This is great.
One Scrum practice is the stand-up meeting. This is a nice mechanism for getting people to synchronize their understanding about the progress of the project. I say nice, but perhaps I should say effective. Everyone has a chance of talking and of learning what the status is and what the current challenges are. In most cases, the meeting is held in front of the Scrum board such that the items on the board can serve as visual support for the progress reports.
Getting the team synchronized is important from multiple perspectives. First, making the challenges apparent creates the opportunity for rallying extra resources around it. Second, spreading the knowledge make generates a common language that eases communication. Third, the very fact of everyone having a say empowers the team and creates a sense of unity, of common goals.
However, there are at least two things this meeting does not accomplish:
- it is not technical, and
- it does not solve problems.
Let's take them in order. The Scrum stand-up is not technical. At times, some technical issues are being raised, but generally, the addressed issues are related to the progress as can be observed on the Scrum board. In most cases, the tasks featured on the board take the form of user stories, hence they are not about technical issues related to the intricate inner details of the system, but about the overall external value.
The Scrum stand-up is also not a place to solve problems. It is a place to get people to raise possible problems and identify resources that can be used to solve them. The actual solving is deferred to the responsible people. The idea behind this is to keep the meeting short and not waste the time of people that are only mildly interested in the problem.
And it does serve its purpose well. With a small but constant investment, the overall progress gets transparent and as a result everyone in the team (product owners, scrum masters and developers) can communicate with one another. Yet, even if the external face of a system is important, it is not enough to get the project under control. In the end, software development is made of many technical decisions, too.
Currently, these decisions are not approached explicitly. They are expected to just happen. And they are expected to happen in concert. Design should somehow emerge and everyone should know and follow it. Sure enough, some design does emerge, but it is not clear and it is not known.
How to get it under control? With a tiny daily stand-up. The internal structure of the system is important enough to deserve a small but constant investment. This stand-up should be held separately from the regular stand-up meeting, because it should be technical and it should involve only the technical team. For example, the product owner should not be concerned with it. The reason is that the focus and language of this meeting should be highly technical and the goal is to assess the status of the internal quality and to reach common decisions for correcting it. For it to be effective, the outcome must be more than a list of known problems. The result must be a list of actions.
This simple idea is at the heart of the daily assessment process.