Monthly Archives: March 2014

Taking Agile Back

I’ve seen some noise lately that appears to have started gaining momentum in February. It seems like it is still low on the signal to noise ratio, but it is a strong signal. It is starting to be pushed by thought leaders in Agile. Even some that have effectively been involved with Agile since before the manifesto. It has not yet reached critical mass, but I think it could.

I was not part of the early days of Agile. While the basics of Agile make just as much sense to me as to everyone else I was not involved in software development and project work until around 6 years ago. Before that I was CIT.

For the few projects we were part of back then we had smaller support roles. They were generally for setting up specific hardware/software and not conducive to Agile methods and practices. In retrospect we ran our team in a matter similar to Kanban, but without any formal process guidelines or documentation. Of course, even back then I was experimenting with improving our process through ticketing systems, deployment tools, and remote assistance – but I digress.

Since joining the Software development world 6 years ago the team I have been on has always been responsive to our customer. We have generally had a fast feedback loop for addressing problems and providing improved functionality. We have been able to work directly with key stakeholders. We have dabbled in improving our process as allowed by the organization.

We have not subscribed to a particular Agile methodology and forced it upon ourselves. We have not conformed to match what a consultant told us was the right way to do Agile. We haven’t, until the last year, even used the word Agile to describe what we do or how we do it.

In that context I may not look like the ideal candidate to be part of a movement about taking Agile back to the ideal that was imagined by some 13 years ago. That may be true, but taking Agile back isn’t just about the past. It’s about the future. I have immersed myself in Agile for a little over a year now. While I may not be a good representative of the past intent, I am part of the future. I may not be one to explain what Agile was supposed to be, but I am here to help shape what it could become. I am part of the movement to take agile back.

Read more at the following links:

Tim Ottinger
On http://notivago.org/
Curtis Cooley
Twitter
Google+

I’ve also written about similar problems before. My Agile is not Scrum post is probably the best example right now. I am also working on a series of posts I’m calling Back to the Basics which I hope will stick to the proper spirit.

Do you feel the current state of Agile is where it should be? Should we be working to “take it back?” How about “move it forward?”

Back to the Basics: Tensions to Manage

Before getting into the main value sets of the manifesto I wanted to take a moment and cover an important line that still manages to get overlooked by some.

That is, while there is value in the items on the right, we value the items on the left more.”
– Agile Manifesto

This line resonates with one of the biggest takeaways I have had from Andy Stanley’s free monthly leadership podcast. The concept is one of a problem to solve versus a tension to manage. Continue reading

The Project Manager and Scrum

Most Agile Journeys begin with Scrum. As I was reading through a blog post over at agileheads it occurred to me that what to do with the Project Manager is perhaps the biggest mystery in Scrum.

Think of it. A classic project team goes to Scrum training together. The Project Manager, the developers, the testers, the analysts. Perhaps there’s even a customer representative that goes, or someone from sales. Out from the training should emerge a Scrum Team, (Product Owner, Scrum Master, Developers) and Stakeholders. In this case “Developers” are not equal to “developers” – but we’ll look at that another day. There is no PM in that list. No “boss”. So what happened? Does the PM stay in the training room forever? Did they sneak out the back – no longer part of the team? Continue reading

Estimation is Dead, Long Live Estimation!

Image courtesy of Graeme Weatherston / FreeDigitalPhotos.net.

Image courtesy of Graeme Weatherston / FreeDigitalPhotos.net.

Estimates are kind of a big deal. I’ve written about them before. (See here.) Last year was a big one for the idea of completely dropping estimation in the greater software development community. In July the twitter account @NoEstimates was taken on as an outlet for Woody Zuill specifically for sparking discussion on this idea. Ask any person in software development what they think of estimation and they’ll share their opinion with you. Mention the idea of not doing any estimation and it could get heated.

The “No Estimates” crowd has some good points. However I believe all out “No Estimation” is gouging out an eye to spite the face. What I feel the right answer is, and the one I have seen from various thought leaders this year, is “Valuable Estimates Only!” It just doesn’t roll of the tongue as well. Continue reading