In the last years we had some quite big research and development investments running in our company. The goal was to design and develop a product for the military market. Trade shows should be the platforms for demonstration and discussions. In parallel to the normal product improvement we implemented a lot of special functionality (for the trade shows) and always had to fight some heavy integration issues (lots of new interfaces and modules on a demo system).
We solved some of these issues with SCRUM that helped us to provide a short reaction time and usually running software. But as the project got bigger we saw that
- the ecosystem surrounding the SCRUM team is very essential for success
- SCRUM has some points to take care of
SCRUM tends to distract from traditional best practice:
SCRUM distracts from traditional software development because it is feature driven. Each SCRUM role is designed to implement functionality. The product owner wants a feature rich product so he creates backlog entries that are a huge set of product features. He is not very interested in product internal developments, tweaking architectural stuff or package refactoring, which he cannot see as a button or text field on his HMI. The development team wants to have progress and wants so show progress to the product owner. All these are good things because they allow agile changes to the development process with respect to functionality. But this does not mean that we have to throw away traditional software engineering phases that have to run in advance.
It is still very important
- to define an architecture blue print at the beginning of an project
- to define some valuable metrics
- to architectural reviews
- to point out someone who cares about software quality
- to do some traditional requirement engineering
A feature driven development vs. in-depth development has to be seriously balanced.
Documentation is important:
The agile paradigm says that running software is more important than a word document. This does not mean to do no documentation. Software development lives in a certain environment that requires transport of information in a written way. This is not a easy task to do because this is not only a developer to developer issue. The team has to provide suitable information to different stakeholders with their specific information requirements as well.
SCRUM team:
SCRUM works best in homogeneous teams and homogeneous technologies. But this is not always the case. Systems can get too complex for a everyone-knows-all-team. This is the more important the more different system components a product has or technologies it is using. A recent project had web applications based on JSF, FAT client stuff based on SWING, a really complex persistence and web-services based on REST or SOAP. The amount of knowledge you need for doing JSF/SWING is sufficient to preoccupy one developer, designing a good and fast persistence (incl. tweaking Oracle) requires really comprehensive knowledge, REST and SOAP web-services are an own world too. In general developers (which are at least human beings) do not scale with the complexity of their software systems. And – this is OK; you will not be able to change this. One indication is a wide difference of estimated story points during planning poker or if someone does not have an idea of the functionality. Important as well: Each developer in a team has some specific skills and interests, is a good idea to make use of them. So – don’t stick on dogmatism.
Backlog
The product owner will prioritize the backlog items from a feature point of view. But prioritization of backlog depends on development steps that make sense. This has to be a team decision and the PO has to be aware of that.
POs with frequently adjusted features and responsibilities tend to lose track of a vision how the product has to look like, if the money is spent (this is usually the point where the project is finished). E.g. a good thing is to classify backlog entries regarding (Kano Analysis)
- Exciters
(I saw it, now I want to have it) - linear
(The more of it, the better) - mandatory entries
(Must be present for PO satisfaction)
This helps to keep the essence of the product.
Company culture
If your company
- thinks that responsibilities are hierarchies
- thinks that it is better to point out single responsibilities rather than using team spirit
- thinks that self organized teams are chaos
- thinks that a project leader has to lead the team rather than supporting its work
than SCRUM will not help.
Additional roles
This article should point out that SCRUM is only one part. As usual, the different roles can be combined in one or more persons depending on the project size or for other reasons.
Later, I will prepare a detailed description about the different roles shown in the figure.