Helping Scrum Work for the Developer
I’m a developer, I’m doing Scrum and I’m not sure it’s working for me!
Audience and Aim
This article is for people in a Scrum development team who are feeling any of the below frustrations:
- ‘All of my non-functional requirements are being de-prioritised.’
- ‘I’m being made to code features whose functional design I don’t agree with.’
- ‘My stakeholders are demanding late, unrealistic changes, citing Scrum being an Agile process as validation!’
There are of course other issues you may be facing, but this article focuses on these three specifically, and how you can alleviate them using the Scrum framework.
It assumes a functional understanding of Scrum (i.e. you work on a Scrum team), but not necessarily a theoretical understanding of Scrum (you needn’t have studied the Scrum guide in detail).
Argument
‘All of my non-functional requirements are being de-prioritised’
A release deadline looms and your monitoring framework is not yet in place. As stakeholders mount pressure on the product owner it is easy enough for the product owner to see non-functional requirements as negotiable, de-prioritising them in the product backlog. However, as a developer you should ensure everything pushed to production is up to your development team’s technical standards.
The reason this has occurred is not because of a prioritisation issue, but a problem with your Definition of Done.
The Definition of Done is where the development team has total control in deciding their own technical standards. Your non-functional requirements should sit in the Definition of Done, not as separate items on the backlog. This means a product backlog item should not be considered finished until it meets the definition’s criteria.
These are not separate tickets, these are not things that can be de-prioritised, they are intrinsic parts of every backlog item which cannot be released until they are finished.
Sit down with your development team and revisit your technical standards. Make a clear, transparent list of criteria and discuss them with your product owner and scrum master. Now, when a product backlog item is agreed on, it is also explicitly agreed that the item will meet all of your technical standards before it can be released.
‘I’m being made to code features whose functional design I don’t agree with.’
The requirements are in, but confusion is high. ‘Surely it would be much easier if it worked like…’ is the invasive thought. You have a plethora of criticisms for the new functional design, and don’t feel you can commit to and focus on the project in hand.
It is important you discuss these feelings as part of your Scrum team. A vital component of being a developer is using all of your experience to aid your product owner in order to optimise value for the product.
However, these decisions are not yours to make. Ultimately the product owner decides the product backlog and fundamentally it is they who shoulder the accountability for the product. Support your product owner with your technical expertise and offer opinions where suitable, but remember the direction of the product is their responsibility — much as the Definition of Done is ours.
‘My stakeholders are demanding late, unrealistic changes, citing Scrum being an Agile process as validation!’
As we are all aware, the 11th hour is not always the best time for a drastic change — a fact occasionally ignored by various parties in a product’s development lifecycle.
The Scrum process encourages stakeholder interaction through ceremonies such as the Sprint Review, and as stakeholders gain better visibility of a product they come up with new suggestions for features, enhancements and directions.
Additionally, a Scrum team is expected to exhibit adaptability, and to help all parties make value optimising changes to the product backlog during the Sprint Review. However, it is important to emphasise that adaptability is not the same as being able to make significant alterations without repercussions.
One method of communicating this is through the Agile Development Value Proposition. Visibility means that the stakeholders should have frequent opportunities to make suggestions, and the development team should have equal opportunity to educate stakeholders surrounding the necessary sacrifices. As in the previous point, your role as a development team is to communicate the technical aspect of your project. Properly organised sprints allow for this in a regular and timely manner.
A useful analogy is that building a product is similar to navigating a ship. When sailing, no captain aims roughly at the dock, closes their eyes, then opens them only when they’re nearly aground. One would select their destination and check regularly to make sure the ship is still on track, making minor and systematic adjustments to the rudder to adjust one’s course.
If large changes are being demanded late in the day, it may be that the engagement and communication within your Sprint Review sessions is not sufficient.
Conclusion
Although often abused, and even more frequently misunderstood, Scrum is definitely a developer’s friend.
- A thorough Definition of Done ensures a high quality product.
- An understanding of accountability eases product direction qualms.
- Communication of the Agile Development Value Proposition with all parties (including stakeholders) ensures realistic expectations of the viability of potential product changes.
