“A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology may help or hinder them along the way).” – Alistair Cockburn
This quote by Cockburn formulates the truth in the software engineering nowadays. If you have a clear set of business goals, the technology decisions are straightforward , trustworthy and you’ve got a team of adequate and responsible people then it’s highly unlikely that you will be spending day and night thinking how to optimize your development team to produce more value.
There are even more factors;
- Can the explicit work be divided into separate modules to be developed concurrently?
- Is the business ready to wait the entire wait until the closing stages of the project to have a look at what they are going to get?
- and so on
Most businesses now, unless they have high security requirements or develop life-critical applications do require quick time to market, ability to change the requirements quickly and on top of that maintain the quality on an acceptable level at least.
In order for businesses to tackle the issues they need to uncover the issues first. Too many times the information dissolves and no-one takes a certain action. It is essential to create a transparent environment and that’s become a painful point of many businesses. The requirements are usually passed to the software development teams and until the day of the delivery nothing is visible; no feedback during the iterations and no visibility. How many times have you experienced the disappointment of learning a user story, a requirement is not going to make it only in the closing stages of iteration? Have you been told in the end of the iteration / sprint that there are a certain numbers of bugs that are showstoppers for the release? Yeah, it is painful.
“If you can’t see it, you can’t improve it” – Alan Shalloway
Everything comes to information radiators.
“Information radiator displays information in a place where passersby can see it. With information radiators, the passersby don’t need to ask questions, the information simply hits them as they pass.” (Cockburn 2001)
Businesses need transparency. The Product planning departments need visibility into the day to day activities of the software engineering department. In the cases when the software development is carried out by an outsourced partner the stakes are even higher, costs can be higher and consequences more painful.
Allan Shalloway comes up with a list of common information radiators used in Scrum environments
- The product vision
- The product backlog / release plan
- The iteration backlog
- Burn-down and burn-up charts
- The impediment list
- You may say that you receive this information in any case into your mailbox, but it is definitely different, “passing by” the information on the big screen hanging in the corridor has more effect than the information in your mailbox.
The release dates, backlog items scheduled to be released and so on are great candidates to be visualised to make all the departments aware what’s coming up.
A Second level of visualisation is even more important and requires more dedication and commitment from the development team, is trying to estimate hours spent on each task and make the capacity of the team visible. It is essential for the product managers to understand whether it is the pure effort, complexity or uncertainty that drives the User Story estimates high, and important to see how many hours of work it is translated to in the end, in order to be able to adjust their plans accordingly.
“If anything is certain, it is that change is certain. The world we are planning for today will not exist in this form tomorrow”. – Philip Crosby
Business needs change, and plans, release plans need to be constantly adjusted to reflect fresh information to marketing and other departments to sell the product / make deals for traffic and so on. Think about transparency, think of boosting your business.