When they won't let you do Agile
If you’re a fan here, or if you’ve had more concrete experiences of working on Agile software teams, you probably have a good sense of how well the Agile values and practices can really work.
Problem: Not everybody sees that. Especially (perhaps) your boss or project sponsor.
So I threw this question out on LinkedIn earlier this year:
How much Agile have you been able to get away with? How?
One response in particular stood out for me. Lou Storiale wrote:
Sometimes Scrum can be implemented without anyone knowing it…. At first, I asked my staff (2 others) if they could meet 3 times per week for 15 minutes or so? They of course said yes. So we began meeting, I didn’t keep a specific regimented routine of “what did you do, what can you do, what is getting in your way,” I asked what’s on your plate for today, how much do you think you can do by “Friday” – anything going on (meetings) that might keep you from doing that?
That’s not a true Scrum, but it embraces the essentials of the standup meeting concept. The boss came along quite a bit later, says Lou, and asked what was going on. Lou (the project manager at the time) admitted he was doing what I call “Stealth Scrum.” The boss–not a big innovator or early adopter type–rolled her eyes and said, “Uh, okay.” And that was it.
“It works,”
Lou said. “That is what matters.”
Why?
This sort of thing, the bottom-up movement towards adopting happier development practices, happens all the time.
After my presentation on “Why Your Software Project Sucks (and how to make it not suck)” at NOTACON7 a couple of months ago, several participants hung around to ask more questions. One of them was really interested in Test-Driven Development, but he was looking at a million-line “big ball of mud” legacy system to start with. I pointed him at Working Effectively With Legacy Code, a book I blogged about in the past. At last report he’s awaiting shipment on the book. Rah!
Along those lines, one of the nice things about test-driven development is that you can sometimes (not always) just start doing it without permission from anyone. In a .NET environment, it means you have to download (for free!) NUnit and add a reference to your Visual Studio project. (Everyone who maintains the same project will have to do the same in order for their builds to work.)
Back to Why Stealth Scrum Works
Stealth Scrum works because, like many of the most effective Agile practices, it’s just a slight formalization of the things smart people are already doing to be as effective as possible. Whatever your formal methodology, or even if you don’t have a methodology at all, you probably check in periodically to find out what everyone is working on and whether they have any obstacles. If you don’t, why not?
Stealth TDD works because smart developers do unit testing anyway. The only difference is when you write the tests.
Stealth Pair Programming works because the best developers review each other’s code anyway. The only difference is that a pair does code review constantly, not just once a day or at week’s end.
What’s in a name?
Just as there are many shops that call themselves “Agile” but insist on top-down control of everything, there are shops that would never call themselves “Agile” but are actually doing a decent job of implementing the principles of maximizing the amount of work not done, adjusting and tuning, and making frequent iterations.
So if management won’t let you do Agile, don’t fight it. Just say “We’re gonna hang out and code in the same cube for a couple of hours.” Or say, “I’ve got this code written that will test our new features before the integration steps.” You might even get to deliver working code every couple of weeks as long as you don’t say the word “sprint.”
The Agile Principles are important. What you call your technique is not.
Have you tried Stealth Agile? How well has it worked for you? What are your suggestions?
September 22, 2010 @ 12:05 pm
You are either Agile or you aren’t. There’s not much wiggle room between. Lately I’ve been hearing a lot of people claiming to be agile, when in reality, they just aren’t doing waterfall anymore.
September 22, 2010 @ 2:26 pm
1. “You are either Agile or you aren’t.” I mostly agree with that, in the sense that Agile is not whatever you feel like calling Agile. Just because your processes are informal, that doesn’t make you Agile. It might just make you inconsistent or lazy. It’s not just a matter of your own opinion though–so on that we agree.
2. “There’s not much wiggle room between.” I do disagree with that. There’s such a thing as being half-Agile. People make progress towards the Agile Grail a little at a time. Or they get to a place that works really well for them and stick with it. If your system aligns with the principles and you’re remaining flexible, that’s okay. Being less than 100% on with a methodology doesn’t make you wrong.
3. “Just aren’t doing waterfall.” Totally 100% agree. Absolutely.
September 22, 2010 @ 2:46 pm
Agile isn’t the only way to build a successful product. I wouldn’t consider “half agile” to be agile at all, it’s more simply “this process I made that seems to work for us.”
Agile comes in many forms, and you certainly could make your own process which is agile. That’s what we’ve done at Prfessor, and our process is the best one I’ve ever worked with.
I could call myself skinny, but that (obviously) doesn’t make it true. Designing a process and calling it “agile” doesn’t make it so.
September 22, 2010 @ 3:14 pm
I think the issue here is confusing using a bunch of steps that are part of an agile process, and actually being an agile environment. You are welcome to have all the daily scrums you want, but if your are working within a framework that values following a plan over responding to change, comprehensive documentation over working software or processes and tools over individuals and interactions – you aren’t agile. You are just pretending, and maybe making your situation slightly better along the way.
Your post implies that using an agile process makes you agile. That’s hardly the case. It doesn’t make you agile any more than standing in your garage making engine noises makes you a car. Agile is a philosophy, not a process or a set of steps you follow. Josh is right – you either embrace the philosophy or you don’t. There’s no middle ground.
September 22, 2010 @ 5:13 pm
Ron Jeffries wrote about something similar
todaya month ago: http://xprogramming.com/articles/beyond-agile-new-principles/I totally agree with Ron (and Dave, and Josh) that “Changing the definition of Agile will not make Mars-based development work any better. The Agile values and principles are just fine.”
But “they state an ideal.” All I’m saying is sometimes that ideal isn’t accessible and you do the best you can to follow those principles in the environment you have.
September 24, 2010 @ 5:44 am
“But “they state an ideal.” All I’m saying is sometimes that ideal isn’t accessible and you do the best you can to follow those principles in the environment you have.”
This is completely true in corporate IT. It is utterly impossible to pull a product manager (if a singular one actually exists), business analyst, project manager/agile coach, developer and tester (if you actually have QA) together in the same room physically, give them a application environment/framework they can exclusively control and then let the Agile magic happen.
Budgets, cross-functional resource management, and over all concurrent program management all make it extremely difficult to leverage pure Agile.
Thus, Mark, I do subscribe to your “do the best you can” statement because that is what you have to do in certain real world situations.
September 28, 2010 @ 2:33 pm
“Agile is a philosophy, not a process or a set of steps you follow. Josh is right – you either embrace the philosophy or you don’t. There’s no middle ground.”
There are always purists that chime in to invalidate a process that may or may not seem 100%. However, philosophies do not get project done on time nor do philosophies create a better product. Philosophies might influence process but it is the process that produces results.
Everyone knows or who has experienced change/change management knows that it is better to be 100% without company approval than 0% with company approval. The issue is this: “What do you do when your boss in uninformed or refuses to change process officially?”
If the situation calls for an Agile process or philosophy sometimes you have to implement that process without a company culture transformation. You do this in baby steps. The first step is to begin to implement the process slowly, prove that the process works and move on to additional processes until before you know it, the company philosophy has altered.
Philosophy does not require 100% buy-in at any certain point in time. There is no line of demarcation anywhere in the history of traditional philosophy, it creeps in, gathers support, integrates itself into a culture until after a period of time, the philosophy is deemed “truth.”
Such is the way in some companies. There are always naysayers, uninformed management and outright saboteurs. Stealth Agile or Stealth Scrum is a way to begin the acceptance of a new cultural philosophy.
There is no 100% anything regarding project management unless you walked in the door and the philosophy was already propagated and accepted.
October 2, 2010 @ 3:29 pm
Thanks for your comment, Lou.
As Alinsky put it, “People are more likely to act themselves into a new way of thinking than they are to think themselves into a new way of acting.”
October 5, 2010 @ 7:52 am
This is a great conversation, and I wish I had come across it a week or two ago.
We are in the process of evolving into an Agile-based environment. I suppose some might say that we’re not agile, since we don’t meet some set of criteria, but really, who cares? Like Lou says, sometimes baby steps are the way to go.
The point is, it is starting to work for us. And when I look back at where we were before we started this journey, and compare it to where we are today in terms of productivity and developer satisfaction, I am quite pleased. There is much to do, but as an old-school waterfall-type project manager, I’m sold on the benefits of Agile at this firm in particular.
My approach is to apply constant but gentle pressure on everyone (opponents and supporters) to continue adoption of activities and thought processes that will help us to evolve to a more competent Agile environment. Will we ever get far enough along the scale to meet some set of criteria so that we can claim to be truly Agile? I’m not sure I care about that. All I care about is whether we are getting the job done in a competent and sustainable way. The rest will sort itself out.
October 5, 2010 @ 9:12 am
I think the other commenters are right in that the Agile practices only work in a surface-y kind of way if you don’t really get and buy into the Agile values and principles.
If you don’t really love collaboration, and if you feel possessive about your code, and if you are super hung up on getting personal credit for things… then pair programming is kind of a band-aid.
If you don’t truly value openness, then a KanBan system may somewhat work for you… but it will be hugely compromised by vagueness and hedging.
That having been said, I really like the idea of actions creating thoughts and feelings. It seems backwards, but it’s a real phenomenon. If you’re not really into changing requirements, but you’re at least a little open to the idea, then working with changing requirements in an Agile-ish space is likely to update your thinking.
That’s why I totally endorse doing some Agile practices without management’s open support, if that works for you. It gives you (the dev team and partners) some benefits of Agile, helps you catch onto Agile principles, and lets management see and experience Agile benefits rather than talking them to death.