Contentious, I know, but the Scrum framework for agile software development may not be completely perfect yet. That’s fine because because we can improve on it, like science.
A few problems that often come to light are:
- Very few people agree what Agile is. I’m one of them.
- Few people agree exactly what Scrum is (despite it being defined by a very short document, The Scrum Guide.) “Like chess, Scrum is very simple.”
- There is a lot of common agile practice that is used by Scrummers and taught on courses but isn’t part of Scrum.
- Many people think they are ‘doing’ agile and/or Scrum but may not be. Who knows? The rules are: there are no rules.
In my last post I mentioned pragmatic changes to Scrum. Below are some that seem common and I’m not sure are always wrong. I think they come from the fact that Scrum makes assumptions about the mere humans who fill the Scrum roles that are, to be polite, idealistic:
- The use of Business Analysts to supplement the Product Owner’s knowledge and skills and the developers ability to listen and ask the right questions. Developers are not all good at dealing with people or at business analysis. The people who are, are not all good at development. Part-people who add up to a whole role may be the best a team can realistically achieve.
- The use of stakeholders who know areas of business better than the Product Owner (PO.) Product Owners need to be super-human: trusted by whoever is paying, knowledgeable, decisive, able to write good stories and constantly available. The PO is there to make dangerous business decisions, so the Team don’t have to. If they make bad decisions, it isn’t the Team’s fault. They are allowed to have help. By this logic, any BA who helps the BA should be outside the Development Team because business process is not “IT”. I have not yet seen any organisation with a business process department. I think we will soon. Process design is often considered a management responsibility but very few managers have appropriate experience.
- The use of technical/engineering/architecture specialists to supplement the skills of the Development Team. One small team is assumed to consist of generalising specialists with knowledge of everything that will be necessary to complete the project, though you don’t know what that is yet, so ‘be lucky’
- Network communicators/organisational specialists. Scrum assumes autonomous teams but at scale, organisational efficiency considerations start to apply pressure to centralise scarce and expensive skills. Co-ordination of networked teams becomes necessary. Traditionally, managers are likely to have filled similar roles but in future there may be more collaboration than typical managers have experienced while fighting for influence and resources inside a hierarchical organisation.
On The Outside 