Communication over Methodologies and Frameworks

Post Image

Have you ever wondered why Scrum is hard to master?

In essence Scrum is a lightweight framework that should enable to deliver products of highest value and where people are more important than the process itself.

The scrum guide even states “Scrum is: Lightweight, Simple to understand, Difficult to master”.

But shouldn’t a lightweight framework be easy to master? Reading through the Scrum guide, you will quickly notice that it is actually simple to understand. All it defines are the roles, the events and the artifacts. The artifacts should help to add transparency into the internal doings, just think of the product and sprint backlog or the sprint burndown. The roles are clearly defined and include the development team, the product owner and the scrum master. The guide also presents a number of clearly defined events or meetings.

First thing that comes to mind is that roles and artifacts are probably easier to master than the aforementioned events.

When you read articles referring to Scrum you will notice a pattern.

The events are where most of the problems come from. Remember the idea is that the artifacts should enable transparency from an external point of view (external meaning here: other departments, management etc.). The defined meetings on the other hand are focused on or mainly revolve around the team. Or to use a software analogy, artifacts are public methods and the events are either protected or private, depending on the type of event.

Why are events hard to master?

Obviously every single meeting in Scrum revolves around the idea of communication. Just think of the defined events. They should ensure communication between every single team member as well as communication between product owner and team and team and user .

The framework defines the events but doesn’t give any clear guidance on the underlying motivation, just a couple of basic definitions, on how to go about implementing them.

For example the Daily Scrum is defined by answering three specific questions within a given time scope. In reality these guidelines should help transform a company or team from an I to a We mentality.

Moving on from only communicating what is needed and passing work from one entity to the next to continuous communication. Opening up old structures and habits by moving from siloed information to a constant and transparent information flow. The Daily Standup should ensure that this takes place on a daily basis, even if only for 15 minutes.The retrospective is about reflecting within a team and the sprint planning (the first part) is all about communication between product owner, team and maybe even users.

Implementing the Interface

Ok, so obviously Scrum defines an interface, but the concrete implementation is up to those using the framework (to remain in a software development context).

This is probably where the problems come from. Scrum doesn’t give a clear distinction between the public part, think artifacts, and the protected part, think meetings. This is a trap.

The focus isn’t on really understanding the deeper meaning of Scrum events, rather teams new to Scrum very often put their focus on tasks, estimations and burn down charts. Thinking this is what “doing Scrum” is all about. This is not where the focus should be. It should be on communication.

Communication separates high performing teams from the run of the mill.

Some teams are focused on doing estimations and working on tasks and believing this is what “Scrum” is all about.

Only that these are just byproducts, not what being agile is about. Great teams know how to communicate, they have found an authentic way of communicating. By authentic I mean non forced, rather suiting the culture wherein they operate.

Nothing will appear more forced, than telling people they have to communicate. Telling people they have to communicate will lead to awkward Daily Stand-ups and retrospectives without significant outcome. Now is this a problem that Scrum should solve? Most probably not. But Scrum also doesn’t help either,  by hiding the fact that this is a fundamental part to focus on.

Getting the Priorities right

Maybe Scrum or rather the Scrum consulting world should put more emphasis on highlighting the distinction between the public and protected parts of the framework.

Shifting the teams effort to really focus on introducing constant communication which is exactly what we want to achieve.

Tasks and estimations don’t create great products, communication does. Communication between team members, managers, customers and users. Best case scenario is that this spreads from a software department onto the whole of an organization. Opening up the information flow through out the entire company.

If we recall, Scrum is also focused on achieving transparency. Transparency is achieved by enabling and focusing on communication and team work. This by default gives you transparency.

Think of management making statistics and data available within an organization or publishing upper management meeting notes inside a company Wiki. The most effective communication obviously is face to face — even the agile manifesto explicitly refers to this. But every form of open communication will support the matter.

Understanding the underlying Ideas

Once you understand the underlying ideas and principles behind the framework, you can either implement your own framework or only use the parts that add benefit to the overall product.

This is what experienced engineers do. They understand the limitations and problems that come with a framework and know how to navigate around the limitations to ensure that the framework doesn’t become the bottleneck. If it does, they either choose a different framework or start contributing to the framework to solve pending problems. This is why a lot of teams move on from Scrum.

In case you still believe that the post its and burn down charts are the key to being agile, maybe it’s highly time to focus on the communication part.

Put creating a culture where people can freely communicate over any methodology or framework. Start by analyzing communication inside your team today, you will notice a thing or two.

If you are like to share yours thought please leave your comments

No comments posted
Leave a Comment     

You may use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>