The Manifesto for Agile Software Development came out of a discussion among 17 people in the Utah mountains. The story around the start in the Snowbird  ski resort is an interesting read, but fundamentally it is about looking for a better way of doing software development, and by extension, almost any other delivery activity.

Agile is a simple idea at its heart, though an entire industry has sprung up around the idea and approach, in many cases, making it anything but agile!

The Manifesto for Agile Software Development is as follows

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

As we have been taking our organization through an Agile Transformation as a part of an overall Digital Transformation, we have been leading extensive training across our business lines and technology teams. One of the most common questions as we discuss Scrum, is around job titles and role. In scrum, there are only a few key roles, and job titles do not apply! There is a good article on the Atlassian site, linked here, that I encourage you to read through. Ihit the highlights here, but they offer a deeper read.

“the essence of Scrum is empiricism, self-organization, and continuous improvement, the three roles give a minimum definition of responsibilities and accountability to allow teams to effectively deliver work.”

The idea of scrum is to keep things simple, contained to a self organized team, and optimized for continuous delivery. To accomplish this, there are 3 defined roles and it is from the intersection of these roles and classic titles or thinking that I see many questions.

Development team

The development team does not have to consist of software developers. According to the Scrum Guide, the development team can be comprised of all kinds of people including designers, writers, programmers, etc.  Titles here have been a source of confusion as involved leaders ask why a business analyst or business user is called a developer – I hear arguments that “I’m not an IT person” or “I don’t write code, why am I a developer?”. The key point for the developers role is that the person is a team member, focused on delivery of value in one or more capacities.

Ideally in a long running scrum team, the members will cross train sufficiently to blur the lines in roles, even in the development team! Unfortunately, in my industry and area, most teams come together for a project, and then disband leading to a higher than ideal rate of churn on this topic.

CSM / Scrum Master:

The scrum master is the “glue of the team” and the challenges in role vs title I see most often are those that come from the traditional PM thinking. I get the question – so who is the PM on this agile project? Or I get the CSM trying to hand out tasks against a project schedule instead of the collaborative scrum approach. This curve is an interesting one to watch, especially in the long time PMI / PMP trained professionals!

Product Owner

“The product owner should not only understand the customer, but also have a vision for the value the scrum team is delivering to the customer. The product owner also balances the needs of other stakeholders in the organization.”

I see business owners who initially struggle with the idea of the product owner role. They are used to the paradigm of meeting with a business analyst, providing requirements and waiting for something do be delivered that they then need to spend more money on since it does not match what was in their head or did not keep pace with the changing business needs.

The product owner role is a far more hands on role, and has expanded responsibility. The key step to success in communication and managing this role is establishing real clarity on the value of the high engagement. The regular feedback cycles, direct ownership and participation in sprint reviews means change is always an option, and surprises are minimal. This means less re-work but to get there, a product owner must understand that they are not the “hands off sponsor” or business lead that gets a “white glove” engagement. The product owner role is a bit of a dirty, hands on, learning in role to get the most value. This is a real paradigm shift for many, but pays off in amazing ways.