Skip to main content

Continuous Problem Solving

Teams in modern software development face a wide variety of problems on a daily basis. These teams are smart, motivated, and possess a wide range of personal experience.

Continuous Problem Solving

The team starts. Depending on the contracting cycle, you’ve been anticipating this day for weeks or even months. You know each other, are familiar with work patterns, and have each been successful on different projects. As you start, you review the contracts for things you have to do and match that with the massive list of customer needs to be solved. Now the question is, where do we start?

One useful adjustment suggests deciding which tasks are more complicated than others and require more resources. And with those more complicated tasks, you can break them into smaller tasks that can be completed sooner, meeting a Minimum Viable Product approach and letting the whole team feel successful. This continuous problem-solving (CPS) approach (framework below) provides a useful starting point to make those decisions.

Teams in modern software development face a wide variety of problems on a daily basis. These teams are smart, motivated, and possess a wide range of personal experience. While these teams eventually solve problems effectively, the time to coordinate and plan for these problems can use cycles better spent in actually solving problems rather than merely creating a new process for each iteration. Problems to be solved include management and software development, personal conflicts, and business development.

Diagram detailing continuous problem solving

BrainGu uses the (rs)2 format to assess quality through resilient, scalable, repeatable, and secure functions. CPS supports these concepts, has worked across BrainGu contracts, and draws heavily on proven Agile and DevOps concepts. The concept is scalable as different problems can occur at different levels based on the team concept and the typical problems. Resilience occurs through having a stable approach that one can move backward and forward along the iterations. Security is not identified as an individual ask, but will built into the approach for software. This means the epics, stories, and tasks will have security guidance as part of the acceptance criteria. A contracting task might include protecting PII while software development could include various scans or approvals.

CPS divides problems into four tiers, simple, complicated, complex, and strategic. If we compare these to yarn, tier 1 is untying a knot from a single piece of yarn; one can clearly visualize where to go. Tier 2 is several pieces of yarn tied together; it can still be unraveled but takes more time. Tier 3 works the same, unraveling an entire ball of yarn, and Tier 4, strategic issues, asks where the yarn came from in the first place and why it is that color. An example problem might be that a user approaches and wants to build a new API gateway to manage their customer access. The entire problem is a Tier 3 as multiple solutions need to be leveraged together. This might break into Tier 2 issues for designing a gateway, connecting to existing databases and tools, identifying user access strategy, and building a web access point. At Tier 1, we have issues for a single individual, deploying a completed system, identifying users, building a new user account request, and other similar issues.

That provides an engineering example, but you ask, “how does that apply to other work, such as business operations?” From a business perspective, if the problem is integrating a new customer, that becomes a Tier 3 issue. The Tier 2 issues might be completing the contract, understanding customer needs, and identifying the right individuals. Tier 1 issues might be ensuring the payments occur correctly, hiring the right people to fill the contract, and getting bodies on-site at the right time and place.

Overall, this CPS approach is not a firm set of rules but a framework. The framework helps by reducing the time one spends on deciding how to approach the problem to time actually spent solving the problem. It assists with traditional Agile in limiting context switches. It also helps identify resources through the tiers to manage capacity and velocity better. Using this CPS won’t solve your problems for you, but it will make the process less painful and more expedient for everyone involved.


Related Posts

View From The Edge View From The Edge

View From The Edge

Teams in modern software development face a wide variety of problems on a daily basis. These teams are smart, motivated, and possess a wide range of personal experience.