When Agile Meets Reality

Dear Diary,

I had a very interesting conversation with another Scrum Master the other day that really got me thinking. We talked about topics ranging from our struggles overcoming introversion to how to foster a team environment - which is my personal favorite. One topic specifically stuck out to me as a perfect blog topic - how the principles we learn in trainings and textbooks do not always translate to the realities of different teams and companies.?

?

As I pondered this after our chat, I started making a list of some “agile concepts” and tried relating them to the “real world”.

?

My mind first went to the structure and purposes of the Agile ceremonies that we facilitate daily. In theory, these ceremonies are supposed to foster communication and continuous improvement. Yet sometimes, these ceremonies can become rushed and status/metrics based. When there are strict deadlines, retrospectives are often the first to get skipped. In the Agile books, the retrospective is one of the most important ceremonies there is! I have experienced numerous times when a daily standup turns into a status meeting (because that is sometimes what the team needs) rather than a quick sync using the three questions “What did I do yesterday, What did I do today, Are there any Blockers”. Learning the importance behind these meetings is essential but altering them uniquely to your team is where you will reap the most benefit. ?

?

Another concept I looked at was “cross-functional teams”. In theory, a Scrum team is supposed to be self-sufficient, with all of the skills necessary to complete a project. However, in practice, teams often lack certain expertise. For example, there have been situations where we are dependent on someone from UX to deliver a design or a Guidewire specialist to assist on a defect or accessibility issue. The textbook doesn't account for the complexities of organization resource allocation and the need to sometimes share specialists across teams. A lot of times, the best thing to do is learn the most efficient methods of communication with different resources around the company and use the time you have with them wisely!

?

Agile preaches that teams should be empowered to make their own decisions, but this idea of “team autonomy” does not always translate. Depending on corporate structure, sometimes decisions are made at a department level, opposed to a team level. When a team reaches a certain level of maturity, they want to be able to take ownership in the backlog and pull work in when they have capacity. Often times, dependencies and shifting priorities can stifle this autonomy.?

?

Lastly, the concept of a “sprint” and “sprint planning” is not always a perfect science. According to the Scrum Guide, sprint planning should be a smooth process where the team selects items from the backlog and commits to completing them in the allocated time. In reality, sprint planning can be (and usually is) a little chaotic! Priorities can shift overnight due to changing business needs, leading to replanning and re-estimation. High priority defects and environment issues can disrupt an entire iteration, throwing off velocity and causing stress among team members.?

?

There are a million more examples outside of the ones outlined above. While Agile and Scrum provide a great framework, adapting these principles to the unique context of each team and organization is crucial. It's not about following the textbook “to a t” but rather understanding the spirit of Agile and applying it in a way that works for everyone involved!

?

That is all for now… Talk soon!

-Taylor