#howtobeagile

[projectmanagertemplate]

How Do I Become More Agile?

Becoming more Agile requires a Mindset Shift. Whether you're a team lead, project manager, or executive, learning how to become more agile i

[standardpixel-blog-blog-blog]

Human scale Agile

Canal at dusk by Jorge Lascar, on Flickr

One of my favorite books in the past few years is "Bicycle Diaries" by David Byrne of the Talking Heads. He shares stories of his experiences exploring cities around the world by bike. Obviously his music career brought him to cities large and small all over the world. Some of his favorite cities were ones he described as "human scale", a term used by architect Jan Gehl in his book "Cities for People ". Parts of San Francisco fall into this category. Byrne mentions cities like Valencia, California (a Los Angeles suburb) which he did not like because the town was too spread out with very few things close enough to be walkable. We like to live in places that are approachable. We like to live in places which give us space to interact and play, as well as do the practical things we need to do. Our work is no different. 

I have been working with one agile process or an other for over seven years. I have tried more than a few flavors of agile and more than a few tools meant to make the whole process easier to adopt. Funny thing is that there were only two times in the last seven years where agile has actually done what it set out to do; make my life easier. Both of these times I was on a team who was learning agile from scratch and was light on tools and process. Where it has not worked is where it had become something which tries to solve so many problems that the process became unapproachable for the people who use it every day. The process did not stay out of the way and make things organized, it became a big giant burden.

Sprawling agile

A lot of the time an Agile process is prescribed to us in full by a consultant or co-worker who's job it is to dream up a process at scale. Their prescription is handed to us with tools and tenets and we are told it is all we need to succeed. In actuality, the tools didn’t fit our need exactly and there were parts of the process which just didn’t make sense to the team. We found ourselves doing things we didn’t need to do for the sake of the process. This is because scaling became the goal, not the daily needs of the people using it. Just like how a multi-level highway interchange improves the over-all flow of traffic through a city, it is far less effective and ascetically pleasing to locals trying to get from point a to point b.

As an example, an employer of mine decided to use an over-customized instance of the Bugzilla issue tracking system. At some point somebody thought that it would be great if each user story on the scrum board or kan ban board could also be a ticket in our developer ticketing system. This ticketing system also has hooks into our source control system so for each story we would be able to see all of the people assigned and even the commits which are being made. Since a lot of corporate dashboards and tools had already been built around Bugzilla, only the product teams would need to worry about the agile process and the rest of the company can hum along as usual. This sounds like a nice feature until you list the things it prevented. First, this function of the tool was obviously designed by developers. Though often the largest group in the team they are not the only ones. What this did was make the tool uninviting to product managers and designers (to be honest, developers weren't crazy about the design either). Non-developers did not need to use bugzilla on a daily basis and these features were not added to it in the most elegant way. This tool also took a lot of the process of updating status and buried it several levels deep in a complicated web interface. I remember somebody on my team looking at this tool and saying, "god I hate this agile nonsense".

The street and the square

Jan Gehl describes good cities being built around streets and squares. Streets are what people use to get places and squares are where people meet. This meets the goal of a city which is to give people a place to live, work, and come together. The goals of an agile process should be to instrument the team so that progress and workload can be measured from day to day. It should also help organize work and scope so that the most important things get done first.

The most successful agile processes I have seen keep the status as publicly visible as possible. A physical board with cards and online tools like Trello and Basecamp can all be used for this purpose. Choose the right one for your team and don't be afraid to change them from sprint to sprint before deciding which one is right. Changing the tool people look at every day to some nicely designed alternative might actually be refreshing.

Think of the daily standup meeting as your square, it should be inviting for those who need to meet and interact but not get in the way of the function of getting where you need to go. The board is the street where you actually get from place to place every day. Keep traffic moving by removing roadblocks quickly.