We all want things to be perfect, right? But are we making software delivery much harder for ourselves in the strive for perfection?
But, who is it that defines perfect? Is it the Architect? The Product Owner? Maybe… Who knows! – it seems to differ from one organisation to the next. Whose version of perfection are you trying to meet?
Imagine a scenario where you are unable to release version one of your software because your architect is demanding answers about version 2 and 3 – which you know that you’re never likely to get to anyway. You’d be feeling pretty frustrated. On the flip side, being prompted about the plans for V2 could mean you totally rethink the way you’ve done V1, saving time and effort later.
Then someone says “Make it future proof”.
What does this even mean?
And is that future ever going to come?
In a perfect world, to be able to release perfect software we would need to make small changes regularly rather than large releases. We would also need to have full control over:
- The requirements
- The development and test environments
- The target environment
- The release mechanism
- Probably the users too…!
So rather than perfect, should we be striving for Good Enough? It will depend on the team culture and how risk averse the company are. This can be influenced by how quickly problems can be fixed, the size of the user base and how exposed any issues would be. During Spotify’s video describing their engineering model (here) they talk about one of their motto’s – “Never Wrong Long”. They can release more frequently because wherever possible they deal in small changes rather than large projects. They also have the advantage that their architecture is decoupled enough that any problems would have a smaller area of impact and any problems can be resolved quickly.
So, is perfect software the enemy of rapid delivery? It depends on many factors. It seems to me that the ideal would be to have small, frequent, iterative deliveries that are quick and painless to release – then if it doesn’t meet someone’s idea of perfect, it can be quickly revisited.
This discussion was around the differing perceptions of the specialist roles within a scrum team and how the relationships can be maintained or made better. The main points are listed here, but please feel free to add any more in the comments.
- An observation was made that if a comment or suggestions is made by a tester it isn’t given any consideration, however if the same suggestion is made by a developer then it is immediately accepted and usually acted upon. All opinions are equal and should be treated as such, regardless of the persons job role.
- The ideal make up of a scrum team would be to have multi-talented T-shaped people, which would still value the specialist skills of each discipline but would give more flexibility to complete any task.
- Job descriptions can reinforce the perception that a developers contribution is more valuable by using phrases such as helping the developer rather than concentrating on the testers skills.
- Job titles can also influence this. One example was that everyone within a project should be called an engineer, it was thought this would naturally lead to a more inclusive approach.
- One scenario discussed was the testers being allocated to a project from a central pool of testers, rather than integral members of the scrum team. This led to the test resource being removed or reallocated. In order to counter this, the the testers were involved throughout the life of the PBI from requirement gathering, to pairing with the developer, making it more difficult to remove the test resource from the team. While this works around the problem, it is no substitute for a fully integrated team.
- Automation could be used as a bridge between development and testers, giving each an appreciation of the other’s skills.
- Giving the testers the skills and authority to correct minor bug themselves was also discussed as a way to gain appreciation and respect.
- Some people were discussed as being role models and encouraging the relationship between the two disciplines by getting involved with tasks outside of their traditional role, helping with automation and training their colleagues.
- We also discussed that often any issues within a team come down to personalities rather than any lack of respect for the job role.
When discussing how to run agile projects in a more traditional organisation a lot of the focus was around the tension around “iron triangle” projects where scope, schedule and cost are fixed which is very contrary to agile projects where scope often emerges throughout the course of a project.
One of the key areas discussed to address this was the importance of the role of a product owner in a scrum team as this person is generally the face of the project to the business and is key in earning and maintaining the trust of the stakeholders through transparency and regular updates.
There was mixed experience in the groups with some organisations having full-time product owners (often recruited specifically into the organisation to do that role) but others where the product owner role is assigned to someone who already has a full time day job and may struggle to juggle the commitments of the role.
This often leads to “proxy” product owners, subject matter experts taking on board some of the role, and in some cases panels of product owners for a single product. One thing that was universally agreed was that there must be a single accountable product owner at any one time – a “single wringable neck” who has the final say on scope.
Another area of discussion was that sometimes development teams implement agile practices but other business functions are not so responsive, for example there is often a dependency on teams to produce training or marketing collateral and these teams may be accustomed to lead time and absolute deadlines. With incremental and iterative releases and changing priorities these long lead times obviously cause issues.
Engagement with other teams with a dependency on a regular basis (such as sprint reviews, standups etc) obviously can go some way to keeping the business in the loop and allowing other teams the visibility of changing schedules and progress.
Often within organisations the road to agility is embarked upon by development teams in isolation, but where these teams have worked with other departments to explain and demonstrate the benefits of an agile approach it has been shown that these same practices can be adopted to manage their own workflow and their output can be delivered incrementally and iteratively in step with the output of the development team.
Please feel free to add your comments.
On Tuesday the 5th April 2016, we held our first session of Practical Agile. Agile professionals from prominent North East employers, including hosts NCFE, Sage, HMRC, DWP, Orchid Software and Coatsink Software, met to discuss their experiences and challenges.
The night started with an overview of the aims of the group, which is to create a community to share knowledge and support each other in real-world agile challenges. This was followed by a brief 5 minute run through of NCFE, their current approach to software delivery and the challenges faced.
Following this, we broke into two groups and the conversation began. The first topics up for discussion were decided based on feedback from those who had registered to come along. These centered around the relationships between the multiple specialist disciplines within scrum teams, and getting the balance between agile practices and more traditional project management expectations. You can read more about the key discussion points here and here.
The evening was well received, and we are looking forward to the next session in a months time where another company will share a brief overview of their team and the topics for discussion will be decided by a vote on the day. If you have feedback from the event or suggestions for future topics, we would appreciate it so please add a comment below. We’d love to see you there, if you would like to join us please register here.