Agile? What the hell?
This is not familiar!
Stand up. Now step two.
Agile? What the hell?
Agile? What the hell?
This is not familiar!
Stand up. Now step two.
The dialog about the value of stand-up meetings is as vigorous as ever. I hope it never gets settled. That’s because I frequently argue both sides. Just not at the same time. Which side I’m on depends entirely on the context. If the team composed of a single functional domain that has worked together for an extended period of time while co-located in a tuned collaboration work environment, then stand-ups of any frequency are probably a waste of time. If the team is for the most part remote and composed of independent contractors representing multiple functional domains, than it can be argued that daily stand-ups become THE most important scrum meeting.
I want to talk about the latter scenario in this post. Remote stand-ups can be the most challenging meetings for a scrum master to facilitate. (In the interests of space, I’ll have to set aside cultural and language issues that are frequently an issue while running scrum with remote teams. I do this not to minimize the importance of these issues, but to recognize they are worthy of much better treatment than I can cover here.)
Remember the agile manifesto? The first two line read:
Simply stated: Don’t bother taking notes during a stand-up. Not as a group, anyway. Individual agile delivery team members are certainly free to do so if it helps their individual efforts. Stand-up notes are a false crutch. It’s as near to a 100% guarantee one can get to say that no one will every go back and re-read stand-up notes. If someone is demanding stand-up notes be taken, suspect a waterfall zombie in your midst and respond accordingly. Worse yet is that the poor agile delivery team member tasked with serving as scribe is going to be so busy trying to capture stuff they will miss much of the conversation and information exchange that makes a quality stand-up so vital.
Consider quality virtual meeting hardware and software an essential tool for your business. We wouldn’t accept a surgeon who goes into the operating room with kitchen knives because they’re “good enough.” Sound professional, be professional. Clear and efficient communication is essential to the success of remote agile teams. Have the best possible communication tools available in place and cut corners someplace else.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Following from the Agile Manifesto value that is the title of this post, Principle #2 may be the most mis-interpreted and misunderstood principle among the set of twelve. Teams frequently behave as if this principle was prefaced with the word “always.”
Constantly shifting requirements leads to a frustrating and unsatisfying environment in which to work. It feeds burn-out and loss of morale. The satisfaction of a job well done depends on the opportunity to actually finish the job, no matter how small. Consider the effects on a finish carpenter who has just spent several days installing and trimming a full set of kitchen cabinets when the homeowner declares they want to change the kitchen design such that all those new cabinets will need to be ripped out and work begun on a new design. Or a film editor who has just worked 21 days straight to pare down an hour’s worth of video to fit into 7 minutes only to learn the scene has to be re-shot from scratch in order to match a change in the storyline.
Of course, the second principle does not state we should “always welcome changing requirements.” Nor does anyone I know claim that it does. But that doesn’t stop people from behaving as if it did. The rationale offered for agreeing to change requests from the stakeholders may be “We’re an agile shop and agile welcomes changing requirements” when, in fact, the change was agreed to because the product owner didn’t challenge the value of the change or make clear the consequences to the stakeholders. Or the original design was, and remains, needlessly ambiguous. Or the stakeholders have changed without renegotiating the contract or working agreements. Or any number of reasons that are conveniently masked with “welcoming changing requirements.” At some point, welcoming changing requirements is about as attractive as welcoming a rabid dog into the house. This won’t end well.
So, what kind of change is the Agile Manifesto referring to? There are several key scenarios that embody the need for flexibility around requirements.
So what is it that locks out the option for additional change? It’s a simple event, really. A decision is made.
Each of these scenarios where adapting to lessons and discovery is essential nonetheless end in a decision, a leverage point from which progress can be made toward a final deliverable. Each of these decisions can themselves form the basis of a series of experiments which, depending on the eventual outcome, may change. Often, a single decision point may look good but when several decisions are evaluated together they may suggest a new direction and therefore impact the requirements. If the cumulative insight from a series of decisions results in the need to change direction, that shift is usually more substantial and on the scale of a project plan pivot rather than a simple response to a single change in a single requirement. The need to pivot cannot reliably be revealed if the underlying decisions do not coalesce into some sort of stable understanding of the emerging design.
Changing requirements cannot go on indefinitely or a final product will never be delivered. Accepting change for the sake of change is what gets teams into trouble.
Much like the forces on evolution, there will always be some external force that seeks to change the project requirements so that the delivered product can be stronger, faster, better, taller, smarter, etc. This must be countered by clear definitions of “minimum viable” and “good enough” relative to what the customer is expecting.
In addition, product owners would serve their teams well by vigorously challenging any proposed changes to the requirements.
See also: The Changeability Decision Matrix
The rules are in place.
We’ve always done it this way.
Sound of waterfall.
I had the privilege of presenting to a group of potential interns from the Colorado School of Mines interested in agile project management. Action shot…
The slide shows what we can offer them as interns: Failure, chaos, and confusion. I unpacked that as follows…
It’s important interns have the opportunity to learn how to fail in small, deliberate and safe increments along with the opportunity to learn how to extract every possible lesson from failures and how those failures lead to eventual success. Much of our business is driven by experimentation and hypothesis testing. Most of those experiments will fail, at least initially.
We strive to be anti-fragile. One way to accomplish this is to be good at working under chaotic and ambiguous conditions. When involved with highly evolutionary design sessions, shifting sands can seem like the most solid ground around.
One of the values for bringing interns into the organization is the fresh perspective they offer. Why waste that on having them fetch coffee? However, interns can often be intimidated by working with people who have decades of experience under their belt. So it’s important they know they have the opportunity to work in an environment that expects questions and recognizes no one knows it all. They are in an environment that seeks alternative points of view. In this organization, everyone gets their own coffee.
What comes to mind when you think of the word “waste?” I’d wager a ten spot it wasn’t something pleasant. Rather, something to be pushed to the curb, rinsed down the drain, or thrown into a hole in the ground and buried. Even the sterile waste from technology projects has a high “ick” factor. If Josef Oehmen and Eric Rebentisch of MIT’s Lean Advancement Institute put the amount of time, money, and resource waste in corporate product development at 77%, how can there be anything good about waste?
Now think of something you value quite highly – a piece of fine jewelry, mastery of a sport or musical instrument, or your home. Have you considered how many resources may have been “wasted” to bring those highly valued things into existence? Shiny diamonds get that way by cutting and throwing away pieces of the original, mastering a sport or a musical instrument involves years filled with bad moves or cringe worthy sounds, and a significant amount of material was used and discarded while building your home.
When organizations consider implementing one of Agile’s many formalized methodologies or frameworks, the idea of eliminating waste is a prominent promise that helps close the sale. Cutting out waste means saving money and saving money means increasing profits. Unfortunately, this promise is frequently delivered to the agile teams as: “All waste is bad. Get it right the first time.” This message doesn’t support exploration and discovery. It doesn’t allow teams the space they need to find innovative solutions in what Stuart Kauffman called the “adjacent possible.” And it certainly doesn’t encourage the iterative development of numerous minimum viable products that build upon each other and lead the way toward the delivery of quality products.
The message I work to reinforce is: “Expect to throw stuff away, especially early on.” By itself, this isn’t enough to overcome the many negative connotations around waste. What is needed is a fundamental re-framing around the activities that have resulted in something one expects to throw away. A couple of questions are worth asking. What value is anticipated from the activity? What are the potential positive effects of having engaged in an effort at risk for ending as waste? Pursuing a goal of zero wasted effort is a fool’s errand. What we want to reduce is any effort that doesn’t add value. If 40 hours were spent exploring a technical option “only” to find out that it wasn’t a viable option in the long term, that throw-away 40 hour effort may just have saved 400 hours of developer time spent trying to make it work. And had the less-than-optimal long term option gone to market, the expense of supporting the early wrong decision could make or break the product, perhaps even the business.
Skilled agile practitioners have a strategy for monitoring the value of any project related efforts:
From a lean product development perspective, Oehmen and Rebentisch describe eight types of waste. I’ve included my additions and comments in parenthesis.
Kauffman, S.A. (2003). The Adjacent Possible, A Talk with Stuart A. Kauffman. Retrieved from https://www.edge.org/conversation/stuart_a_kauffman-the-adjacent-possible
Oehmen, J., Rebentisch, E. (2010). Waste in Lean Product Development. Lean Advancement Initiative. Retrieved from http://hdl.handle.net/1721.1/79838
Scrum mastering remote teams demands an extra set of skills than those required for co-located teams. The non-verbal cues we’ve learned growing up and throughout our careers are often not available with remote teams. Consequently, we have to train our ears to listen more attentively and follow-up to verify any assumptions regarding meaning from conference call, email, or instant message communications.
As scrum masters, we also need to coach team members to deliberately introduce practices that accommodate the lack of non-verbal cues during scrum meetings. For example, there are two practices I implement during remote stand-ups that facilitate the feel of co-located stand-ups.
Using techniques like this with remote teams does not replace the richness of co-located scrum meetings. They do, however, move the two a little closer.
The plan crashed and burned.
We seek and find root causes.
A lesson is learned.