Is Your Team Agile?

I mean, does your team Do Agile?

The problem (as it often is) is with the question. Agile isn’t a thing your team can be or not be. It’s not even really a thing you can do or not do. Agile is a continuum of habits that your team is in that lead it to levels of delivering more valuable software.

Per the observations of Diana Larsen and James Shore, Agile teams in the real world evolve along a path, rather than just waking up one day and binarily deciding to “do Agile now”. There are four signposts (denoted by star ratings) of Agile fluency that they have identified along this path:

  • Creating business value, not just code (★). Teams at this level define the work in user stories, work in iterations, scrum daily to stay in sync, and review their progress at the end of each iteration to tune things and determine what to do next. This high frequency of communication ensures that the team isn’t building the wrong thing.
  • Delivering on the Market’s Cadence (★★). The two-star team practices continuous integration and test-driven development to ship new versions of their software as early and often as the market will accept it. Keeping the code in a consistently shippable state reveals defects early, keeps technical debt low, and keeps team morale high.
  • Optimizing the Team’s Value (★★★). Teams at this level have worked the first two levels enough to have acquired a bond of trust with the rest of their ecosystem–their expertise speaks for itself and allows collaboration and decision-making to be accelerated, and these rituals become more of a formality than a necessity for delivering great software.
  • Optimizing the Organization’s Value (★★★★). A four-star team sees its work in the context of the whole organization and optimizes not only for its own success, but for the success of other teams and the organization as a whole. This sounds like an adorable mission statement that gets posted in the break room just above the extra water cooler jugs, but the reality of achieving this actually involves a fluency of communication and trust among teams that your company probably really doesn’t have yet. Because this is hard and requires emotional labor and guts from everyone in the building.

I digress. So, here’s a handy graphical representation of said star-laden path that you can perhaps post next to that heartfelt mission statement.

And here’s the thing that Larsen and Shore don’t want you to miss about their star-rating system.

More stars generally indicate that more value is being delivered at that level. BUT. Any of the stops along the way may be enough Agile for what your team is actually after at the end of the day. This is handy to remember when you’re struggling to breathe from under the crushing weight of the things about your work which you cannot control–it’s better to adopt a few killer practices on a small scale than to reject Agile methodology wholesale on account of Fred in Marketing says we’ve always done it this other way.

When someone at the meeting table declares “we are Agile now” or “we do Agile”, red flags should go up. Literally, if you like. If that makes everyone else in the room chortle enough to get how silly that is.

The real world is made of people who are not on your team (let alone in your company), and they don’t so much care about the baller new process template that’s really helping you value-add and synergize verticals. Think more in terms of “here are some habits we are in” and “here are some other habits we could take on if we need to do better” when you want your team to use “Agile” to do work that makes an impact and a difference.

Agile 2012 – Diana Larsen and James Shore – Agile Fluency [ Agile Toolkit Podcast ]

Your Path through Agile Fluency [ Martin Fowler ]

What Does The Emotiv Headset Mean for the Future of UX Design?

The Emotiv EPOC Headset is a spidery-looking bit of headgear that translates electrical impulses from your brain, head movements and facial expressions into digital input. And, as discussed in depth here, it has a .NET API.

For serious. They have an API for your thoughts now.

Setting aside the obvious implications for gamers and people with disabilities (and, I guess, gamers with disabilities), what could this sort of device mean for the future of business applications?

Last year, Siri delivered a serious upgrade in human-machine interaction to the masses (at least, those masses who could swing an iPhone 4S in this economy). Android is still flailing to match it. Even the latest version of Windows bothers with the mouse and keyboard only under the heading of backward compatibility.

Tomorrow’s more successful nerds will need to learn to see around the ways in which the traditional KVM interface to software has blocked in our thinking. What will be possible and probable when you can regularly expect to speak and think at your applications? What will the screen look like?

Consider that it’s the thrilling year 2012 now, and we are still making plenty of audio-only telephone calls. That’s not because the technology for video phones isn’t there. The ubiquitous Videophone never happened because the use case was fiction—a real telephone conversation involves walking, driving, or just not necessarily being presentable or stationary in any way.

So, maybe we only bother with the screen under the heading of backward compatibility.

Maybe the new interface is that would-you-like-fries-with-that sort of headset, with the occasional display available when needed. Maybe the fact that I’m picturing a headset at all is paleofuture, and rooms will just come standard with transducers for your innermost twitches and ideas. Creepy.

Anyway. Back to mind controlling your software. Here’s where you can check out the Emotiv development experience for free, complete with a software emulator for the headset.

It Makes One of These Out of U and I

While I was taking in a recent episode of Dot Net Rocks (the one covering the new LightSwitch rapid development platform), co-host Richard Campbell said something in passing that caught my ear. He described a hypothetical enterprise development scenario in which the “senior guys are building a set of WCF services that the, um, client-building guys can access”.

I batted an eye. Why are we assuming that our senior developers should be focused on the server side code?

This is no slight to Campbell, of course—he probably meant nothing by it at all, good-natured Canadian citizen that he is. But it called to mind tales I had heard before of concerns being separated across a team in this way. The more experienced members of the development staff get assigned the IMPORTANT BACK-END WORK, while they let the new kid, y’know, bring up some screens.

Sure, the nether-layers of your stack contain critical elements that must be tightly engineered for performance and accuracy. There is little value in a brilliantly laid-out page on a website that can’t perform, or in a screen that renders the wrong answers in a gorgeous typeface.

But is this really a working model for a team shipping successful software? Can we afford to regard an application’s User Experience as a foregone conclusion, or to pretend that the real art to be created is in the logic and plumbing of the application?

In the age of jQuery, WPF/Silverlight, and the iPad, our users are expecting a friendlier and more compelling experience from their software every day. Is the server really the place that a seasoned application developer can provide the most value? Would their skill and experience not be better put to use connecting meaningful information with the human being on the other side of the screen?