April 2019

When Daily Scrum Goes Bad

Are your Daily Scrum meetings taking more than 15 minutes?

Scrum Meeting

In Michael Mankins’ and Eric Garton’s book “Time, Talent, Energy: Overcome Organizational Drag and Unleash Your Team’s Productive Power”, they state that most people spend on average 11 hours per week in meetings. The point of meetings is to communicate. Communication is a common problem in large complex software projects and constant (daily) communication is key to successful project management. This is why the Daily Scrum is so important. Daily Scrum (when done correctly) optimizes team collaboration and performance. The goal is for everyone on the development team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours. According to the Scrum Guide daily scrum is a 15-minute time-boxed event that is held every day of the Sprint. If you are consistently going over the 15 minutes, your Daily Scrum might be going bad. If that is the case, then one of two things could be happening:

Inefficient Scrum

During the daily scrum, each team member should answer the following three questions:

  • What did you do yesterday?
  • What will you do today?
  • Are there any impediments in your way?

If more detailed discussions needs to happen, individual (or a group) team members should meet immediately after the Daily Scrum to discuss those issues in more depth. This will allow you to adapt or change the rest of the work in the sprint. One sign of an inefficient scrum is going into too many details during the Daily Scrum (ie- lack of discipline in following the 3 questions). Another issue is providing updates not related to the sprint. This can happen if people outside of the development team attend the Daily Scrum. Daily Scrum is designed to be an internal meeting specifically for the Development Team. If other people attend, it is the job of the Scrum Master to ensure that they do not disrupt the meeting. To keep things efficient and productive the goal is to answer the three questions. If developers are not able to answer the question, “What will I do today?” then it could be a problem with the sprint planning and what needs to be accomplished during the sprint.

Team is too big

If you are being efficient with your Daily Scrum, and still overrunning the time then there maybe too many people on your team. If too many people are providing updates (especially updates that are not relevant), people lose interest. Jeff Bezos famously has the two-pizza rule for both meetings and teams. The rule is that each should only have as many people as two pizzas can feed over lunch. The more people in a meeting, the less productive the meeting will likely be for all involved. The Scrum Guide suggests having between three and nine team members who are actually executing the spring backlog. One way to think about this is every person is a node and they link to other nodes. Those links are the relationships between the nodes. Each relationship requires energy (time) and communication. As the team grows in size, the relationships do not grow linearly, they grow exponentially. Which requires exponentially more communication and energy (time).

If the team has grown too large, splitting up the team seems like a relatively easy solution. But how do you split up the team? A good place to start might be a Dependency Structure Matrix(DSM; also referred to as a Design Structure Matrix).

A DSM analyzes the dependencies between modules and can help project managers in:

  • Deciding which modules should be kept under a single team
  • Deciding which modules can be executed in parallel without any dependency clash

If you do not have any modules that can be executed in parallel (ie- all your modules are tightly coupled to each other). You may need to perform some architectural refactoring to create a more loosely coupled architecture. The benefits to this include improved productivity and improved quality of the software.


No one likes meetings, but they are necessary on complex projects so that everyone knows what everyone else is doing and how their work is affecting other people. Understanding the dependencies between your different software modules can help you optimize your teams and keep the Daily Scrum from going bad. If you want to understand your current software dependencies in a DSM format check out Lattix Architect.

Simplicity is not the solution to Software Complexity

The Solution is Organization

Taming Complexity

Software just keeps getting more complex. As it gets more complex, it becomes harder to maintain. Fixing bugs begins to feel like exchanging old bugs for new ones. There is a clamor to simplify the code. But is simplification the answer? And, what does simplification mean?

A software system is composed of interrelated elements each with different properties. As the number of elements, relationships and properties increase the system gets progressively more complex. If your application has 1000 different components and those components are actually used, there isn’t much you can do about reducing the number of components.

If a financial software deals with many types of securities can you simplify by reducing the number of securities or their interrelationships or the properties that distinguish them? If a medical device requires FDA certification, can you reduce the steps or the artifacts that are required for the certification? If the real world is inherently complex, the software we develop to model it will be complex.

For sure, there is accidental complexity that results from the implementation whether it be inadequate design or tools that are hard to use and understand. How do you separate the accidental complexity from the inherent complexity? And, regardless of where the complexity comes from, how do you deal with it?

In my experience, there is one good general answer to these questions. You need to organize to deal with inherent complexity. You also need to organize to discover the accidental complexity be it clutter or be it design-debt.

Specialize to Distribute Complexity

As the number of parts of a system increases it becomes harder and harder to keep all the details in our heads. No matter how brilliant you are, you aren’t going to know about the details of all the js files or libraries that are in your Nodejs backend (substitute with your favorite frontend or backend framework). At some point it becomes impossible and we feel that the system has become “complex”. Most software that we used today is maintained by teams of developers and is too complex for one person to understand fully.

The key approach to dealing with complexity is through decomposition. We group the elements of the problem into parts and let people specialize in those parts. This is no different from how the complexity of the human body is dealt with by doctors with different specializations. This is a recursive process — as the complexity of a part increases, we decompose further.

The key issue is how to decompose. If you have hundreds of restful APIs how do you group those APIs so that each of the groups is easier to understand? If you have a large number of React components, what is the best strategy to group them? If you have numerous services how do you organize the code that is specific to a service and the code that is shared?

The answer to these questions is what an organization is about.

Organize to Tame Complexity

A good organization tames complexity by dividing it up:

  • It allows different parts to be developed independently most of the time. Of course, if the shared parts are changed it will affect all the impacted parts. On the other hand, if the common parts are fairly stable then you might find yourself in a super productive team. A decomposition that combines loose coupling between cohesive parts is the goal.
  • The skills needed for each of the parts are different. For instance, the team that works on the front end can master css while the backend team can build expertise in databases.

Note that the overall complexity of the system hasn’t decreased. Instead, it is now distributed over multiple teams so that each team (and, ultimately, each developer) deals with reduced complexity. Of course, all this is predicated on an organization that actually allows this to happen.

What about accidental complexity? This complexity is often a result of sub-optimal design. Actually, a good organization is also a great way to uncover poor design. Depending on how bad the design is, the desired decomposition will force you to see and fix the unwanted couplings. Furthermore, poor design in different parts of the decomposition can be dealt with by teams who have a deeper understanding of that part. Often changes and improvements can be made without affecting the entire project.

Without good code organization and a team that reflects it, development is like blind men trying to make sense of an elephant. Do you know how your software is organized? When a change is to be made, is it clear what to change and what will be affected by that change? If not, every change will be like a blind man feeling around an elephant.