The gospel of Agile seems simple on the surface. Put in place certain consistent ceremonies. Break the work up into small chunks. Measure complexity, not time. Don't tell the business when things can be done.
Is it working? The flexibility of Agile, often seen as a strength, is frequently a weakness. The trouble of scheduling complexity instead of time is a burden to the business. The trouble of measuring velocity is a burden to project managers. All those ceremony meetings are often seen as a burden by developers.
It is difficult in the face of high expectations, complex software, organizational bureaucracy, and looming deadlines, to value these Agile ceremonies. They all have a purpose of course, but if we are not able to give them due time and attention then they become worse than useless.
Beginning with my personal favorite complaint, let’s look at The Sprint Retrospective. Very few would disagree with the assertion that examining our performance and coming up with things that we can improve on, as well as applauding ourselves for things we did well, is a good use of time. One nice thing about the retrospective time-wise is that it is a very stream of consciousness meeting. Make a few lists individually during the session, group common items, rank and prioritize, review. Having just come off of an intense delivery cycle it can be difficult to reflect at the time in which these are usually held - we are still recovering from the last Sprint and trying to get aligned for the next one! Wait too long and you can't really remember what happened anyway. However, the biggest problem with this ceremony is that it is common for the same complaints to surface every time, because the feedback loop is usually broken. The purpose of the retrospective is to capture needed change. I have not seen many project or program managers that have the cycles or even mindset to feed the acknowledged deficits back into fresh requirements or process changes - nor to feed the credits back to recognition or spiff programs.
Next let's look at Backlog Grooming, which apparently has a terrible connotation in the UK and has been relabeled to Backlog Refinement. The reasoning had to be explained to me in a rather awkward conversation. But I digress! The ceremony is critical because generally everyone wants to keep an organized house. For me, Backlog Refinement is an opportunity to put the I back in Team. As in, I'm happy to take one for the team, and do this piece of work with the project manager and possibly a product owner. This session really does not require the full technical staff, just the people who need things and the tech lead of the people who make things. The rest of the developers are just sitting there on mute, rolling their eyes and multitasking anyway.
How about The Sprint Review or The Sprint Demo? First of all, something I often advise but is infrequently adopted is to start your Sprint with a demo script. I'm not sure why this is a challenge, but at least for me knowing what I'm going to show in 2 weeks or so is crucial to keeping me on track in the development process. If you have QA staff, let them do the demo! In theory they've been using the product more than anybody else. That said, this is a great one for your developers to attend because this is one of the few opportunities developers have to receive positive feedback instead of the normal thankless grumbling they hear the rest of the time.
And finally we get to the holiest of holies. The Daily Scrum. What did you do? What are you going to do? Anything in your way? This session, repetitively performed on a daily basis is challenging to keep from becoming either overly long or pointlessly redundant. A well run team doesn't really require this status check in. Instead I propose a team-chat-based scrum monitored by the project manager for hotspots and direct interaction indicators. An ad hoc session between involved individuals can be conducted as-needed to satisfy any cross-developer or cross-feature or cross-team issues/obstacles etc. This way we reduce the grind, while setting aside explicit time for actual problem solving when needed.
As a consultant, I have worked in many environments. I can honestly say I've never seen two Agile implementations the same. Organizations reference the flexibility while they implement oversimplified or overcomplicated solutions. So is Agile a wrong approach? Definitely not, but as always the "how" matters, the truth is in the details.
It is not at all unusual in my experience to be brought into an ongoing software project that is under heavy fire from business for being overdue and over budget, only to find the problem is not where the blame is being placed, on the developers, but instead the problem is buried in how the work is fed into the process.
The communication gap between what a stakeholder wants, a product owner describes, and what a developer understands, is often vast. Solving this problem is the key to making your Agile process work for instead of against you.
Yet solving this problem somehow seems unique to every organization. Without exception I have found a need to customize/tune the workflow and cadence to the organizational makeup/dynamics present. However, there are key steps that can be formalized to provide a framework for fixing our communication problems between tech and business. Our version of this formalization is called “Lean Drops”, because lean things are cool, or used to be. Whatever we call it, understand it is a “philosophy of communication” not a prescriptive software development process.
