You all know that I love agile and all things agile. Every now and then its a good exercise to question the things we hold so dearly. I figure this might be an interesting thought process so I’m blogging as I think through it.
Can I question the agile manifesto? Mmm perhaps I should take a more aggressive approach and defend the opposite. That might open my mind to more ideas. Here goes:
We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:
I suppose you are entitled to your opinion. I am sure there are many people in the world who believe they have uncovered better ways of developing software. Wow. This is quite difficult – feel like I’m dissing my community. Pushing on …
Individuals and interactions over processes and tools
So I totally get that people are more important than machines and ideologies. But we are building SOFTWARE. Thus we are computer people, who love online tools. Most of us run our lives using these tools. We trust the tools we develop with, usually more than the random person the company hired to work with us in a team. As a developer I am good at what I do – so let me do it. I don’t want to do your job of analysis and understanding. I want to do my job of making it work. Just had a lightbulb moment in understanding some developers anti-agile stance.
Working software over comprehensive documentation
I believe in noting things down – when I don’t I inevitably forget about them. Thinking through a problem space and carefully noting all the things that need to be done is due diligence. When you think through a problem and spend time there, actually doing the work to solve the problem is easy. Of course I still want working software, I just think having a well thought through document will solve 90% of the problems. This was a bit more tricky, I really don’t like verbose documents. But if I think of it as a thinking tool I can make sense of it.
Customer collaboration over contract negotiation
I know the customer is always right, but blindly following the customer – who probably doesn’t know what he wants without a contract is business suicide. How will you make money if there is no agreement (legally binding) of how you are trading services for cash. As a customer I want to know how much something is going to cost me before I commit to paying. I need to talk to other vendors and compare prices. I need to know what you will give me for my hard earned money as opposed to someone else. Ok getting into the flow of things now, this one felt easier. It helped to think of my upcoming house renovation and what I’m needing as a customer.
Responding to change over following a plan
Everything I do in life has a plan. Yes they change – but not by much and only when something goes horribly wrong. And my plans cater for some ‘problem’ time. Following a plan gives me certainty to whether I’m on track or not. It lets me know and plan for other things in the near future. Of course I want to respond to change – but only if it affects my plans end goal not for the sake of change. This one was much easier. I do believe in plans, and I love responding to change, however I’ve seen how quickly a project can get messed up by only responding to change.
EXERCISE OVER!
OK so lets see what I’ve learned.
1) It’s fairly easy to justify almost any sentence and provide examples of why you’re ‘right’.
2) Even the things I believe in wholeheartedly can be wrong at times.
3) I shouldn’t judge those who believe differently. I should seek to understand – as they probably make a lot of sense.
That was fun, and challenging 🙂 What do you believe in? Can you question and defend an opposing argument?
Hmmm… funny you skipped the last sentence of the manifesto, which kind of summarizes your lessons learned: “That is, while there is value in the items on
the right, we value the items on the left more.” 🙂
I had it in there, but I felt like I was just repeating it so I removed it … perhaps I should have left it in 🙂
I love the spirit of this post. If we don’t question our assumptions, we run terrible risks. I think we can borrow from Feynman’s statement that part of the obligation of scientists is “bending over backwards to show how you’re maybe wrong”. It’s also pretty courageous, given how heated these things can get!!
I agree that the last sentence is what brings it all together. For me, the reason that Agile is better than any other flavor-of-the-month approach to the world I’ve encountered is that it represents a point of view coupled with a belief in some degree of balance. It is loose enough to allow creative growth, and the balance keeps that growth from being unidirectional or dogmatic.
I also think that the manifesto without the 12 supporting principles is a shade of itself. For example, tack this principle into just about any working system, and I’m going to get pretty excited: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” For me, those principles fill out the skeleton of the initial four “this over that” statements.
I am now foolishly going to wander into countering points that you made to counter yourself, which will likely just be preaching to the choir. But just in case someone reads this and says, “yeah, she’s got a good point, Agile is terrible”, I include my rambling:
“We trust the tools we develop with, usually more than the random person the company hired to work with us in a team. As a developer I am good at what I do – so let me do it.”
“Without Limits” is a movie about Steve Prefontaine, a runner who apparently had an absurd level of raw talent. The movie focuses on his relationship with a coach who tries to help develop his potential. The relationship is complicated, and sometimes the coach steers him wrong, but it touches on the important idea that you might be good, but you can always get better. Something as natural as running can be improved even at the highest levels of the sport. Agile addresses this continuous improvement, but it also gets into the very important team dynamic (which a movie about an individual runner obviously does not!) The single developer hero may go interesting places, but I believe that being part of something larger is lands better. Unless you are a work-from-home consultant, you’re going to be in some sort of team. I have worked with devs who embody this “I’m good, leave me be” stereotype; I find it endlessly tricky to avoid making them feel like you are trying to fix them, but I have faith that supporting them while simultaneously supporting our beliefs about Agile can lead to a better world for all involved. My best luck has come from avoiding any agenda, and from discussing things openly and with minimal judgment (thank you, Lyssa Adkins). But even that luck is limited, so–while I maintain my optimism about the possibility of breaking through this knot, I think you are right to identify it as a major sticking point for many.
“Of course I still want working software, I just think having a well thought through document will solve 90% of the problems.”
I might understand this part manifesto line wrong, but I always thought the documentation being discarded was the 100-page spec I wrote for a six-page website at my previous job. Drawing out good technical diagrams or writing down how to access a particular server seems perfectly above board.
“…customer is always right, but blindly following the customer – who probably doesn’t know what he wants without a contract is business suicide.”
I think one of the best things about Agile is how it uses iterative/incremental development to get around the terrible practice of customer-is-always-right development, but giving the customer a chance early on to see that maybe they weren’t as right as they thought.
“I need to know what you will give me for my hard earned money as opposed to someone else.”
This is tricky, but it comes down to trust. I have worked with vendors where everything was clearly written and I ended up with a terrible product and feeling a little swindled. Now knowing what I know about Agile, I would rather go to someone where there is less stress on writing it all out and more stress on a collaborative process of moving forward. In either case, the contract has holes you can drive a bus through, but in the latter case, the worst case scenario is that you can catch problems earlier, and the best case is a beautiful working relationship.
“Of course I want to respond to change – but only if it affects my plans end goal not for the sake of change.”
I think this applies differently depending on the audience. If you are rigid and think you plan everything out and never change, you need to learn this lesson. If you are already respond to change when necessary, you are in pretty good shape, and can ignore this lesson, apart from perhaps remembering to remain vigilant about the occasional urge to overplan.
And thus ends this absurdly long comment that is probably longer than the original blog post.
WOW that was a SUPER long comment – thanks!
Its pretty easy to justify anything – scary how easy it is actually. Being able to understand another point of view wholeheartedly is valuable though. Since this post I have been able to explain the 4 statements by explaining value in both sides and then highlighting why agile says left over right. Maybe I should try this with the principles – though I suspect that will be more tricky.
Yeah, sorry about the crazy rambling. Once I got into it, I got a little carried away.
I want to start doing this questioning exercise aimed at specific aspects of Agile that I am used to espousing. If I ever get around to it, you are totally getting inspiration credit!
Hi Sam,
I love the agile manifesto because it encourages to challenge your beliefs and gives you a lens to reflect on your own decisions. I agree with Rolf, the last sentence is hugely important. So is the first, even though it gets even less attention.
“We are uncovering better ways…” not “We have found the best way….” “…by doing it and helping others to do it,” not “by just doing it.”
So agile at its core is about learning, changing, and helping others. It’s anti-complacency.
One of my great a-ha moments came when I realized that as a trainer of Agile, I was not living the agile values, because I was not actively helping others to become better trainers (and I wasn’t sure how actively I was looking for better ways to train.”
I think the first sentence of the manifesto is massively undervalued!
I also love the manifesto for its pairing of things we might genuinely choose to value. There are no easy targets on the right side. So when you make a decision, you can ask yourself, does this decision emphasize something on the right or on the left? Is this decision consistent with my values? If I valued a left item more, how would the decision be different? What consequences would I expect? What if I valued the right side more…?
I use this reflection as an exercize in workshops, and find it a very powerful way to generate backlog items for improving the organization. What if we made ourselves a bit more agile…
Cheers,
Peter