Breaking Agile Rules at Payara

03 Jun 2019

I'm a Project Manager at Payara and I love Agile.

 

There is a rule within the Scrum Agile framework that dictates that there are to be absolutely no breaks between sprints. The team is required to flow smoothly out of one development iteration and directly into the next with clockwork-like regularity in an unabated quest to deliver value. Pausing between sprints, the rule says, would significantly compromise the team's ability to learn and adapt, rendering them less agile.

Except I believe that (in this instance) Agile has got it wrong, and at Payara, this is a rule we have recently decided to break. Here's why...

 

Inside the Sausage Factory

There is a perception, predominantly by those who have never worked in the software industry, that a Developer's typical day involves arriving to work around 10:00 to spend most of the day browsing Stack Overflow and/or Reddit, sending each other memes over IM, or discussing the latest Avengers movie, in dispersed with sporadic bouts of actual code writing. The reality, however, is that making software is complicated and being a Software Developer is tough.

 

Just like Thor's magical glass of beer at the end of Dr. Strange, Developers have a never-ending inbox of, typically very complex solutions to design, develop, test, and document. This is their sprint backlog. The moment they empty this backlog, someone, usually someone like me, comes along and fills it back up. When they are not creating complex solutions, Developers are rounded up and directed to inspect how they go about creating complex problems. This often results in yet more things to go into the magical, never-ending inbox of work for the team to do.

 

Having all of this happen sprint to sprint without pause, is, in my opinion, a sure-fire way of making Developers thoroughly miserable, at best, and at worst - running them into the ground and causing them to burn out completely. In all cases, this mentality turns the development process into a terrible unending production line that is not so much Agile as it is self-destructive.

 

Instead, as a development sprint is closed, the Engineering Team at Payara step away from their IDE's, close the sausage factory for a day, and take a well-deserved breath before getting stuck into the next iteration.

 

Stop, Collaborate, and Listen

At this point, I imagine those that are utterly devout to the Church of Agile are sucking their teeth in disdain at the mere concept of momentarily stopping the constant heartbeat of the Agile process between sprints. Put away your manifestos and settle down, we are still bringing value!

 

When the Engineering Team have finished merging their PRs, the sprint is closed, and the next version of the Payara Platform is ready to release. Planning and prioritisation has happened, and the next sprint's backlog has been filled ready to start again. What are we doing that is bringing more value than getting the next cycle of development underway?

 

I gently remind the Development team here at Payara almost on a daily basis that there is one value to rule them all in Agile, and it plays a big part of why we have started taking that break between sprints...

Individuals and Interactions Over Process and Tools

...or, as I often simplify and recite back to Devs as...

 

Share the Love

The Payaran Engineering Team are distributed across a wide geographic area and multiple time zones. We have Developers across Europe and into South Asia and even though we leverage all kinds of modern communications tools it is often challenging for them to re-group as an entire team and dedicate any real time outside of their own personal development silo.

 

In response, we dedicate an entire day, free of development environments and repositories, backlogs and sprints, where the entire team surfaces for air and comes together as one. To give this regrouping focus we do two things, normally performed in much smaller time boxes within the actual sprint.

 

Our development cycles are long and the Developers have worked hard throughout to advance the Payara Platform Roadmap and create new functionality and features. To give the Engineering Team an opportunity to celebrate their achievements as a team and show off all of the lovely shiny new things that they have created to each other and the rest of the Payara team, we spend the morning doing a Show & Tell. Every single member of the Engineering Team gets an opportunity to demonstrate and discuss the new technology they have built within the latest version of the Payara Platform. This is not just a review of the product, it's a group activity to recognise how amazing Payara Devs are. In short, we take some time to properly share the love.

 

Inspect and Adapt - Resistance is Futile

I believe that iterative improvement is absolutely fundamental in becoming more Agile. Done right, the ceremony of a Sprint Retrospective Meeting is the best way to get the team engaged with reflecting on what happened during the iteration and identifying actions for improvement going forward. I want the Engineering Team to be more Borg-like in the way they adapt (obviously without the whole assimilation and green lasers for eyes thing).

 

However with long sprints, large backlogs of complex issues, and a fast-moving and diverse Development team, it has been challenging to perform an effective retrospective within the confines of sprint due to limited time and the pressure to complete development work.

 

Having the retrospective on our break day, outside of a sprint timeframe, gives us the luxury of taking the time to ensure that everyone on the team gets to contribute, we have some fun (maybe more on this another time), and come out the other side with things that will make everyone's lives easier. Going forward, the team and the software they are building should be better for it.

 

Don't Do, Be

It's easy to jump on a bandwagon and end up in a ditch, and perhaps the lesson here is to be agile rather than do Agile. This is not to say that the framework that Scrum Agile provides for a team like the Engineers at Payara isn't amazing, because it is!

 

We're just prepared to bend some of the rules if they are impeding the path to awesomeness.

 

    Payara Blog        Subscribe Here   

 

 

Comments

Subscribe