A lot of people think Agile is about working faster, but that really isn’t right. It would be more accurate – and perhaps alleviate many of the arguments against agile practices – if we thought of agile as being about working slower because we’re being more deliberate. BUT, at the same time getting rid of all the crap that doesn’t add value, so that we do, indeed, end up delivering more functionality in a shorter period of time.

I like to think of Agile as the Just Do It methodology. In software development, we’re really great at this thing called “yak shaving.” If you’re not familiar with the term then take a moment to read: So There I Am, Shaving a Yak…. Go ahead, I’ll wait. It’s really funny, I promise.

“So there I was at the zoo, shaving a yak, all so I could take a few pictures of my dogs at the park.” – Bill Gaiennie

A really huge part of yak shaving – at least for me – is trying to figure everything out so that I can make sure I’m going about things the right way. Oh boy, I can plan and research and do proof of concepts like nobody’s business. But at the end of the day, I’ve got a bunch of “stuff” with no actual working software for the app I’m supposed to be building.

Agile instead says “You’re never going to know everything about the app until it’s already been written. Cope.” and instead gives us tools to continue to move forward by focusing on what we do know. And then, a funny thing happens. The more of the application that we build, the more we learn. And so, we’re able to move forward, not by focusing our time on what we don’t know, but rather by focusing on what we do know and building actual value out of it.

Read More…..

A Hacker Chick Guest post by Trudy Prins, a wonderfully passionate software development manager at RIPE NCC in The Netherlands. I asked if she might share what she believes makes a successful software team. I hope you enjoy her answer and this glimpse into how she leads her teams as much as I do…

As a Software Engineering Manager, I believe a successful engineering team is a happy team. Happiness boosts productivity, creates an environment for excellence, and offers fertile ground for growth on both a company and a personal level.

So, what makes a happy team?

Frequent knowledge transfers. Team members should have the opportunity to schedule presentations in front of their peers, engage in discussions, follow trends, try out new solutions, have spikes on all kind of topics, go to conferences together and whatever they find suited to share their knowledge & enthusiasm.

Immediate feedback on their performance. I tell them constantly, clearly, and on the  fly what I think they did good, great, or not good at all, without making a big fuss about it or waiting a year until their performance review is up. Their annual review shouldn’t hold any big surprises.

Read More…..

Goodness on the Internets:

An Open Letter to Micromanagers by Scott Berkun.

“Owners of thoroughbreds never stop their horses during a race, every ten seconds, to remind  the horse and jockey how to run, where the finish line is, or that it’d be a good idea to finish first. Why? It would slow them down. Only an idiot would do this…”

and so begins Scott’s letter to micromanagers everywhere. Complete with a link to anonymously send the letter to your favorite micromanager and signed, Hugs and Kisses, The People You are Micromanaging.  I love this guy.

TDD Triage.  Bob Martin addresses a number of questions around Test-Driven Development, hopefully dispelling some of the  religious extremist views on the topic and showing where TDD works and where it doesn’t. These include:

• Is TDD a replacement for architecture? (Nope)
• Is TDD a replacement for design? (Not even)
• Should TDD be used for every line of code? (Usually, but… actually, no)

How Nonsense Sharpens the Intellect. Alright, this is just awesome and reminiscent of Kathy Sierra’s suggestions to insert a little randomness into what we do. A NY Times article explains the science behind why nonsense and randomness actually help us understand things better. And, with that advice, I’ll end this here.

A lot of people say you can’t be a good software manager without really understanding software development. But, let’s face it, people who understand software development are a dime a dozen in our industry. What we really need are people who understand leadership & management. I mean… you know the drill – when was the last time a software project failed for technical reasons?

And so, it was very cool to hear David Spann share his research on Finding and Developing Agile Leader’s at last week’s ScrumClub.

It’s simply not enough to know the latest agile practices. In order for agile projects to succeed, they need leaders who exhibit agile behaviors and, here’s a hint – being a technical guru ain’t one of them.

Now, I don’t want to mislead – David isn’t saying agile leaders don’t have to know anything about software development. What he is saying is that the success criteria for leading agile teams is dependent on the leader’s beliefs and behaviors. That is, how they think and act is  just as – if not more – important than what they know.

Read More…..