« Nerdy Cute Girls. In T-Shirts| Main | Back to the Darkness »

Why Agile Teams Win in the Marketplace

| | Comments (0)

This post is about true Agile/Lean thinking. If parts of it disagree with your particular opinion of doing things, no criticism is intended.

  • Agile is Applied Science. As opposed to most all other systems of developing technology, Agile makes no assumptions about what will work or won't work in a particular team or situation. Yes, there are tons of best practices out there, but at the end of the day it's just a team looking at data, forming hypotheses, creating business value, then validating or disproving the hypotheses. New teams "get this" and will immediately ask me "How about we just skip stand-ups? We're all in the same building anyway." To which I usually tell them something about trying the best practice for a while until they understand and know it, then change it up however they like in order to optimize.

    As an outsider, you note some interesting things about teams while watching them optimize that's not immediately apparent to the people inside the team. There is a huge aspect of psychology and sociology at work in technology teams that the teams themselves do not see. Kind of like how a fish is unaware it is swimming in water. Many times they will try something they don't like, say pair programming, and see an immediate improvement in productivity. In addition, the developers are more happy. But -- and this is really strange -- if you ask these same guys if they like pair programming some of them will tell you no. Their preconceived notions get in the way of observing reality. When I first saw this I thought it was just individuals acting irrationally, but after watching dozens of teams (and seeing it in myself) I've concluded this is just part of the human condition.

    This has some interesting implications in how teams make decisions. The ultimate arbiter, of course, is whether or not you consistently meet your sprint goals. But "meeting goals" and "continuing to improve" are two different things, and if you're not improving, in my book, you're not agile. Some folks will want to only use data-based decision-making processes. Some folks are much more loosey-goosey. Whatever you do, have an objective baseline, try something for long enough to really grok it, then take a hard look at whether it works or not. Remember the beauty of small teams is that you cognitively cover for each other, so you might think something sucked or had no impact while somebody else has the complete opposite opinion. Learn to be open-minded.

    At the end of the day, however, it's all Popper and Peirce. Look at data, form possible hypotheses, test, adapt. Good agile has a lot of the same attributes as good paradigm-breaking science and bad agile has a lot of the same attributes as bad science. If you've got the easy-going MythBusters attitude about seeing where things lead you, you'll go far. If you're rigid and inflexible -- even if you are a huge agile fan -- you won't.

  • In Agile the People go to the Work, not the Work to the People. In traditional management, work is broken down from really big pieces into smaller and smaller pieces until each person has a tiny bit of work to work on each hour. People who are not working are failures in this breakdown system, and "management" is the process of keeping everybody busy.

    In agile, I get to the User Story or Backlog Item level and I have reached the quantum of business value. As a management outsider, I should only be concerned with how fast the stories move across the task wall -- it is the ultimate indicator of team productivity. I have to have the faith -- or at least the common sense -- to know that how it all happens inside the team is not something that I'm really qualified to act on. Could be they have trained monkeys doing the work. Could be they all take Fridays off. However it's happening, if my team is delivering business value in a manner that's tremendously effective, leave them the heck alone. If they're not, give them some time to make sure they are not improving, then fire them. But whatever you do, don't micromanage. It's a funny thing: people usually know how to do their job, but if you start telling them, they are more than happy to let you tell them exactly what to do. You've just removed all accountability from the system.

  • Agile has no Standards Organization. I can buy a book on Agile Pizza-Making, and that's a good thing. Readers of agile literature are expected to compare notes and reconcile it with the things they already know. There is no magic person or group of experts deciding what's agile or what's not agile (although many of them would like to!)

    Ten years from now I would expect agile best practices for many items to look much different than they do today. In my opinion, the word "agile" is a marketing term for best practices around iterative and incremental development, and I'm okay with that. The other guys can keep the certifications and the One True Way. I just want a buzzword to identify ideas I might find useful.

  • Agile is all About the Team and the Iteration. I've got a chunk of work and a chunk of time. Somebody thought this work was useful to somebody, and the team thought we could make it all happen in the time provided. Let's go make that happen. it's such a simple concept, yet it has profound implications on how things in a team work.

    In big organizations we might have a PM or a PO who helps us decide what has business value, but the idea is, really, to use the person who actually has money: the customer. Here's a guy who needs something, here's some people that can make it happen. Everybody wins.

    Note that there are not a lot of levels or processes between the guys who can make something happen and the guys wanting something done. In fact, the simpler the better. This tracks very, very closely with the golden rule of startups "stay close to the customer" In agile, the closer you are the better it works.

As I understand it, there is a whole effort to create a fusion between startup methodologies and agile/lean ones. But I'm not sure "fusion" is the right word. In my mind, startup systems are really all about a superset of agile -- finding iterative incremental projects that have value in the marketplace and how to construct them. I think if anything all of this work is simply underlining to people who either don't know agile or don't know startups that the two have always been in sync.

Agile teams will always win in the marketplace because agile teams always focus on the marketplace and delivering value to it. Other systems focus on other things -- including the system itself. Agile is fuzzy enough to not lead to doctrine wars yet specific enough to give teams useful help in making things happen faster.

Leave a comment

About this Entry

This page contains a single entry by DanielBMarkham published on June 4, 2010 1:44 PM.

Nerdy Cute Girls. In T-Shirts was the previous entry in this blog.

Back to the Darkness is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Social Widgets

Share Bookmark this on Delicious

Information you might find handy
(other sites I have worked on)

Recently I created a list of books that hackers recommend to each other -- what are the books super hackers use to help guide them form their own startups and make millions? hn-books might be a site you'd like to check out.
On the low-end of the spectrum, I realized that a lot of people have problems logging into Facebook, of all things. So I created a micro-site to help folks learn how to log-in correctly, and to share various funny pictures and such that folks might like to share with their friends. It's called (appropriately enough) facebook login help