Friday, March 14, 2014

Agile is dead...but roundup lives.

It has been a bit of a break for the Roundup, but its back. There has been a lot of action in the blogosphere and a lot of it has prompted personal reflection and change. Change based on what we have learned, that is how we know we are agile, right? Hoping to add a more personal reflection piece to this blog going forward. We will still review the best and brightest agile-related content out there, just with a little more of personal insights thrown in. Her we go...

Agile Is Dead(Long Live Agility)
Summary -
Dave Thomas, one of the originals, who drafted the agile manifesto, expresses his dissatisfaction with the direction that Agile has taken over the past decade or so. Dave puts in words what we practitioners feel every day - Agile "rules" are dumb if followed blindly and dogmatically. Agility is the essence of the agile principles not the mindless following of "best practices". Use Agile as an adjective not a label. This is not about implementing processes that profess to be the embodiment of Agile but to be truly embedded in the concept of Agility. To do what suits best to move closer to your goals and use the lessons and the understanding gathered to correct your path toward your goal. Do not use practices as a benchmark for agile, but use true agility as your guide. If you have any doubts about whether you are "Doing Agile Right" or not, read this. This is the most important blog post that has shown up of late in the agile world in my opinion.
Favourite Snippet -
That’s just plain wrong. “Do Agile Right” and “Agile for Dummies” are just two of the innumerable attacks on the English language featuring the word. They are meaningless. Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”
Summary -
Jeff Archibald, founder of PaperLeaf, writes about Overworking. This one also hits home. As a developer, I have done this multiple times in the past. Even as a Scrum Master, Agile Coach or Team Lead, I have done this many many times and know what it means. Archibald admits to this as well and reiterates how this is a sign of a broken system. He also introduced me to the term - humblebrag, which is a very apt term for the phenomena. Archibald recognizes this as a sign of you being a bottleneck or not delegating enough and "trying to be too many things". Archibald does allow for this on occasion, but recognizes that if this is a usual thing, something is broken in the system.
Favourite Snippet -
We need to stop being proud of overworking ourselves. It’s unhealthy, it stunts the growth of the business, and it’s unsustainable. Instead, we should be proud of creating or working in an environment that is efficient, organized, and diligent enough to allow people to work regular hours on meaningful work.

Mob Programming
Summary - 
Scott Manson(self professed "Power ballad aficionado"), writes in his February post about Mob Programming. This is basically code review on steroids. Gather every developer from your team together, select a piece of code to review/refactor and have the entire team provide input on the refactoring. One monitor, one keyboard, one machine. On the face, the practice looks like the edge of chaos, Manson finds the first foray for his team enjoyable. It seems that the more experienced members of the team dominated proceedings. Manson's proposed solution to this is having all team members spend equal time on the keyboard taking the lead in expressing their ideas. Having lived in the world of Pair programming for the last year or so, this seems to be a great exercise for spreading knowledge and best practices within the team.
Favourite Snippet -
The main aim of these sessions is to learn collaboratively, so we want to encourage everybody to get involved.

Personal Reflection
Thomas's post is a breath of fresh air. It reconfirms for me some concepts that I have had in my head that have been battling with some "proven" agile practices. The team should be free to exhibit agility the way they feel is best. The team should also guard against using this as a license to abandon agility. Abandoning agile is not the same as abandoning agility. Archibald's post also hits home. It is not just the humblebrag, but actually the personal satisfaction one derives from doing the best(or most) for the team. It is not healthy for the individual, the team or the system as a whole for team members to be continually working 60 hr weeks.

Special Interest
To commemorate pi day here are 17 equations that change the world by Ian Stewart -
tumblr_n2c8noLd1q1qzy0ygo1_1280.jpg (599×784)


  1. Nice post - it is amazing how many times I have discussed with people that a 60-80 hour work week is not something to brag about and instead is an organization level failure. Obviously there are many causes - lack of resources, poorly defined deadlines - but the real root cause is all to often poor planning at the beginning that led to a need for heroics.

    1. One of the major issues I have seen is cultural. The organization rewards the 80 hour work week and it is widely accepted as a mark of a great employee. If the harmful behaviour is incentivized, the team members will obviously follow the incentive.