Agile is a meta-process. It describes a framework for designing processes having particular qualities. Scrum is, in some senses, an instantiation of an Agile process.
In a sane world, you can't sell a process. Except in the US, where you can actually patent a business process. I won't dwell on the topic of patents, save to observe that the entire world of patents has become a broken mess that exists to feed lawyers.
However, moving on, the point at issue is that most businesses actually need to see product emerge from their processes in order to make money. So it's important to understand what product is, and the nature of the relationship between Agile and product.
The first line of the Agile Manifesto makes it clear what domain Agile principles are intended to apply to :
"Manifesto for Agile Software Development"
Furthermore, we have :
"We have come to value working software above comprehensive documentation"
The point is this. Agile is NOT GENERIC . The empirical observation that gives rise to the principles of Agile was done by software practitioners in software development contexts. There is absolutely no guarantee whatsoever that Agile principles can safely be transferred to different domains. This has not, however, stopped people from doing so. There's a body of literature on the topic, see this study for example. The Scrum Alliance have even tried to use Scrum as a model for teaching in Canadian classrooms ! I won't ask how they got ethical clearance for experimenting on children. Or maybe teachers do exactly that all the time 🙂 .
So perhaps you make home furnishings. Fantastic ! I'm sitting on such a product right now, and it's quite essential to me. The market for home furnishings will last at least until we have anti-gravity. It's entirely conceivable that some business analyst will rock up and tell you that Agile processes will shorten/speed up your product development lifecycle. IMHO you can safely ignore them, unless you are making IoT enabled robotic sofas.
But you may wish to consider reflecting critically on the development of your various products over the years, and asking 'what has actually worked ?'. That much you can take from Agile - improvement starts by being honest about what works and what does not. If you don't have the data to help you make such an assessment, you may want to consider starting to gather it. You may also like to consider investigating Lean Thinking, which emerged from an industry engaged in manufacturing tangible goods for consumers.
None of this is rocket science, but when I point it out to eager Agilistas they can get quite upset. It's not that Agile principles cannot be translated, via suitable semantic gymnastics, to circumstances other than software development - that bit is easy. It's that they cannot be applied with confidence without first verifying their applicability by careful empirical observation. Agile demands no less.
That bit is hard - see my comment here about comparing Agile vs non Agile results. So if you make home furnishings, you can, of course, plan and run your own experiments. Just be careful - significant rigour will be required before you can be confident in the results.
Therefore, just in case it wasn't clear, the only type of product that I'm going to be concerned about here is software.
For everyone involved 🙂. The point being, there can be a large array of different stakeholders in any product development activity, and in a sense you are developing product for all of them. However, they don't all have the same priorities or perspective on exactly what the product is, or how involved they should be in the development process.
The Agile Manifesto stresses the need for communication between stakeholders, particularly between business stakeholders/sponsors and developers, but is light on detail. Scrum attempts to fill in some of this detail, but leaves as much as possible up to the Scrum team.
If, as a developer, I needed to communicate on daily basis with many of the stakeholders, resolve all conflicts of interest, discuss money and budgeting and resource allocation and marketing and product strategy... well, this would ( to say the least ) have a negative impact on my ability to quickly write code to make a working thing.
Scrum has recognised this, and the role of Product Owner is the response. Note carefully that this is a role that exists within the overall development team. The Product Owner does not sit outside the team and deliver requirements from on high. The Product Owner is an integral part of the team. This goes to the observation I have made elsewhere on the nature of the relationship between Scrum and the business.
Also, note very carefully that the Scrum master role is not the role responsible for product definition. The Scrum master can help, in the sense that they can coach both Product Owner and Developers as they work together on product definition tasks, but the Scrum master is a facilitator, and does not have responsibility for the nature of the product itself ( Product Owner ), or the nature of the technical solution(s) employed to create it ( Developers ).
Developers sometimes fall into the trap of believing that they are working for the Product Owner, and that the Product Owner is therefore the only person of any importance when it comes to questions about their work. It is not expected that the developers will speak only to the Product Owner and Scrum master for the entire duration of the Sprint ! Developers are working for the business, and are allowed to communicate with anyone in the organisation who they believe they need to in order to make progress and achieve their Sprint Goal.
Very often the best person to talk to will be the Product Owner, but this is not a given. My advice to developers is to try to avoid passing all communications through the Product Owner by default. The Product Owner has no interest in technical discussions, unless those discussions might have an impact on the team's ability to achieve the Sprint Goal. The Product Owner has no interest in any line management issues team members may have, unless those issues may affect the Sprint Goal.
Equally, Product Owners can fall into the trap of thinking that the developers are their team. This is not the case. There is no ownership relationship between the Product Owner and the Developers. The team is, in fact, a close collaboration between Product Owner and Developers for the benefit of the business.
The Developers will work with the Product Owner very closely, but it's important to appreciate that the Product Owner is not the only stakeholder. Although the Product Owner role makes the Product Owner responsible for some important decisions about the work that is done, the Product Owner can also be seen as representing the interests of a multitude of other stakeholders to the team.
The Product Owner role is a very busy one, largely due to the amount of communication involved with all the various stakeholders, but can also be a very isolated one, despite their close relationship with the team. The Product Owner carries a significant degree of responsibility for the ultimate success of the product.
So it is a key responsibility of the Scrum master to support the Product Owner, and to ensure that the relationship between the Developers and the Product Owner is a positive and productive one.
One particular observation I have made when dealing with Product Owners is that if they come to the role with little experience of Scrum, they are often shocked by how 'little' functionality will be delivered in a two week Sprint. This is largely because the idea of 'Done' includes a lot of work which in other sorts of development environment would not be considered 'development'.
Therefore there is a sense in which every new Product Owner, experienced or otherwise, needs to 'calibrate' their expectations when starting with a team, and this may take several Sprints. During this period, the Developers are also going to be learning how to interpret and work with their new Product Owner.
The Scrum master should be busy ensuring that roles, responsibilities and working practices are mutually understood, that work on the backlog continues smoothly, and that information about the status of the team is being radiated as appropriate.
Much is made in Agile literature of the Tuckman model as applied to Scrum team formation. Well, the Product Owner is a part of the team, and so to an extent a new Product Owner means a new team, and some disturbance in the force must be expected, whether it follows Tuckman or not.
© Mark de Roussier 2021, all rights reserved.