pliantalliance.org

J. Timothy King has a good post talking about trying out new tools and being open to experimentation. This is a great sentiment and really the only way to mature at all as software developers. Try new things and see if they help. If you are having trouble with your current tools and processes, then what is the harm in taking a few days (or weeks) to try something new?

From the post:

A growing team is passionate about growth. And that means they will give new tools a fair chance. They might be skeptical. But because of their passion for growth, they will be able to set aside their skepticism. But they must choose to do so. They must choose to consider that maybe they’re wrong. They must choose to list what would need to happen to prove to them that they’re wrong. They must choose to test this list. They must choose to embrace the results and be excited to discover a new truth, to open up a new righteousness.

Another good point he makes is about slack time.

Of course, before you can take that risk, you need to have slack in your schedule. You need to be able to burn time in order to try new things. Slack is where you grow.

From what I’ve seen, too many companies are focused on the short term “get it done” approach. There is often no slack time built into the team’s process to sit and think and experiment. Research is key in improving both the developers’ abilities and the overall quality of the software being developed. Without slack, there is really no point in trying. You’re liable to be seen as wasting time and if deadlines are missed, “because I was thinking about how we can improve our overall abilities” likely won’t be an acceptable excuse.

I hate to keep pointing out one person’s posts, but Lidor is a great writer and says stuff so much more eloquently then I ever could. This time he writes about how we are all afraid to speak up and say what is really in our hearts about how we do software development. We know we should be trying something different, or stopping some technique that is more cost than benefit, but we just go along with what everyone else says, afraid of being labeled “uncooperative, pessimistic, or simply detached from the business reality”, or worse.

When you see a trendy technique that everyone thinks is the silver bullet, but somehow you just don’t see the benefit, speak up. Be that naive little boy who doesn’t know any better and point out that the emperor is naked.

Andrew has an interesting post on what we should call the traditional heavy weight waterfall processes. He comes up with “stubborn” as his adjective of choice, which I agree is a good word. But in his descripton of Agile, he contradicts himself.

In the first paragraph:

Agile is the most disciplined software development process I have used to date.

I was actually surprised at this statement and agree wholeheartedly. Agile is very disciplined. So disciplined in some cases that you get in trouble for daring to break the rules. For the record I’m going with the first entry in this definition of discipline, namely training to act in accordance with rules; drill: military discipline..

Then Andrew’s last paragraph reads like this:

I have found the adaptability of Agile and the disciplines of XP (test driven design, continuous integration, relentless refactoring, early and often delivery of working code) to be a much more satisfying solution for effective software development. And so have my customers.

So which is it? Is Agile disciplined or adaptable? To my mind, these two terms are contradictory. Maybe he ment you can be disciplined in your adaptability with Agile, but it is unclear. In any case, this kind of ambiguity is my main problem with Agile. Who the heck knows what it means anymore? There are so many definitions and so many people claiming to be Agile, that, like I’ve said before, the term is starting to get ambiguous at best, and meaningless at worst. If people just focused on “being agile” instead of “doing Agile” we’d have a lot less confusion.

Mike has a good post on cowpaths. He talks about how roads into Dallas/Ft.Worth were created along the lines the cows used to walk a hundred years ago. Therefore the roads are curvy and generally inefficient. Then he relates it very well to IT projects. The message is, on new projects (or any project for that matter), question how and why things are being done. Are they being done solely because that is the way it has always been done or is there a reason? And even if there used to be a good reason for doing something a certain way, is that reason still valid?

To quote Vincenzo Galilei:

It appears to me that they who in proof of any assertion rely simply on the weight of authority, without adducing any argument in support of it, act very absurdly.

Remember, authority isn’t necessarily based in company or social hierachies. History, peer pressure, and ignorance can all be “authorities” on which poor processes are continual employed without anyone stopping to wonder why something is being done.

The fact that I can’t figure out what the heck the Agile Manifesto signers believe as a group is telling. Some say Agile is a marketing term while others are saying stuff that I completely agree with and sounds more like PSD, or what I thought Agile was originally all about. Here’s another quote from a recent interview with Ward Cunningham that gives me hope.

It is very important as a professional to be able to observe and absorb technique from peers. An amateur can say, “I only do things my way.” A professional must be able to say, “Let’s try your way for a while and see what happens.”

I’m still confused why the Agile folks can’t seem to agree with each other though.

Daniel Read has a good post about the benefits of developers being open to new suggestions and directions from other people. These people can be on your team or other teams. They can be gurus in the industry or complete strangers who believe they’ve had success with a project. Being closed leads to stagnation. If you never evaluate new ideas within your context, you may miss some great oportunities to improve, or at the very least miss the opportunity to justify and tweak what you are doing now. Listen to what other people have to say and see if what their experiences have taught them can lead to better software development for you.

From the post:

On a software project, if a team member says, “Hey I have an idea! What if we did our logging this way instead?” and your default answer is, “We don’t have time for that right now.” then opportunity is lost, and over time enough of this will grind down the morale of the team.

This is especially true if the developer(s) are unhappy with how things are being done and there are people (managers or not) standing in the way of changing things. “We don’t have time for this right now.” is a giant red flag for me.

Of course, to be completely pliant you should also be open to dropping ideas on the floor that turn out not to be beneficial for you, or that the cost-benefit analysis doesn’t justify implementing. Just because someone (who presumably had succcess) said to do something, that doesn’t mean you should do it. It does mean you should likely listen to them, learn from what they’ve done and see if the ideas can be applied to your situation.

I posted a link to James Bach’s great rant on best practices a while back. Here’s a reiteration of the same thought from Jason Yip.

Okay everyone … all together now …. and this time with feeling …

There is no such thing as a best practice for all contexts.

After seeing AgileDraw, Lidor has come up with some more ways we can hype Agile and profit from it.