Recently, I have initiated a poll in one of the “quality” engaging communities on LinkedIn. The poll was about the most common digital product development challenges (I called them pain points, and this will bite me hard later on). The poll got a solid amount of engagement and interesting comments, and I couldn’t help but write about it and its discovery.
The Poll
So, here is the poll and its result as of January 22nd, 2024:
In digital product development, challenges are commonly perceived as an intrinsic part of the journey. As you can see, within 7 days (the duration of the poll), quite a lot of people participated, and, not surprisingly, the “Scope creep” challenge got the golden medal. “Excess of development debt and defects” is a runner-up, and “Constant story carryover” came very close after. Not surprisingly at all.
Within a respectful discussion that unraveled under the poll, a few key discoveries arose, which I would like to share with you today.
Scope Management Predominates
A significant (52%) of poll respondents identified scope changes and the creeping up of scope as the most prevalent pain point in digital product development. This highlights the ongoing challenge of managing and controlling project scope effectively. We have written about this challenge a lot and have to admit that this challenge appears so common it may deserve its own Agile ritual to be crafted to mitigate its effect. But, it’s absolutely clear that something must be done to make sure that MVP stays that “MVP” and not “MVP and a couple more things. Three. Five. A few.” Since so many teams suffer from this issue, it may need to be addressed on the next level.
Engineering Managers’ Dilemma
One perspective noted in the poll that, although mentioned as potentially main challenges, they have discovered that constant tweaking of processes by engineering managers in pursuit of fixing challenges can be a major challenge itself. The focus, it was argued, should be on addressing customers’ needs rather than incessantly adjusting internal processes.
I tend to agree; the focus should always be on the deliverable and its value, although we still have to go through the process of delivery. That’s ultimately our goal—to launch a solid product or feature. However, if we constantly run into issues with defects or changing requirements, the success of our enterprise gets compromised.
Communication Challenges
Poor communication between teams was pointed out as a common pain point not mentioned in the poll. While Agile practices were suggested as a solution, there was a counter-opinion that Agile alone cannot solve communication problems. In all sincerity, Agile creates a welcoming environment for fostering successful communication, but it’s ultimately up to leaders to ensure that fostering is happening. Not two teams are the same; in some interactions, flow easily and smoothly, in others… well, they could be better.
Cultural and Management Considerations
Emphasis was placed on the cultural and management (leadership) aspects of challenges. It was suggested that in healthy organizations, pain points are promptly addressed, indicating that persistent challenges might stem from failures in culture and management.
This perspective underscores the critical role of management and leadership in shaping a healthy and productive development environment. Effective leadership, which is proactive in predicting possible issues based on its knowledge of the development process and applies an understanding of the team and cultural dynamics in the company, appears essential for overcoming digital product development challenges.
“Dysfunction Indicators”
The term “dysfunction indicators” was introduced, emphasizing that challenges should be viewed as symptoms rather than isolated pain points. Identifying the root causes is essential for meaningful improvement. The pains of the development challenges are certainly painful but result from actual “pain points” – the breaks in the process, though one may not discover those pain points until feeling the pain from it. These challenges are more of the indicators that something is not working. And it’s up to a good servant leader to be in the inquiry as to what that is.
Challenges and the Absence Thereof
Interestingly, a subset of commenters noted that they do not experience the mentioned “pain points” in their teams, or any pain points whatsoever, claiming that everything works seamlessly. This raises the question: Is it possible to avoid challenges completely, or could it be that some teams do not perceive or acknowledge the existing ones? Exploring the idea that challenges are inherent in development and may manifest differently across teams adds depth to the ongoing discussion.
Defining and Addressing Pain Points
The importance of defining pain points was highlighted, emphasizing that understanding what qualifies as a pain point is crucial. The interpretation of challenges may vary among teams, requiring a clear definition to address them effectively. So, how shall we address them, and, most importantly, how shall we predict them by noticing some early signs they display?
Addressing the Pains as Disfunction Indicators
From scope management to cultural and communication issues, teams navigate a complex terrain. Recognizing these challenges as opportunities for improvement and cultivating a culture of continuous learning and adaptation is key to overcoming them. As the software development world evolves, addressing these pain points becomes crucial for delivering high-quality, timely, and valuable digital products.
While many teams appear to showcase exceptional functionality, a majority still grapples with various process and product-related challenges. In this article, we’ll delve into the pain points and challenges faced by digital development teams based on a recent survey. Let’s explore the nuances of these challenges and, more importantly, present effective solutions.
Recognizing Challenges Before They Arise
We all need a sanity check once in a while. It’s much easier to fix things when you start noticing that the process is not working its best, rather than when it’s all crumbling down. Let’s see if we can tackle most common “pains” of the digital product development, and provide any valuable suggestions on which dysfunctions those may indicate and how to address them on early stages or prevent them from happening.
Project Delays, Budget Overruns, and Development Debt
This may indicate insufficient planning and incorrect estimation. Even a slight shift in the projected feature or MVP launch dates or cost increase should be an early indicator that there is a miscalculation somewhere. Even one carryover story should be a warning sign. I have observed project reviews signaling that the project is in the “yellow” or even “red” zones (indicating being outside of projected timelines), and nothing was being done about it, as if it was expected and accepted. Very often, even a couple of months’ delay in the release may compromise the success of the whole enterprise.
Takeaway: Track timelines and budgets closely, regularly assess progress, do not take delays or excess spending lightly, and address deviations promptly.
Requirement Clarification Mid-Development, Business Priorities and Scope Shift and Excess of Defects
All of these could be strong indicators of inadequate or even broken communication between business and development and/or a lack of a stable business strategy. These dysfunctions are always related to business and business stakeholders, although they are not the only ones to blame. Where business strategy lies primarily in the hands of business executives, it’s in the power of Product Management to help them translate their bird’s eye view ideas into tangible strategy, define that sharp vision of the product roadmap, and help them understand the importance of staying on course as that course was chosen, and only deviate from the path of success if that success may be compromised by not adjusting in time to rapidly changing market needs.
The same goes for the excess of defects. It is very rarely the result of low-quality work and is mostly caused by insufficient or incorrect communication of the requirements to the team. Communication is key here, and the middlemen of that communication are the Product Manager and Product Owner. But they are definitely not the only responsible parties when it comes to establishing proper handling of the requirements. Both business and technology are partners in the endeavor of delivering a successful product! Both parties must (yes, not supposed to, but must!) be in constant inquiry about the clarity of the requirements – if they were clearly understood when they were submitted and received. Product leaders can definitely be facilitators of the process, but all responsibility may not lie just on them.
Takeaway: Establish robust communication channels between business and developers with fast and simple feedback loops, conduct comprehensive requirement analysis before development, and ensure constant inquiry into the correspondence of said requirements with dynamic market needs to maintain the same dynamic and low-impact scope alterations if needed, staying aware of key pivotal points in the development when such alterations may be required without highly impacting project success.
Lack of solid Team Spirit, Frequent Team Changes, and Cross-functional Partnership
We truly believe that leadership is either good or it doesn’t exist. Any issues related to the quality of internal and external team collaboration may be signs of void leadership. It’s a false premise that, since teams operate within Agile methodology, they will self-organize. There probably are teams like that who don’t need anyone like a scrum master, product owner, or product manager to get together, put their minds into it, and in addition to delivering solid code, will also deliver a solid process. I am not saying it’s not possible. It’s just very rare.
Usually, there must be the driving power, the inspiration, the fire, the Prometheus – who will ignite that passion to work together with a common goal of creating something great. Who will that be – it doesn’t really matter. But it will be the Leader. Or the Leaders. They will be able to see the team as a whole and each individual in it, and craft the best environment for that specific group of people in which they will flourish.
The same applies to inter-team relationships, where good leadership will be that flagman to set up all necessary communication channels for successful interaction and ensure that teams’ mutual goals are supported through completion.
Takeaway: Be the Servant Leader, even if you are formally not. Servant Leader takes responsibility for team’s success or stepping back when other leadership takes over. Encourage open communication, create a safe space for sharing ideas. Make sure that everyone’s voice is heard. Ensure these communication practices spread over interactions with other teams. Stay in theconstant inquiry of the quality of leadership provided.
In digital product development, challenges often serve as veiled indicators of underlying issues within teams. Perceived pain points may be manifestations of deeper dysfunctions that are true pain points. To swim through these seas effectively, it is crucial for teams to stay vigilant, maintain a continuous inquiry into their development processes, and be attuned to early signs of challenges. Whether pertaining to requirements, team dynamics, or processes, a constant state of inquiry keeps teams agile, responsive, and prepared to address emerging challenges before they escalate.
No responses yet