top of page

14 results found with an empty search

  • Feeling pain vs the actual cause of pain in software development

    For quite some time I dealt with pain in my feet due to plantar fasciitis and it wasn’t until a few months ago that I finally fully recovered from this injury. The difference between the last few months and the prior time period was that I learned that the cause of my pain was not where I felt the pain, but rather due to tightness in my hamstrings. This was hard to believe because my hamstrings felt fine, but as I learned more about this particular injury it was plausible that this was the root of the issue. Armed with this new information, I began to incorporate daily hamstring stretches into my daily routine. Within a week I started to feel a slight improvement and after three months the pain has completely gone away. Before I knew that the issue lied with my hamstrings, I spent a lot of time targeting remedial solutions at the point of the pain. I would stretch my feet, massage them, and even bought sneakers with more padding thinking that this would help alleviate the pain. Unfortunately, in the long run there was little to no benefit from those efforts. In hindsight, I wish I had spent more time understanding the actual potential causes of this issue as it would have saved me time and money because I would have been able to implement better solutions from the moment I started experiencing discomfort. When I think about this injury and my path to recovery it is hard for me to ignore the parallels with this experience and the similar experiences that I have had as a product manager on software development teams. As such I want to share some flags that you can look out for that are strong indicators that your team is experiencing pain in one area, but most likely the issue lies elsewhere. Furthermore, I want to give you some tips on how to resolve those types of issues. The following issues usually indicate that the root of the problem often lies elsewhere: Unexpected consequences or reopened defects from feature or bug changes Flip-flopping of product requirements Unexpected consequences or reopened defects: Pain area: The team frequently experiences unexpected issues due to a new feature enhancement or a defect fix which then leads to fire fighting and additional development work. Actual problem area: In my experience the common culprit of this issue is lack of team understanding of how a portion of the work impacts the broader body of work. This gap in understanding leads to unexpected consequences when those portions are introduced to the system. Resolution: It is critical to bridge the gap of understanding among all team members from design, to engineering, to QA. Maintaining up to date user journey flows and architecture diagrams help provide visuals that allow one to understand the impact a change in one area can impact the other areas of the system. Reviewing these documents prior to beginning work on a feature helps ensure that the different paths of a solution are accounted for in design, implementation, and testing which then begins to reduce the frequency and impact of unintended issues as the team broadens their awareness of the whole system. Flip-flopping product requirements: Pain area: The same feature(s) keeps getting re-worked and progress on the other items stalls as the team keeps revisiting the same items. Actual problem area: In my experience this issue often lies between the stakeholders and product and design. When we produce solutions that are half-baked, meaning that those solutions do not fully meet the needs of the business then you are likely to find yourself re-working the same aspects of the application. Resolution: The best way to prevent this issue is to be rigorous with the solutions being presented to stakeholders during the design phase such that the feedback process elicits as many possible issues with the proposed solutions so that when it is time for implementation the proposed solution has undergone sufficient iterations to capture and resolve as many possible unknowns prior to implementation.

  • Differences between efficient and effective Daily Stand-ups

    Early in my career I wondered why, at times, a team ends a standup with more unanswered questions about the progress in the given sprint than they started with. It confused me as to how the responses to the three simple standup questions could produce such ambiguity when they were designed to give us clarity on the progress. I could not shake the feeling that something was amiss even when stand-ups were run efficiently i.e. under 15 minutes, at the same time, and the same place. After working with many different teams and running over a thousand stand-ups I learned that there is a big difference between an efficient standup and an effective standup. An efficient standup goes through the motions expediently, but an effective standup provides the insight to make informed decisions as to what are the next best steps to take as a team. Imagine that you are in standup and one of your team members provide the following update “Yesterday I worked on my story, today I will continue on my story, no blockers” versus “Yesterday I worked on my story and discovered an issue with the application unrelated to my story that impacts the performance of the application. Today I will continue with my story and I also want to discuss the impact of this performance issue with the team to see if we should prioritize it or not.” The second version of the update shares useful information that allows the team to determine the best course of action. This form of communication keeps in mind the greater good of the team and allows the team to be more effective. Unfortunately, many teams have one or more team members that resort to the first type of update when they should be sharing a version of the second one. The good news is that these issues can be fixed when you help foster an environment that promotes healthy communication and collaboration. Helping your team address these issues will bring the team closer towards operating more effectively to get the most value out of standup. Finally, I strongly believe every team can achieve both efficiency and effectiveness at standup by diligently encouraging better communication and teamwork. Improvements in this area will not occur overnight, but they will occur when there is a persistence to become the high performing team that your team knows it is capable of becoming. On this journey your team will discover that they did not need to work any harder to meet their goals, instead they just needed to work smarter by working together. Common standup issues Here is a list of common issues that I have encountered that can arise during standup and possible actions to take to resolve them. Miscommunication Lack of a common language: A common form of miscommunication occurs when team members use different definitions to define their work. I have seen team members confuse each other when using a word like “done” to describe their status when they actually meant “dev complete.” These slight differences in word choices can alter the team’s expectations about the work to be done next. One common and effective way to address this issue is to align the sprint board’s swim-lanes with the team’s workflow. Unclear ownership: Miscommunication can occur when it is ambiguous who the owner of the task is. Work can slip through the cracks when owners are not explicitly assigned to it and when a team member is asked about a given task they may respond something along the lines of “I thought they were going to do it.” Be clear and rigorous in task assignment. I recommend tracking all tasks with whichever ticket tracking you are using like JIRA. Fear of sharing bad news: Sometimes team members fear sharing bad news because they think that it will reflect poorly on them or the team. This miscommunication occurs due to omission of the issue or when the issue is shared much later than it should be. This prevents the team from taking corrective action as soon as possible. It is imperative to not delve into the blame game and instead place that energy towards the problem at hand. When team members begin to share issues impacting the team in a timely manner you can positively reinforce this positive behavior by recognizing the team members that share the issue that they observed and praising them for bringing it to the team’s attention. Lack of Teamwork Prioritizing individual priorities over team priorities: Team members that prioritize their individual tasks at the expense of the team’s priorities means that the optimal value to the customer is not being delivered. The value to the customer should always be the first priority and the team needs to prioritize that over their own tasks. Team members should feel comfortable to shift their tasks in order to maximize customer value. Raise issues that impact the team: Some team members are lazered focused on their individual tasks that they either do not recognize or forget to let the team know when they discover an issue that impacts the team. Consistently remind the team to put the team’s priorities over their individual tasks and continue to build this habit through positive reinforcement. Repetitive updates or ambiguous progress is often an issue of team members not seeking the help they need from others Rabbit holes: Team members can dig themselves into rabbit holes when team members attempt to figure out solutions to their own problems and continue to attempt to resolve the problem when they should be seeking help from the team. Sometimes a fresh pair of eyes offers a new perspective to the problem that yields a path forward to the solution. Figure out ways for your team to experience the benefits of receiving help and embed them into your team’s workflow. Delegation: Some team members have a tendency to take on a lot more work than they can do in a given sprint which increases the amount of stress those team members experience as the amount of work piles up. There are a number of benefits with delegation and one of the most important is that it makes the other team members feel valued as they are given important tasks. Extra tip: beware of frustration or annoyance in the tone of voice or the body language of your team members as these are other ways your team may be communicating symptoms of these issues. Finally, daily stand-ups are much better when we have fun and bring positive energy so bring a smile, have some fun, and try to make each other’s day just a little bit better than it was 15 minutes ago.

bottom of page