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.

Design Structure Matrix for Complex Systems


In today’s fast paced world, businesses are always looking to understand and streamline their complex systems to become more efficient and effective. One great way to do this is with the Design Structure Matrix (DSM), which offers a unique view of complex systems. DSM analysis allows organizations to optimize the processes of product and system design.

"Engineering work can be procedural and systematic. People think of engineering as a matter of always developing something new, unlike business operations, where you do something over and over again. But we’ve learned that while you may repeat engineering work five or 20 times in your career instead of 100 times a day, there’s a process there. And if you can capture that process, you can improve it.” Steven Eppinger, Professor of Management Science and Engineering Systems, MIT Sloan School

The Design Structure Matrix is a simple, compact, and visual representation of a system or project in the form of a square matrix. This visualization provides insights for system engineers and managers who must design, organize, implement, and maintain the system and its relationships. DSMs are a way of simplifying complex engineering tasks in order to make them more efficient.

DSM analysis helps companies turn product design into a productive routine, rather than an ad-hoc process that is continually being re-invented. Repeating steps is necessary in some projects to make sure things are done correctly and DSM analysis can provide insights into the difference between necessary repetitions and wasteful ones.

Overall, DSMs show the same information as a graph but in a more scalable, concise way that highlights important patterns. As a system grows, graphs begin to look like a giant ball of mud whereas the DSM maintains its readability. DSM analysis groups elements according to their membership in a module or team. This allows insights into minimizing system disruption, which increases system robustness and resilience.

How to Read a DSM

DSMs are graphical in nature and use a matrix display format. The figure below shows a simple DSM model of a system with 12 elements. The cells along the diagonal represent the percentage in each element. Examining any row in the matrix reveals all of the outputs from the element in that row, which in turn are inputs to other elements. Looking down a column shows all the inputs to the element in that column, which in turn are outputs from other elements.

For example, reading across row 3 we see that “Determine Manufacturability” provides output to “Determine Cost” and “Determine Load”. Reading down column 5, we see that “Determine Power Need” receives input from “Determine Cost.”

Design Structure Matrix

Uses of the Design Structure Matrix

There are three basic uses of the DSM: system design, development process, and organizational planning.

System Design

A system design DSM maps components of a complex system in relation to each other. An example is to understand the parts of a computer and how they interact. Using the DSM, you can visualize the system in new and insightful ways allowing you to find inefficiencies. You will better understand when there is a problem with a system that needs to be fixed. If something needs to be changed, you’ll know which other parts of the system will be affected by that change.

Development Process

The development process DSM maps activities and deliverables required for complex procedures. An example would be to streamline the process of real estate construction. Some of the benefits include allowing you to understand the design iterations that will be required to complete the process. You can also smooth out the flow of information by seeing everything that needs to happen and all of the interactions in one place. This leads to being able to get things done faster and more reliably.

Organizational Planning

Organizational planning maps people, teams, and departments that work together to execute complex business workflows. One example is to define the best way to organize the offices of a company so employees are located geographically based on their job function and who they need to communicate with to complete their assignments. The DSM shows all the relationships in a workflow and provides insights for better alignment, physical co-location, and better connection. This leads to quicker workflows with less costly mistakes.


Design Structure Matrix techniques allow for the management of complexity by focusing on the elements and their relationships of a complex system. DSM analysis has proven to be extremely valuable in understanding, designing, and optimizing complex systems including system design, development processes, and organizational planning. Lattix’s complex system solution provides the ability to analyze and optimize your complex system, conduct impact analysis, and measure, track and report on the changes in your system.

For more information, read about Lattix Support for Complex Systems.

Dependency Structure Matrix for Software

The Dependency Structure Matrix or Design Structure Matrix (DSM) is a simple, compact, and visual representation of a system or project in the form of a square matrix. When talking about software, the DSM is a great way to visualize and manage dependencies between modules, which is critical to the management of software projects.

Frequently when discussing software dependencies you are thinking about directed graphs that looks something like this:

Directed Graph View

The DSM represents the same information as a graph, but in a more concise format.

Dependency Structure Matrix

The DSM row and column headers represent the boxes in the graph. The DSM non-empty cells represent the arrows in the graph. Why do you need two different ways to represent the same information? As you can see, the equivalent representation in terms of a graph quickly becomes cluttered and difficult to understand while the DSM scales easily and offers the ability to spot architectural patterns at a glance. Problematic dependencies, such as dependencies between modules, are also easy to identify (red triangles in the DSM above).

What are the benefits of the DSM?

The DSM is particularly good for analyzing large, complex systems. A number of partitioning algorithms can be used on the DSM for architectural discovery and management. For software, we typically recommend the component or reachability algorithms. They help identify layering and componentization within the software system even after architectural intent has eroded.

The results of the partitioning algorithms are displayed as square boxes, called virtual partitions, within the DSM. Here is an example of how the results of the component and reachability partitioners are displayed within the DSM:

Dependency Structure Matrix

Partitioning helps determine:

  • Layering. The layered view of a partition group (called virtual partition), where the higher layer depends on the lower layer but not the other way around. This is a great way to visualize and maintain your current layering structure.
  • Strongly (or cyclically) connected components. These are the subsystems that are interconnected so that there are dependency links that go from one of the subsystems to another. This is also an example of high cohesion. If these components were supposed to be loosely coupled (or modular), breaking the dependencies above the diagonal should be the goal.
  • Independent components within a layer. These are subsystems within a layer that have no dependencies on each other.

Example using a DSM to analyze software architecture

For a real example, we are going to use the open source tool, Ant. Below is a partitioned DSM for apache.org’s Ant 1.5.1. This version of Ant is made up of 20 packages, which contain more than 400 classes.

Dependency Structure Matrix

Once you load Ant into the DSM, it is possible to partition Ant into three subsystems as seen above. These subsystems are layered in a particular order where the lower layers are independent of the higher layer. The first thing that you can observe is that the architecture is not completely consistent. In the cell with the red flag, the “x” (row 4, column 11) shows a feedback loop existing outside of the subsystem.

By keeping the infrastructure (ant) independent of tasks (ant.taskdefs), Ant designers had designed the layering to allow additional tasks to be developed by multiple developers simultaneously. The DSM above shows that they were only partially successful in that goal. The conditional tasks (taskdefs.condition, column 11), which is in the infrastructure component, is used by the tasks component. This creates a feedback loop or cyclic dependency between infrastructure and task components. One possible solution to this cyclic dependency is to move the conditional tasks into the tasks component.

The DSM also highlights how intertwined the types subsystem (row 9) is in the framework. This means that developers of newer types need to understand and deal with the entire ant infrastructure. If future improvements require parallel and easy development of new types, then it would be advisable to define a component architecture for types. These are some of the quick insights you can get by visualizing your architecture with a DSM.


System complexity results from dependencies that violate the intended architecture as you saw in the Ant example above. Bad dependencies prevent modularity. The lack of a well-defined and well-understood architecture makes software changes difficult. This leads to high software maintenance costs.

As another example, we have analyzed the Android kernel using Lattix Architect to illustrate how understanding software architecture and identifying dependencies can help any development organization manage the impact of change, improve productivity, simplify code maintenance, and reduce risk. You can view the results in this whitepaper. If you are interested in seeing how your software project looks in Lattix Architect, sign up for a free trial.

Mastering Complexity

Mastering Complexity is a new Dependency Structure Matrix (DSM) book by Stephen Denker. Steve is a management consultant who has worked with DSMs for many decades and his vast experience is reflected in the book.

This is easily one of the most approachable books that I have come across. The early chapters were easy to read, well-illustrated, and explained the concepts well. However, what comes as a surprise was when the simple concepts of the early chapters give way to much deeper material. The book covers advanced concepts such as reducing cycle time, scheduling reviews, risk management, partitioning and tearing. In keeping with the philosophy of the earlier chapters, these sections are also covered in a concise manner. In fact, they are so concise that you would be advised to read some of the chapters in conjunction with the original research they are based on; otherwise, you might feel short-changed by some of the later chapters.

For me, the most interesting aspects of the book are the links to practice. One of my favorite sections is the chapter on reviews. It shows very simply how the ordering of coupled activities ties into review tasks. I also found the sections that show organizational coupling based on tasks to be quite revealing. One of the later chapters even has an analysis of inner-city crime and violence using DSMs to identify the control dependencies - a nice example of the out-of-the-box thinking that is enabled by DSMs.

“Mastering Complexity” is a welcome addition to the swelling roster of DSM books. Without question, systems are becoming far more complex these days. They are becoming more varied with interactions that involve a large number of tasks, people, and other elements. Today, there is an urgent need to document current approaches and to push on the frontier of new approaches for managing complexity. Denker’s book is a fine start for that process.

Analyzing ArgoUML

Johan van den Muijsenberg just published (in Dutch) his analysis of ArgoUML in a magazine published by the Java User Group in Netherlands. The brilliance of Johan's analysis is in how logically straightforward it is and how that analysis yields clearly identifiable architectural issues and fixes. It is yet another example of how easily architecture erodes from its intended design. If more teams were to focus on fixing "bugs" in architecture, they would reap rich dividends in improved quality and productivity.

My main complaint is why Dutch readers should be the only ones to benefit from this interesting and useful article. Here is a Google translation into English.

What Star Trek Can Teach Us About Software Architecture

What Star Trek Can Teach Us About Software Architecture

The writers of Star Trek Voyager envisioned a game that was worthy of challenging the superior mind and intellect of a Vulcan. They called it Kal-toh. To the human eye, Kal-toh looks to be a high-tech fusion of Jenga and chess. Lieutenant Tuvok of the starship Voyager would be quick to tell you "Kal-toh is to chess as chess is to tic-tac-toe.”

In Kal-toh, the players are presented with rod like game pieces that are in total chaos. This could be compared to legacy code with no discernable architecture or documentation – spaghetti code or a big ball of mud. The object of Kal-toh is to move the pieces (systems and subsystems) until a perfect structure or architecture is formed. The challenge in Kal-toh, as in Software Architecture Design, is that if you move the wrong piece, the entire structure can collapse.

Kal-toh and Software Architecture are based on very similar principles. An experienced Kal-toh player has the ability to visualize the complexity in the Kal-toh puzzle. Without fully understanding how the Kal-toh pieces interact with each other there is no road map to create stability in the structure.

Visualizing software systems is hard because there are a very large number of elements with dependencies on each other. Therefore, the ability to scale is critical. Furthermore, the purpose of visualization is to reveal the architecture. This means that it is important to not just draw the dependencies but to show where dependencies are missing and to highlight the problematic dependencies.

Lattix has pioneered an award winning approach for large scale visualization based on a Dependency Structure Matrix (DSM). Lattix incorporates hierarchy in the display, while showing the architectural decomposition and the dependencies at the same time. Built-in algorithms help discover architecture. What-if capabilities allow users to modify the current structure to reflect the desired architecture. Users get a big picture view while still identifying problematic dependencies. Lattix also provides an intuitive Conceptual Architecture diagram that takes some of the lessons of a DSM and makes them accessible to a wider audience.

Let me leave you with a Star Trek quote. Lieutenant Tuvok said “Kal-toh is not about striving for balance. It is about finding the seeds of order, even in the midst of profound chaos." The same can be said about Lattix.

Book: Design Structure Matrix Methods and Applications

There is a major new book out: Design Structure Matrix Methods and Applications. The authors, Steven D. Eppinger and Tyson R. Browning, may not be household names, but they are rock stars in the world of DSMs. This book contains a clear and lucid introduction to DSMs. However, what makes this book so compelling is its rich collection of examples.

The book contains 44 real world examples as varied as NASA's Mars Pathfinder, BP’s LNG Terminal, LLBean’s Software Code Base, or Luftfahrt’s Airport Security System. These examples drive home the generality and simplicity of DSMs. I am also proud to note that the LLBean analysis was done using Lattix tools.

The book groups these examples into 4 categories:

  • Product Architecture
  • Organization Architecture
  • Process Architecture
  • Multidomain Architecture

While the first three applications have existed for some time, the application of DSMs to link and analyze multiple domains is relatively new. This is a natural progression; and, it raises interesting new possibilities. For instance, we know that different stake holders have different ways of looking at the architecture of a complex system. We often choose to think of them as separate views. Yet, these views are related. Can a system be designed without the designer being cognizant of how it will be deployed? The multi-domain DSMs may provide an effective mechanism to capture those relationships.