Developers are moving away from functioning as “order takers”, focused almost exclusively on coding, to collaborating with solution sponsors, stakeholders, customers, and end users (i.e., Stakeholder Community) to define, verify, and validate what they develop.  Many technical contributors find this level of direct collaboration difficult to manage alongside their growing list of technical responsibilities.

This article is the last of a four-part series about why so many developers are fed up with Agile and why so many organizations fail to achieve Agile’s much-touted benefits.  The common thread across the series is that what often passes for Agile is anything but Agile.

The other topics covered in this series are:

• The Never-Ending Agile Grind – Developers often feel overwhelmed by the constant pressure to produce under tight deadlines.
• Greater Visibility & Oversight with Less Control – The “radical transparency” of Agile approaches, such as Scrum and Kanban, is often exploited by management as an opportunity to micromanage development teams.
• Top-Down Driven Agile – Technical contributors often have little say in how their organizations or sponsors implement Agile, leading to the imposition of unnecessary, ineffective, and, often, counterproductive practices on development teams.

Difficulties Collaborating with Stakeholders

One of the defining characteristics of Agile is the fostering of close and ongoing collaboration between software development teams and their Stakeholder Communities.  As the fourth Principle of Agile Software Development states:

Business people and developers must work together daily throughout the project

http://agilemanifesto.org/principles.html

Needs, expectations, and feedback from the Stakeholder Community guide what Agile teams build.  Delivering features and capabilities iteratively and incrementally affords more opportunities to inspect and adapt deliverables and team processes accordingly.

The ultimate validation of a solution’s value is use by real customers and end users.  Prior to release, Agile teams test and validate software increments in collaboration with their respective Stakeholder Communities.  After release, development and/or operations teams monitor and evaluate how evolving solutions are used and perform.  Lessons learned inform decisions about upcoming development.

Many Agile projects fail because this vital feedback loop breaks down or is never established.  Achieving effective collaboration between groups of people who hold different ideas about what is needed or important is difficult.  The trust and respect upon which collaboration depends take time and effort to build and are easily undermined.  Avoiding or mitigating misunderstandings, disagreements, and conflicts starts with people understanding each other’s perspectives.

The Developers’ Perspective

Below are some of the most common issues developers encounter when dealing with Stakeholder Community members.

There is also the issue of whether development teams have access to the right stakeholders (or any stakeholders at all).  Too often, those who provide requirements do not have intimate understanding of relevant business or mission processes or of customer and end-user needs.  This is especially true in organizations with traditional project management cultures where project or program managers, architects, and senior engineers are expected to “know” customer needs yet rarely interact with them.

The Stakeholders’ Perspective

Collaboration is a two-way street.  Agilists approach requirements from a customer-centric perspective.  Unfortunately, too many developers think about solutions from the perspective of what they want to build.  They define requirements as development tasks to accomplish or as system functionality to develop.  In the eyes of the Stakeholder Community, these attitudes come across in the following ways:

Expanding Technical Responsibilities

Along with increased expectations for Agile development teams to interact with stakeholders, the scope of work done by software developers continues to grow.

Back in the 80s and 90s, a software developer was considered proficient if he or she specialized in one operating system and one programming language.  In the 90s and the aughts, many, if not most, developers specialized as front-end or back-end developers. There were much fewer tools to master and most development was custom rather than based on third-party components and frameworks.  Also, the work associated with the full lifecycle management of applications was highly specialized and assigned to different people.

The advent of the Cloud and DevOps changed all of that.  Now developers are expected to be “full-stack developers” capable of developing both the front and backend components of complete releasable features.  Virtual computing and the Cloud broke down operating system-based development siloes. Open-source development wildly increased the number of tools and frameworks available.  Great efficiencies brought about by DevOps came at the price of developers learning DevOps tools, developing automation scripts, and managing DevOps pipelines.

A proficient developer today is a master of multiple programing languages, highly conversant in more than one operating system, comfortable using a plethora of tools and frameworks, and regularly contributes to testing and DevOps automation.  Software developers now perform a lot of work that used to be set aside for specialists such as system administrators, configuration managers, build engineers, testers, etc. While a lot of that work is now automated or abstracted away from developers, the scope of what is considered development work is much larger than before.

Many software developers feel overwhelmed by expectations to keep up with the ever-increasing pace of technological change, consistently deliver value, and collaborate with stakeholders.  Most developers entered the field for the opportunity to develop software for a living and concentrate on becoming better technologists.  They become highly proficient at building software but lack the business or mission insight necessary to better align solutions with business or mission needs.

Proposed Solutions

Development teams do not need to choose among better collaboration with stakeholders, maintaining technical excellence, and delivering value cost effectively and in time to be valuable.  To achieve that balance, we recommend the following actions.

Promote Strong Product Ownership

While not all Agile teams are Scrum teams, Scrum’s concept of Product Ownership is useful for managing Stakeholder Communities and can be tailored to work with non-Scrum Agile teams.  In Scrum, the “product” is synonymous with whatever technical capability a Scrum Team develops, be it a system, solution, application, etc.

A Scrum Product Owner (PO) is responsible for fusing the various needs, wants, and perspectives of product and project stakeholders into one complete, coherent, and cohesive vision. The Scrum Development Team looks to the PO as the primary (but not the only) source of business or mission knowledge and understanding.  The PO enlists the help of the development team and the Stakeholder Community in defining the product/solution but is primarily responsible for outcomes.

An empowered PO is able to do most of the heavy lifting associated with managing a solution’s Stakeholder Community.  While software developers are free to work individually with any stakeholder, the PO ultimately decides what features make it into the product and the nature of those features.  This arrangement provides developers a dedicated Scrum Team liaison to the Stakeholder Community who is well-informed and respected by the community.

Mentor Developers in Customer Engagement Skills

Customer engagement and requirements elicitation are learned skills.  While some people have more of a knack for them, everyone can benefit from training and mentoring in those skills.  Such training would include topics such as:

• Organizing and Leading Meetings
• Presentation Skills
• Active Listening
• Holding User Experience (UX) Workshops

Investment in these “soft skills” pays off in better communications between development teams and stakeholders, better requirements definition, less rework, and greater customer and user acceptance of delivered solutions.

Align Work to Team Capacity

Development teams have more time to interact with stakeholders if the amount of work they commit to is in line with their capacity to complete it.  As explained in the first article of this series, software development teams that do not have control over the amount of work they commit to are not Agile teams. 

Invest in Technical Training

Another way to open up time for developers to collaborate with stakeholders is by providing access to technical training and setting aside time to take advantage of it “on the clock”.  Done well, this investment can bring about better prepared and more knowledgeable technical contributors, better solution implementations, cost savings due to decreased rework, and a boost in employee morale and goodwill towards employers.

Pass Along Knowledge through Technical Consultants

Often, development teams do not possess specific hard-to-find skillsets or may not have the bandwidth to learn them.  One way to meet short-term development needs while passing along knowledge is by partnering developers with technical consultants.  This learning by doing model accelerates learning, thus providing development teams more time to interact with stakeholders.

Conclusion

Developers and stakeholders benefit greatly from closer collaboration in defining solutions.  The keys to improving that collaboration are:

• Developing well-managed Stakeholder Communities through a Product Ownership or Management model
• Aligning the amount of work done by development teams to their capacity
• Leveraging training and mentorship to open up more time for collaboration with stakeholders

This series covered a lot of ground concerning the frustrations with Agile software development shared by many developers.  I too have participated in “Agile” implementations that failed to be Agile.  What those failed implementations had in common was an inability or unwillingness to let go of traditional project management biases rooted in Taylorism.  The challenge is not in training people on the mechanics of individual Agile approaches.  It is in chipping away the Industrial Age organizational mentality that stifles progress in today’s cyber-driven world. 

The Agile Manifesto is a clarion call to improve how we work by acknowledging the skills, knowledge, talents, and professionalism of today’s knowledge workers.  Agile is an ever-evolving domain filled with practitioners dedicated to improving it.  It is that ethos that keeps me optimistic about leveraging Agile to improve not just software development, but world of work in general.

Last Updated on February 2, 2022