Working software is the primary measure of progress.
There’s often a huge difference between working software and complete software. In agile, nothing is ever really complete, and working software doesn’t have to be fully finished to bring value to the end user.
A lot of time in agile, you’re not going to complete a whole piece of functionality within a sprint. By incrementally delivering working software, end users have the ability to provide more regular feedback, which will allow the development team to make necessary changes without building unnecessary features and functionality.
So what is working software? In most cases, working software provides value to the end user, has limited bugs, and is high performance. If we can provide additional value to the end user after each sprint, then we’re showing strong signs of progress.
In order to know what value the software is meant to bring the end user, it’s important that the development team and customer agree on requirements and acceptance criteria. What is delivered should work well and should be tested by the end user. Once the customer has tested and approved your working software, then you can move onto the next sprint.
If the customer and the entire agile development team have a common understanding of the definition of done and of what working software is, then everyone can start working towards meeting requirements.
However, end users and development teams aren’t always on the same page. Sometimes the end user doesn’t want to participate in requirements planning or accepting the working software. If end users aren’t participating, there’s no way to really know teams are developing what they want.
Other times a client won’t really pay attention to what’s actually being delivered, but instead they’ll pay attention to the velocity they’ve set. This is problematic, because each development team will determine velocity differently, and velocity is not a measure of working software.
For example, a client might set expectations that each member of the development team needs to deliver two points each day so that a team will deliver a certain number of points by the end of the sprint. If that amount of points isn’t delivered, the client won’t accept the sprint. In this scenario, the client doesn’t care about receiving working software; they just care about collecting story points. This kind of mentality can lead to inflation of points and have negative impacts on delivering value to the end user.
When being agile, it’s important that everyone from development to testing to security to ops to the business is on the same page in terms of what requirements are and how you plan to deliver working software incrementally. Facilitating that transparency, however, is easier said than done.
One way to start being more transparent is by encouraging your client to play a more active role in planning requirements, testing and acceptance, and providing feedback to the team. At the end of the day, development teams and the customers should have one common goal: deliver working software to the end user.
I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.
