It’s 1989 in San Dimas, California, and strange things are afoot at the Circle K. Bill and Ted have been spending all their time trying to create a metal band - “Wyld Stallyns” - all at the expense of their education.
Somewhere in the future the year is 2688 A.D., and the world exists in an utopian society due to the inspirational “Wyld Stallyns”.
Little did Bill and Ted know the consequences of failing their final year at high school. A bogus outcome could have a devastating impact not just on their future, but also the whole of humanity. Ted’s dad would send him to military school if he failed his final history oral report, ending the chance of “Wyld Stallyns” being successful.
Rufus, a traveller from the future, time travels back from the year 2688 A.D. to the present (well, 1989) year to help Bill and Ted fix all their problems and pass their oral history exam.
The Bill and Ted story goes on into a mind-mash of time travel, to sort out their oral history report.
You may wonder ‘what on earth is this guy wittering on about?’. Well, it is a vague summary of the 1980’s movie “Bill and Ted’s Excellent Adventure”, starring Keanu Reeves and Alex Winter in the lead roles.
Let's go back in time a little ourselves.
The Agile Manifesto, which was created some 15 years ago, says that “Continuous attention to technical excellence and good design enhances agility”. And for some strange reason, in my head, instead of “technical excellence”, I hear Bill and Ted saying “totally excellent dudes”.
Why are technical excellence and good design so important?
The way I have experienced this is, if you allow your teams to produce a poorly designed or low quality solution, it becomes increasingly difficult and time-consuming to add more and more features. Unlike Bill and Ted, we do not have a friend from the future to come back in time and help us out. The only option we would have will be a major redesign or refactoring phase - and this would be bogus.
So how do you make sure your teams are being technically excellent?
1. Ensure your team has all the skills they need.
The utopian place to be is for everyone in the team to have all the skills necessary for the delivery of your product, making everyone a generalised specialist. In the real world, there are often a lot of skills necessary to deliver a product and it is not practical for everyone to know them all. It is however still important to ensure that the team has a good healthy balance of the skills necessary to develop your product. Try not to have single points of failure with one person being an expert in one skill, and make use of paired working to spread knowledge throughout the team.
2. Let the team make design decisions.
The best people to make design decisions are those on the team who work with the product on a day-to-day basis. Try not to have design authorities in ivory towers, mandating designs that a team must follow. The team is composed of the people who are at the coal face, working on the product on a day-to-day basis, and are therefore best placed to know how best to design the product.
3. Make refactoring part of the process.
As we add more and more functionality to our products, it is possible that the design of the product could start to evolve into something which is not the best possible design. Obviously, this is not technically excellent, so is not something we want - you might say it is bogus. Hence, it is important to allow teams to have time to refactor their product. Refactoring is simply changing the solution/design to be better, without changing the functionality.
You can see why we must allow our teams to have enough time to refactor. This can be a difficult balance between adding new features and refactoring code.
4. Ensure quality is always being met.
In Agile teams, we make sure we are always delivering a product of high technical quality from the outset of product delivery, whereas the Waterfall approach leaves test quality until the last phase. However, in Agile teams there can often be pressure put on the team to deliver something without meeting the agreed level of quality. This must be avoided at all costs, since it only leads to more refactoring later on, and, worse, the team will be known to be constantly delivering a poor product which needs more and more refactoring. One simple approach we could use here is to implement a strong Definition of Done (DoD). A DoD is a list of agreed quality criteria that the team will always plan for and comply with.
5. Promote increasing technical excellence.
It is important that we promote continued investment in technical excellence in the team and individuals. We need to make sure the team is kept updated with latest advances in technology, and individuals are having the opportunity to satisfy their desire to master new skills.
Unlike Bill and Ted, we do not have a Rufus to help us, even the world's best ScrumMaster cannot time-travel to go back and fix problems made by past decisions. So it is really important that we continue to pay attention to making sure our teams are promoting technical excellence and good design, and constantly striving to improve their process, product, and people.
To help you out in promoting technical excellence in your teams, Radtac offers a new set of technical courses.