Representative Inclusiveness in conjunction with Scrum Product Development

Recently when I was learning one of the fundamental topics of leadership or a modern leadership which is "Representative Inclusiveness", the first thought came into my mind or probably my immediate instinct was naturally trying to relate this topic with the Agile/Scrum product development.

As an agile practitioner or a coach always thriving to build a best scrum team which in turn produces the best product, I felt scrum provides or enforces the Software Development Managers and Scrum Masters to have a culture where inclusiveness is a natural element in the team and no one feels left out.

In this post I want to emphasize the benefits of inclusiveness which is a natural aspect in Agile or Scrum product development. Before that, I would like to explain two points,

1. How inclusiveness is natural in Scrum?
2. Why it was missing in other SDLC models like waterfall?

How inclusiveness is so natural in Scrum?

We have various scrum ceremonies during the iterative product development and one of the key element is "progressive elaboration". Progressive elaboration is achieved by doing continuous refinement meetings. What is so significant about continuous refinement in the context of inclusiveness? If you look at one of the rules for continuous refinement is that you should have all the members of the scrum team as part of this meeting.

Why it was missing in other SDLC models like waterfall?

In the age of waterfall we all know, "how the project or product development is carried out". There will be a requirement specification from customer, a functional specification will be written by the business analyst, the module lead or a technical lead who is known to be an expert or senior will write the technical specification. There will be a project plan also made for 6 months or for an year. When the development phase starts, the lead will distribute the tasks to all the junior staff. Majority of the times according to their competency or sometimes their competency is undermined. This is very much inclined towards the hierarchy where work gets done by command and control. The byproduct of this approach will bring few more unhealthy elements to the team and organization,

• When a new member joins the team he will be fully energized and wanted to do his best and he does this irrespective of every other negative factors affecting him or making him feel left out. However over the time he loose motivation and the sense of belonging or ownership.
• Sometimes an incompetent person sits as a technical lead or team lead. A junior or less experienced try to come up with the better ideas. He will be suppressed as incompetency always carries the fear - "the fear which always keeps them on the edge and making sure that they are not thrown out".
• This will further create groups where gossiping starts. When things reach out to this stage even a good performer will fall into this trap unless he has a good coach or he is conscious enough to sense what’s going around and keep his head straight.

We can list down much more. But that is not the intention of this post...

Now let me explain how this representation and inclusiveness of everyone in the team creating a win-win situation for the team and the organization in the context of scrum product development,

1. When everyone is included in the continuous refinement process the first feeling people in the team get is that they are not left out and there is no need to peep or build a curiosity to know what’s going on.
2. The most beneficial part is that everyone tries to share their ideas on how the product should be built (provided there is an active participation from everyone. It’s the scrum master's responsibility to make sure he gets that).
3. In my experience I have observed, how a one liner requirement in a user story elaborated into multiple paragraphs. This was simply by the questions raised by all the team members about various use cases and based on the input sources like GUI, Interface etc
4. This has really solved the problem of identifying major gaps at the later stage when customers or product owners getting demos and acceptance phase.
5. The inclusiveness doesn't get stopped with the continuous refinement and it gets extended to design meetings where teams come up with their best design by having a good brainstorming sessions and various point of view from the diverse group of people (each one in the team would have come from various backgrounds which brings new ideas and perspectives).
6. At the end both the organization and each team members are in the win-win situation by delivering a best product or feature to customers and feeling the sense of belonging or ownership.

One of the counter arguments which you always hear when you do this is that, the amount of time spent by the team members. When you look at the benefits of building a complete product or feature to a customer this extra time is negligible. When things are not done right and the kind of frictions you face with the customer at the later stage which would add a lot more damage than the time you have invested by having all the team members participated in meetings.

"Build a culture where inclusiveness is heart of your team"