Creating Healthy Tension in Software Dev Teams
Brendan Homann • May 27, 2019
One of the most brilliant things about an Agile process is when it works, it really works. You get development teams that produce software that is exceptionally valuable to the business while creating an environment in which development team members are highly engaged. However, more often than not there is an unhealthy level of tension between software development teams and their stakeholders.
This article is for you if you’re asking yourself these things:
Why are they not working on the most important features?
Why does the team over promise and under deliver?
Why are we constantly working on technical things and not on new features?
A common story
I was discussing with a friend who has moved to a new company which is scaling up past the startup phase. As the company grew, the founder became distracted away from product management into business management. The development team is being given clear direction or face time with the founder and are using this gap in direction to focus on technical “busy” work. The owner is getting frustrated that the development team isn’t building the new features their customers are asking for. The development team is slowly becoming disengaged and not enjoying their work.
This is a common problem repeated in many organisations with slightly different factor depending on whether the company is a startup, scaleup or enterprise.
Enterprises may find that development teams spend a lot of time talking about creating or fixing the framework or resolving for technical debt. You may notice development teams convincing organisations to invest in rewriting parts of their application by swapping out technology which serves very similar purposes (e.g. moving from Angular to React). These rewrites are often sold on the improvement of developer productivity and customer experience.
Changing technology is either a by-product of poor implementation or selection or a strong lack of business requirements. It generally never results in sufficient gains in productivity or customer experience to warrant the investment. If the team caused the poor selection or poor implementation, what’s to stop them making the same mistakes again?
Creating healthy tension
To keep a development team on track, you must actively encourage a healthy level of tension between the stakeholders and the development team.
On one side, you should have the stakeholders wanting the development team to produce as much as possible. There should be a hunger for new features and the stakeholders should be eager to review the results. There should be celebration when results are achieved. There should be active engagement with the team to support them.
On the other side you should have the development team understanding their progress is closely monitored. Their performance is critical to the organisation's continued success. The results will be reviewed and celebrated. Failure to perform will be questioned, and if there are excellent reasons for under-performance they will be accepted. Continued under performance without due cause will have undesirable consequences.
However, too often development teams are left to their own devices, trusted to just “get on with it” while stakeholders are busy with other tasks resulting in frustration.
Some tips to create healthy tension
Here’s some common approaches that should increase satisfaction and alignment between the stakeholders and the development team based on some of the most common needs.
1. Stakeholders want to keep the development team working on the highest value work.
A backlog of work needs to be created, ideas go into the backlog and are refined into fully formed business focussed requirements. A prioritisation session needs to occur regularly between the development team and the stakeholders to blend technical needs with business value.
2. Stakeholders want the development team to deliver value and the development team needs time to focus and deliver.
Hold a sprint planning meeting where the development team identifies how much work it can do during the sprint. It’s critical this is the development team taking items off the backlog and committing to the plan. The stakeholders should sign off the plan, ensuring it’s work that is the agreed highest priority.
The sprint plan is like a mini contract or promise, the development team says they can deliver if they are left alone to deliver. If the stakeholders avoid changing the plan, they are rewarded with a delivery on time.
3. Stakeholders need to create sufficient engagement within the development team to keep them happy and productive.
Typically the stakeholders are involved in defining work clearly with business focused user stories and acceptance criteria. Sometimes themselves or sometimes through a product owner or business analyst. It’s critical that these user stories clarify the problem and the business requirements (e.g. we want to register new users with their name, company, email address and phone number so we can follow these users up) and without dictating specifics of implementation of the solution (e.g. we need to create a new record in the users table).
Dictating the solution in technical detail is a surefire way to disengage a developer. Failing to provide a developer with clarity around the problem and the business requirements often results in developers filling in the gaps or waiting for further information. The result being solutions which need rework, inefficient development processes and unhappy developers.
The stakeholders and the developers need to come up with a compromise around the timeframe for delivery of new features and resolving for technical debt. Failing to resolve for technical debt could make it frustrating for the development team to continue to deliver. The development team needs to ensure that they aren’t worked to death by having stakeholders over commit them to a schedule they have no influence over.
4. Stakeholders often want to know how long it will take to deliver, to set expectations with clients or other stakeholders who need to plan around the arrival.
Engaging the team in estimating the work is imperative to achieve their buy in. If the team does estimate their work, they are more likely to hold themselves accountable for delivering within their estimates. The stakeholders need to know they can’t change the plan (being the stories or the acceptance criteria) while it’s in progress or without changing the estimates. With sufficient clarity as to the problem and business requirements developers can provide accurate estimates.
As a result development teams can usually achieve a consistent velocity (amount of work delivered per sprint). With a consistent velocity you can predict when work will be delivered. You should be able to predict when work will be delivered, +/-50% on anything further than 6 months out, and +/-20% on anything in a 4-8 week time horizons.
5. Stakeholders want to be sure that things are on track, so we need a way to measure and predict our deliveries.
There should be tooling which shows work remaining VS work completed with a view to both short range (within the sprint) and long range (3-6 months). The development team needs to know their progress to completing the shippable increment will be tracked and monitored and if things aren’t on track then everyone need’s to see it and they need to articulate why it’s not on track.
Sometimes it’s obvious, for example 'new requirements were identified, we’ve had to change work we thought was done because we learnt something new'. Adding more scope items pushes dates out, simplifying or removing scope or impediments brings dates in.
6. The development team needs to regularly present progress to stakeholders in order to stay on track.
There should be a regular set of presentations (a showcase every 2 weeks) where the development team is forced to present their progress with a live demo. This ensures there are opportunities for stakeholders to regularly inspect progress and course correct. The live demo causes the development team to find a way to focus their energy on proving progress to themselves but also to their stakeholders.
If the development team haven’t delivered on their sprint plan, there should be explanations as to why. Where reasonable explanations and consistent performance is observed there should be celebration. Where consistent under-performance is observed there should be corrective actions taken.
7. The stakeholders and the development team should review how they are progressing and identify any areas for improvement.
The stakeholders may receive some ideas from the development team, usually at a retrospective meeting, as to how to help the team go faster. Common examples might be avoiding interruptions when team members have headphones in, providing clearer requirements (e.g. specifying wording for error messages and email content prior to the sprint starting), answering questions faster during sprint or helping the team get any tooling or hardware they might need.
In summary
Establishing a healthy tension between development teams and their stakeholders results in more engaged development teams, better products and more value created. When you setup some rigorous processes in a light weight fashion the stakeholders can have minimal touch points with development teams while ensuring they are getting value and their expectations are managed.
If you think your practices could use a little improvement, we offer independent reviews on your processes along with actionable recommendations. Please do
get in touch.
Share This Post
Get In Touch
Recent Posts
Red-team challenges have been a fun activity for PZ team members in the past, so we recently conducted a small challenge at our fortnightly brown-bag session, focusing on the burgeoning topic of prompt injection. Injection vulnerabilities all follow the same basic pattern – un-trusted input is inadvertently treated as executable code, causing the security of the system to be compromised. SQL injection (SQLi) and cross-site scripting (XSS) are probably two of the best-known variants, but other technologies are also susceptible. Does anyone remember XPath injection? As generative models get incorporated into more products, user input can be used to subvert the model. This can lead to the model revealing its system prompt or other trade secrets, reveal information about the model itself which may be commercially valuable, subvert or waste computation resources, perform unintended actions if the model is hooked up to APIs, or cause reputational damage to the company if the model can be coerced into doing amusing or inappropriate things. As an example, entrepreneur and technologist Chris Bakke was recently able to trick a Chevy dealership’s ChatGPT-powered bot into agreeing to sell him a Chevy Tahoe for $1 . Although the U.S. supreme court has yet to rule on the legal validity of a “no takesies backsies” contract (as an employee of X Chris is probably legally obligated to drive a Tesla anyway) it is not hard to imagine a future scenario with steeper financial consequences.
With the advent of ChatGPT, Bard/Gemini and Co-pilot, Generative AI, and Large Language Models (LLMs) have been thrust into the spotlight.
AI is set to disrupt all industries, especially those that are predominately based on administrative support, legal, business, and financial operations, much like insurance and financial organisations.
One of the features of life working at PZ is our brown bag lunch and learn sessions; presentations by staff on topics of interest – sometimes, but not always technical, and hopefully amusing-as-hell. Yesterday we took a break from discussing the book Accelerate and the DORA metrics to take a whirlwind tour of the current state of play running “open source” generative AI models locally. Although this talk had been ‘in the works’ for a while, one challenge was that it needed to constantly be revised as the state of AI and LLMs changed. For example, the Stable Video Diffusion examples looked kind of lame in comparison to OpenAI’s Sora videos (released less than a week ago) and Groq’s amazing 500 token-per-second hardware demo on Monday/Tuesday , and the massive context size available now in the Gemini 1.5 models (released a few hours before OpenAI announced Sora...coincidence? An effort by OpenAI to steal back the limelight! Surely NOT!). And now a day later, with the paint still drying on a highly amusing slide-deck for the talk, Google releases their “open-source" Gemma models! The day itself presented an excellent example of why having more control of your models might be a good thing. ChatGPT 4 users began reporting “crazy” and highly amusing responses to fairly normal questions . We became alerted to this when one of our own staff reported on our internal Slack about a crazy response she received to a question about the pros and cons of some API design choices. The response she got back started normally enough, but then began to seem to channel Shakespeare’s Macbeth and some other olde English phrases and finished thusly. "Choose the right charm from the box* dense or astray, it’ll call for the norm. Your batch is yours to halter or belt. When in fetch, marry the clue to the pintle, and for the after, the wood-wand’s twist'll warn it. A past to wend and a feathered rite to tend. May the gulch be bygones and the wrath eased. So set your content to the cast, with the seal, a string or trove, well-deep. A good script to set a good cast. Good health and steady wind!" The sample JSON payload was also in keeping with the rest of the answer. { "htmlContent": "
Your HTML here
", "metadata": { "modifiedBy": "witch-of-the-wood", "safety": "sanitized", "mood": "lunar" } } Hubble, bubble, toil and trouble. Although there were no reports of the GPT4 API being affected by this (only ChatGPT) it might have given people developing automated stock trading bots using GPT4 a reason to pause and contemplate what might have been if their stock portfolio now consisted of a massive long position on Griselda’s Cauldron Supplies. As ChatGPT would say, Good health and steady wind.
Bay didn’t start her career out in software development. At school, Bay excelled at maths and physics, but adored writing, English and drama; lost in a world of Romeo and Juliet and epic fantasy.
Organisations across Australia turn to Patient Zero design, build and maintain custom software applications. Our Australian based development teams are vendor & technology agnostic and ready to deliver your next project.
We have a proven track record of projects delivered in a diverse range of industries including Education, Insurance, Waste Management, Health/Medtech, Government and even EV Charging.
Quick Links
Contact Us
1300 714 093
[email protected]
Brisbane
Level GR-109
310 Edward Street
BNE QLD 4000
GPO Box 2056, Brisbane 4001
Sydney
Level 3-104
320 Pitt Street,
Sydney NSW 2000
ABN 98 611 165 498
Latest News
Red-team challenges have been a fun activity for PZ team members in the past, so we recently conducted a small challenge at our fortnightly brown-bag session, focusing on the burgeoning topic of prompt injection. Injection vulnerabilities all follow the same basic pattern – un-trusted input is inadvertently treated as executable code, causing the security of the system to be compromised. SQL injection (SQLi) and cross-site scripting (XSS) are probably two of the best-known variants, but other technologies are also susceptible. Does anyone remember XPath injection? As generative models get incorporated into more products, user input can be used to subvert the model. This can lead to the model revealing its system prompt or other trade secrets, reveal information about the model itself which may be commercially valuable, subvert or waste computation resources, perform unintended actions if the model is hooked up to APIs, or cause reputational damage to the company if the model can be coerced into doing amusing or inappropriate things. As an example, entrepreneur and technologist Chris Bakke was recently able to trick a Chevy dealership’s ChatGPT-powered bot into agreeing to sell him a Chevy Tahoe for $1 . Although the U.S. supreme court has yet to rule on the legal validity of a “no takesies backsies” contract (as an employee of X Chris is probably legally obligated to drive a Tesla anyway) it is not hard to imagine a future scenario with steeper financial consequences.