Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Manifesto vs Process: Avoiding the Agile Ritual and Maximizing Customer Return Pt. 2

DZone's Guide to

Manifesto vs Process: Avoiding the Agile Ritual and Maximizing Customer Return Pt. 2

In part two of our look at the Agile Manifesto vs. process series, we'll explore procedural ceremonies that drifted from the original Agile Manifesto goals.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

In this second and final edition of the “Manifesto vs. Process” series, several specific Agile procedural “ceremonies” that have strayed even the truest of evangelist away from the original goals of the Agile manifesto: Satisfy the customer, welcome change and continuously improve processes and product.

Agile was built to accommodate the customer by accommodating change, but how many times has a business asked for a change and developers said it could be delivered with zero resistance or backlash? A few common answers that agile teams give to businesses when requests for “urgent requirements” are made are as follows:

  1. “We’re in middle of a sprint and this will have to wait until the next sprint cycle.”
  2. “This request will require a full deployment, plus testing and it will slow our current sprint. We need to reduce this sprint’s scope to accomplish this new input.”
  3. “If we just create this “quick fix,” it will incur a technical debt and we will have to spend time later on to fix it.

So the question is – can we truly accommodate change?

According to Google, the definition of a ceremony is “the ritual observances and procedures performed at grand and formal occasions,” and is that not exactly what the processes born out of the Agile manifesto has given us? From Sprints, Scrums, Retrospectives, Stand Ups and countless other practices evangelized by those who teach them, Agile has become a near religion full of practices followed ritualistically and without adaptation or change – the exact opposite of the accommodating objective centered in the original manifesto itself.

 Look at each one of these “ceremonies” and step back from what has been burned into us as “what must be done.” As DevOps, Continuous Delivery, TDD and a whole slew of new ways of thinking and delivering software are added onto our Agile Processes, it is time to actually consider how we could be applying them better by using dynamic thinking.

Sprint Planning (example of a two-week sprint cycle, 10 person team)

Duration: 2-4 hours before each sprint.

Collective Team Hours: 10-40+ hours per week

Purpose: Prioritize the features to be built and establish sprint objectives and make a commitment.

Development team and product owners come together to discuss deliverables, scope and other restraints or possibilities for the upcoming sprint.

Problems:

  1. If you have a 10-developer team, you are likely going to spend 20-40 collective hours talking during this planning process.
  2. The sprint planning meeting often takes longer than the allotted four hours. It takes at least a full day with a larger team and at the end you likely would have rushed a few features to finish when you did.
  3. Not all developers are always involved in the discussion - developers in general do not like meetings, so expecting full participation from people who are not enjoying the process is naïve.
  4. Developers put a buffer on their estimates. This happens because developers may underestimate what they can accomplish and give themselves wiggle room, meaning you may be underutilizing your teams.
  5. Too much discussion. With so many minds at work, you are guaranteed to disagree on a lot of things.
  6. Worst of all, planning is often used to tell the business what cannot be accomplished versus what can.

What can you do differently?

Take a deadline-first approach. What does the business need to achieve in set timeframe? Prepare a high-level roadmap of what needs to be done each week, and then do a one-to-three day roadmap of what needs to be achieved in those days. Allocate work to developers and kick off.

The communication can be verbal or written. Help the developers understand what needs to be built and go build it. Update the weekly roadmap every day or two or three days and compare it to the original roadmap.

Daily Standups (example of a two-week sprint cycle, 10 person team)

Duration: 15-20 minutes per person.

Collective Team Time: 1,000 minutes = 16 hours per week

Purpose: Get everyone on the same page, share challenges and potentially solutions

The team and product owners and managers gather, in a standing format, together and give “brief” updates on projects they are currently working on and challenges they may be facing.

Problems:

  1. Standups often run over.
  2. People are not really present and listening.
  3. Developers don’t always properly articulate what they need to say.
  4. Starting developers’ mornings with low energy is not best for productivity.
  5. Water cooler talks after the standups discussion can offline items and ideas, and tasks are lost, not to mention everyone spending more time.

What can you do differently?

Meetings can be very ad-hoc and held when required. If you need, you can meet multiple times a day with the whole group or just a group of them. You might decide to totally skip it or change the format to simply state who will work on what.

Iteration Review or Demo days (example of a two-week sprint cycle, 10-person team)

Duration: 30-60 minutes for a two-week sprint cycle

Collective Team Time: 10 hours per week

Purpose: Showcase what was delivered during the sprint and get immediate feedback.

Product owners, users, business stakeholders and developers are brought together to review what has been accomplished since the last sprint.

Problems:

  1. Points one and two from Standups are valid problems here as well – Iteration reviews often run over and participants may not all be engaged.
  2. If the demo does not go well, you have created more topics of discussion and lowered the energy of the entire team.
  3. The preparation time for the demo itself requires deployment, creating good data, verifying several times that things will work, and thinking about how you can hide the parts that are not working, and others.

What can you do differently?

Show progress every day, as it happens, so that the customer can make changes on the fly instead of waiting for the sprint to end and working toward creating stories for the change requests.

Retrospectives

Duration: 30-60 minutes for a two-week sprint cycle

Collective time with 10 people team: 10 hours per week

Purpose: Understand what is not working and improve.

Held after completing an iteration, the entire team comes together to discuss what worked, didn’t work and what to change for improvement.

Problem:

  1. As the team grows larger, you can only pick a few high priority problems and the rest stay in backlog forever.
  2. Action items are not always taken on. Other priorities put a few high priority ones in the backlog too.
  3. Points one and two from Standups are still valid – retrospectives often run over and participants are not engaged.

What can you do differently?

Everyone knows what needs to change every day. Make those decisions as they happen and don’t wait for the entire sprint cycle to call out to then come up with an action plan and then make changes.

Taking only four of “Agile’s key ceremonies” into consideration, you can see that if you closely follow the “rulebook” you are likely spending invaluable time stuck in procedures that often do not truly accomplish the Agile’s goal. Remember the key tenet - “Our highest priority it to satisfy the customer through early and continuous delivery of valuable software.”

The side effect is lost time, and generating twice as much time to perform these rituals than not. In addition is the glaring problem that each ritual is trying to solve a problem that is typically never solved completely.

Some of those things I outline here should be, in my opinion, common sense. They may spur an uncommon feeling. But by simply creating the right level of communication for the team in a manner that fits your organization and the personalities of your “people,” you can save immense time and, ultimately, create self-organizing teams.

When we deviate from the original principles of the Agile Manifesto and create strict rules, we lose focus on development and doing what really matters – getting things done.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,agile manifesto

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}