When it comes to software development, problems can arise at any point during the process. Even if you lay out every detail all the way from start to finish, an unexpected, headache-inducing issue can still come up, demanding your full attention.
But how do you know where the root cause really lies? Agile gives us a practical framework, in the form the concept of “People, Process, Tools,” that helps us diagnose issues in a more systematic way. In my experience, it’s rarely the tools piece (although that happens), and 80% of the time the conundrum is with either people (the team) or process.
Identifying the root cause of a software development problem requires some investigation. You have to examine every piece of the puzzle to see what doesn’t fit.
Team problems can refer to issues arising from the performance of an individual employee, such as not completing tasks, completing tasks incorrectly, producing low quality work or slowing other team members down. They can also arise from the way the team functions as a group and what norms (explicit or, more often, implicit) the team has.
Process problems are generally issues that arise when everyone does their job well, but the combined outcome of their effort is suboptimal.
For example, let’s say you had a fantastic product launch, and you tell your team that you want to look at the analytics. They respond, “What analytics?” What you hope is a badly timed joke turns out to be a real issue stemming from hidden assumptions. You assumed the inclusion of analytics was an obvious thing to do, and the team assumed you’d tell them explicitly every item to include.
This is a process issue. In this particular case, the process is not transparent enough, which causes a misalignment. But it’s nothing a good retrospective with solid team ownership can’t fix.
When teams are disorganized or don’t have the right people working in the right roles, software development problems can become complicated and hard to manage.
So to diagnose what’s not working on your team, start with a bird’s eye-view and work your way down.
A team that’s consistently aligned with your company’s culture sets the foundation for your overall success. To determine where your team is in terms of culture, ask yourself the following questions:
In this phase of problem-solving, you need to have an honest conversation with yourself about the culture of your entire company. If your company culture is holding your software development team back, then you have a greater challenge on your hands than fixing a team-level issue. But if you can see other departments setting and achieving goals without the issues your team is experiencing, then your company culture and values are probably not the problem.
Next, determine whether each individual team member fits well with your company culture.
This isn’t about skill or talent. If someone doesn’t align with your culture, values, and overall mission, then they need to be replaced. It may sound harsh, but maintaining a common culture is crucial if you want to build an effective team.
To analyze the process, you’ll need to define it. This is best done collectively and introspectively. It will help you as a leader to understand both the big picture and to zoom in to the details, since those do matter in this case.
Get together for a white-boarding session with your team and walk through the process of getting a working epic/story or task out, from inception to production deployment. Pay special attention to the hand-off process between different functional areas — from product managers and designers to engineers and technical staff, from engineers to ops, and so on.
This is where agile can be as prescriptive or as lightweight as you want. The specificity for your process really depends on the size and, in some cases, the technical maturity of your team. For example, three buddies in a WeWork whipping up the latest crypto app would likely be very efficient just following Agile principles with next to no formal process. On the other hand, a globally-distributed engineering organization of 500+ engineers working on mission-critical software needs to have a lot more robust and detailed approach, probably something like Scaled Agile. Being pragmatic and not overprescribing for the size of your team will help them actually adopt the process changes you recommend.
Once you have your process clearly defined and laid out, then determine who does what job within that process. From there, you can create an accountability chart that defines the roles in your process and who does them. That can serve as a basis for evolving the process, ensuring you have clear accountability for each phase of the software development lifecycle.
When you have a fully completed process map (especially those hand-off/integration points!) and an accountability chart, some process issues will become clear. Others, though, may not. Your process map needs to be a constantly evolving tool that responds to change. It might be helpful to include a review of it in your retrospectives or in future 5 Whys and issue analysis sessions, since the gaps will be easier to diagnose.
Your team is solid and motivated, empowered and with a high degree of cohesion. The process is clear and lean. Yet there are still major issues. What gives?
It might be the overall technical maturity of the team or of an individual team member. You might be asking too much of them.
For example, say you have an employee named John in the product owner role. Is John a good product owner? What is a product owner supposed to do anyway? Does he know that? Does he fulfill those expectations? Does John struggle because he doesn’t have the skills, or is it because he’s doing five different jobs at once?
Get crystal clear on where each employee performs optimally and where they lack. Asking for others’ viewpoints, especially senior managers or even external advisors, may also help you determine where individuals would work best in your process. After your analysis, you can also talk with each employee about your overall vision for the product and what you’d like their role to be in developing it.
As you determine each person’s capability, you might decide they’re not operating at the level the team or process needs. If that’s the case, you have two options: train them in their current role, or move them to a different part of the process.
You might give them lower-level tasks, split their responsibilities or provide another person to help them. However, if they’re explicitly and solely holding the process back, like someone who doesn’t align with your company culture, letting them go might be the only option.
The agile software development process is an iterative one, so it’s important to monitor and manage the effectiveness of your team regularly.
This three-step process can help you pinpoint problems with your team and your process, helping you get back on track sooner rather than later. The insights and solutions you discover will be worth the trouble.
.gif)
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
.png)