Agile Edge Cases
Don't be a wimp! Master Agile Edge cases and become a master Agile Ninja Warrior Kung-Fu Zombie Apocalypse Jedi Awesome Dude Person
Ever think about Agile edge cases? You know, when somebody’s flashing the manifesto up on a screen, waving their arms around, and talking about how each item is important, just one side is more important than the other. It’s kind of a feel-good moment that we all like. But in the real world we know it’s not always so happy. There’s hard conflict, and the system fights against itself. In the programming world, where something is right at the edge of a conditional statement, when two rules conflict, we call that an edge case.
As a coach who has also been part of coaching teams and helped set up coaching groups that have coached even more, I’ve had my eyes on and talked about literally hundreds of teams adopting Agile. These agile edge cases come up. A lot. So let’s walk through a few.
Scenarios and Recommendations for Agile Edge Cases
The team doesn’t want to do Agile. As ScrumMaster you’ve tried to provide the training and guidance, but still the team wants to do something completely off-the-wall, like use a waterfall process or have each person plan out each detail of their work for the next 30 days. This can lead to some heated arguments about who is “really” doing Agile or not. Why say you’re Agile if you want to do all this non-Agile stuff?
What the team decides, rules. End of story. Agile just isn’t Agile if the team is doing what you read in a book last month. If Agile is anything it’s everybody helping each other out even when the rest of the team won’t listen to them. And that includes the ScrumMaster. Being a servant means serving.
The Product Owner Role is badly-staffed/missing. You either have a guy there all the time that can’t make decisions, you have nobody there aside from a few minutes a week, or some lame combination in-between where the real Product Owner role is basically missing-in-action. If you wanted something to kill team enthusiasm the quickest, this is it. Describe a simple, no bullshit system of working and then don’t implement it.
Welcome to the real world! And suck it up already. You have two jobs in any organization: create value effectively and communicate why you aren’t creating it as well as you could. In this case, “creating value effectively” ain’t in the cards for you, so the second part of your job is paramount. Learn to start communicating your problems with the Product Owner role. Use your stand-ups, demos, and retrospectives. Email. Kindly pester. Plead. Whine. Working these types of Agile edge cases, the ones where you’re hosed, it’s all communication now.
Yes, "Edge Case" is overused, but in this instance learning about Agile Edge Cases can be very useful
Management is always trying to “help”. Management may know that they’re chickens and not pigs, but they’ve also become very good at working their own guerrilla management organization. They stay after stand-ups for questions and answers (the old status meeting), they smile and use non-verbal body language to encourage the team committing to more stories than they can deliver, or for the ultimate in kabuki theater, they just tell the Product Owner what to say while everybody’s in the room. This is the problem that will go unstated, it just hovers like a dark cloud over everything the team does, killing initiative.
Give up. Management is the ultimate Product Owner. They are bypassing everything. So let them do it. Don’t fight a losing battle. Make them (all of them) Product Owners. Do it publicly. Let them carry on as usual. But gently keep reminding them that the point of a Product Owner is having one point of contact. It prevents the team thrashing around. You don’t have to be a jerk or act like you are carrying a grudge, but you do have to keep reminding them about the consequences of what they are doing. That’s your job, not to let them forget.
Your Product Owner is asking you to do stupid stuff. The Product Owner wants you all to attend training for 3 days on something you will never use, or he tells you that he wants to make the system harder to use for the customer. One team I know spent two months “thinking” about the look-and-feel of an insurance claims screen. The team would do a working mockup. The Product Owner would decide, his boss would change it, then he would make a new decision, then the VP would change it. Two months. A team of five people playing with UI mockups. People want to be doing something important at work. Sending them on wild goose chases simply underscores the message that they aren’t that important.
The Product Owner rules. Even if he wants stupid stuff. If the Product Owner comes into the room tomorrow and says “Hey guys, next sprint I think I want you all to wash my car and start doing my laundry.” guess what? You’re going to be learning some advanced test-driven laundry skills next sprint. You have one person who can tell you whether some goal is worth achieving, and that’s the Product Owner. He can’t tell you how to do it, but he can sure tell you what needs accomplishing. Of course, you’re supposed to have a close relationship with the P.O. such that you guys all understand each other. This shouldn’t happen — but it does. If it keeps happening, I’d be looking for another gig.
The only reason you’re adapting your work is to meet a complex plan. Your Agile team is complimented and encouraged, and they’re told that there will be a day-to-day plan put together for the next six months outlining all important work, including required milestones. After just a few hours of working on a complex, detailed plan, all hope is lost. You can forget about having an exciting project carrying around that kind of baggage.
Put somebody in charge of creating and managing BS plans. But don’t use the plan inside the team at all. If the organization wants a 12-page GANTT chart, give them one. Have Joe pretend to be Project Manager, create a complicated plan, and do all of those plan things. But still work in an Agile fashion. Joe can drop new items in the sprint (with the approval of the P.O.) as they become necessary. This isn’t complicated. The plan is just a facade, a way of assuring the organization that you are not forgetting things.
The tool is the interaction. Agile, as far as you know it, means updating an online tool everyday and doing a telephone call for a status meeting. Agile is just like the old system, except with different tools and different names for the meetings. The Agile experts at the company wave their hands around a lot and talk about stuff like “emergent behavior” and “self-directed work groups”, but in reality they’re the people pushing the tools. Everybody just wants you to not rock the boat, keep your head low, and fill out the tool. Like always.
Tools communicate meta data to people outside the team. In-person conversations communicate things inside the team. If you’re on a wire somewhere, adding things and moving them around on a screen, you’re not on the team. Hate to have to tell you that. There are a lot of teams that actually have no members. It’s just a collection of folks working together to complete tasks set up on a computer. Nothing wrong with that. Heck, it might work great in some cases. But it’s not a team. If you don’t know the name of the other guy’s dog and what his favorite band is, you’re not working on a team together. You’re just working by yourself with someone else on the net.
The documentation is more important than the work. On one hand management is pushing for the work to get done, on the other hand there are these other managers that tell us that there’s a ton of documentation to do. If we don’t do it, we’re not done, no matter what the program does. I’ve had teams with support personnel onboard who told them the documentation was never used — yet they had to do it anyway. Some teams not only have documentation, but each document has multiple layers of sign-offs. Required. Talk about killing a project with paperwork.
Just like with the complex project plans, put the documentation on a separate track from the coding and Product Owner acceptance. This really sucks, but it beats tying up everything inside of one story. For approvals, split the stories into pre-approval and post-approval. Then add a column to your storyboard for “delayed by approval” and park those there. (Whether or not you want that column as part of your sprint or simply another section of your backlog is an open question.) Point them out everyday. Draw a line on your project burn-up to indicate the amount of work that the approval process is blocking. In short, get really good at identifying and communicating these impediments by modifying your storyboard, splitting stories, and diagramming impact.
Agile Edge Cases Teach
If you want to be a good programmer, you learn how to handle edge cases in your code. By the same token, if you want to be a good Agile practitioner, you should know and be able to respond to Agile Edge cases in your practice. It’s the Agile edge cases that really show us what it’s all about.
If you’ve read along this far, you might be interested in improving your Agile practice with my books on implementing Agile. Up your game so Agile edge cases will defeat you no more!
February 8, 2012
5 responses to Agile Edge Cases
Having a single PO is problematic. As a single point of failure its completely inefficient and has no checks and balances. PO telling you to wash his car needs to be checked! Also a team of 8+ developers needs a “team” of product owners analyzing the requirements and feeding them to the team in parallel otherwise they will choke the PO on minute clarifications (the reason why POs start going missing in every agile project). I’m not even going to start on larger teams or teams spread across timezones. The product team can and should coordinate their activities just as any other team.
Documentation is important! Its similar to when engineers coordinate services between themselves, they absolutely must document the interface of all services they create for others to consume – these contracts must be clear! Similarly the product team needs to document their high-level features and eventually the their detailed scenarios (both happy and alternate) – as this is the interface contract for consumption by the development and testing teams.
Finally, the big-picture must be understood, documented, and maintained throughout from both a product standpoint as well as the development standpoint and in some cases from an enterprise standpoint. The big-picture must leverage the analysis of high-level features (both functional and non-functional) spanning well past the goal release date, this analysis should include all associated risks, their mitigation strategies, prototypes and proofs of concepts. You cannot perform this duty in a distributed manner in short sprints. You needs dedicated lead roles to manage this long-term big-picture – lets call them Engineering and Product Architects. The Architects must collaborate and coorindate effectively the activities of both the product and development teams to keep it on the big-picture track. Finally a Project Lead coordinates the overall delivery schedule. The governance of this structure can be setup in many ways but the goal should be that everyone’s voice is heard.
Agile before it became bastardized, was the ability to effectively manage needless documentation and analysis paralysis. For this one needs only to place the appropriate controls in place targeting such criteria and ways to mitigate them.
Sony,
First, thanks for the comment. I appreciate your taking the time to share your thoughts.
Instead of taking you up on the details of your comment, which I found to be misguided, I’ll address what I feel is the underlying premise: paperwork equals risk reduction.
Yes, there might be a team the Product Owner works with to coordinate features. Yes, there might be a need for a BPM and UCM-like set of documentation aligning the work of the team with the strategic plan of the organization. There is definitely a need for this type of work in any project of consequence.
But that’s just it, there’s a need for this type of work, not paperwork. If there’s one thing we’ve learned, it’s that the paperwork is not the real work! The paperwork just signifies the work has been accomplished and recorded. Business contracts of this nature have an extremely limited useful lifespan — measured in weeks if not days. It’s not like programming where you can create an interface contract and expect it to still be useful months later. Business environments change. Quickly. Decisions on a wide range of things need to be updated both frequently and in an unscheduled manner.
Agile is dynamic process tailoring. That doesn’t mean there’s no need for the things that you mention, just that the team (and organization) quickly and adaptively tailor the formality and paperwork required to the current needs as measured by those closest to the problem. I always tell people on my Agile teams that you are welcome to bring any process or documentation you’d like into the team room. We’ll evaluate whether it’s a risk worth addressing, then decide how to address it: documents, meetings, give it to an enterprise group, etc. Too many people want to think “Agile means we don’t do requirements” or “Agile means we don’t do Enterprise alignment and strategic planning.” That’s just not true. The trick is how we do those things. I don’t think you’ve figured that part out yet. You’re still talking about all these pieces of technology development as separate things to be done, when in fact they are project and enterprise risks to be considered all together (and balanced) in an ongoing manner. Different way of looking at the problem entirely.
You get into program management as well — how a product might evolve over several years. Great topic, but not related to my post at all. Plan on going into it with a future entry, though.
Thanks again for the reply!
“paperwork equals risk reduction” – Sorry, that was not my underlying premise. My underlying premises were “efficiency”, “clarity in contracts” (between teams and team members) and “alignment” with big-picture visions (product, project and enterprise). Most importantly the lack thereof in Agile methodologies.
Regarding “paperwork”. The human race took major leaps in evolution when the following happened: spoken language, written language, mass-printing and now of-course the global information paperwork known as the internet. Documentation is primarily for “clarity” pinning down information otherwise floating as ambiguous interpretations. Clarity is in terms of both the facts of the domain as well as communication. Clarity leads to increased efficiency in a team of many members – as seen with the timely leaps in human evolution.
I have no issue with documentation being only a snapshot in time and getting stale and letting the code become the ultimate authority. But you cannot expect the product team or testing teams to grok code only. Also without strict standards enforcement code soon evolves into unreadable spaghetti understood only by the longest surviving members of the teams.
In the end Agile methodologies are analogous to this: Driving to an unknown destination with “NO” authorative map in hand and everyone having a different idea of how to get there. Yes, you might get there eventually by getting lost a zillion times. But its better if you pin-down the big-picture concretely on paper so that everyone’s on the same page (pun intended).
This is turning out to be a very interesting conversation Sony! Thanks for sticking with it.
Let’s see, you’re hitting on “efficiency”, “clarity in contracts”, and “alignment”, right? These are the things you are so worried about?
I think the problem here (and please correct me if I’m wrong) is absolute thinking. Nobody is saying that enterprise alignment shouldn’t happen, or that lack of clarity or efficiency is a good thing. Everybody has the same goals (except maybe for the true Agile zealots who refuse to look beyond the teams, or the true order-junkies who refuse to see the true impact of the risk-reduction strategies they are using.) The question is how to achieve them.
First off, there is no “Agile Methodology”. It’s best practices around iterative, incremental development. Different practitioners can give you different answers, and that’s okay. That’s the way it’s supposed to work.
Over time, we’re beginning to spot trends in these best practices, an underlying philosophy that holds true in the creation and maintenance of complex systems. You could call this the “philosophy of Agile” if you like. Like so many other things that Agile doesn’t directly address, if you want to talk alignment and all of that we must discuss some philosophy, work through the implications, then apply it to our particular situation.
This is way too much to go into in a comment, so I’ll use a metaphor that I hope I won’t torture too much.
Every series of projects at an Enterprise level is just a collection of nodes exchanging and transforming information. That information may be requirements, user interface standards, tools training, etc. The trick at both the project and enterprise level is to choose the appropriate format and channel for the information.
Now we know that some mediums offer us much greater bandwidth — we are able to contain a denser amount of information in a smaller physical space. So we use things like UML diagrams and sketches to convey things that conversations never could easily accomplish. But we _also_ know that human beings have limited cognitive processing ability, so we don’t create 20-page technical specs when a 1-page diagram will do. (That’s not saying we never create those docs! Just that we’re aware of the impact of the information format and channel as we create and process it.)
Some pieces of information might be mostly static, like enterprise deployment practices. Some pieces of information are mostly dynamic, like the exact business requirements for the iPod app. I can’t give you hard and fast rules, because it varies from organization to organization.
What we have found, over and over again, is that practitioners focus more on the purpose of the information channel than the format and channel. So, for instance, it might be very important to provide exact details in some area for enterprise alignment, so a set of documents might created along those lines. Over time, however (and this could be as short as a couple of weeks), the series of documents could easily run into the hundreds of pages, contain complex diagrams not easily understood or — most likely — overly constrain execution teams in areas that are inappropriate, all in an effort to reduce alignment risk.
It seems like when you are the person not responsible for creating direct business value, everything you can do to make things more “efficient” seems like a good idea. You’re never making immediate trade-offs. Many times you’re never even aware of the changes you are instituting.
The original Agile wonks just took a look at the state of affairs and said our emphasis is on the wrong things. Not that we should start one thing and stop another, not that we should never work through the issues that you’ve brought up, just that we have the right idea that we’re executing in the wrong fashion.
We have to keep the human aspect first and foremost. We have to understand that clarity has it’s limitations. Maybe there’s a shop that’s striving for ultimate clarity, but I wouldn’t want to work there. Research in languages shows us that words themselves don’t have unique and concrete meanings. Instead, they exist in a framework of other words. Each project creates it’s own system of meaning, as any good OOADP architect understands. There are a lot of folks that think that once we define a concept like “customer” we’re done with it. This is simply not true — and helping folks understand why is something we technologists need to get better at.
So yes, clarity, alignment, and efficiency? All great things. Let’s all work for them. But we’ve been really bad at these things in the past, mostly because of the mental models we’ve been using. Written communication is terrific, but it’s not like programming. Simply because you can create a 50-page document of how you’d like widget X to be created doesn’t really mean much at all. If talk is cheap, written communication in technology shops is even cheaper.
Wish I had time to go into this in more detail today. Thanks again for continuing the discussion.
The meaning of agile in short according to me is to have a process in place that’s to maximize not only individual efficiency, but also the team efficiency.