Collaboration OVER Documentation...

Triggered by this good post by Fabien at the Server-Side Pad...

Folks... the Agile Manifesto does NOT say that we should throw documentation out the window.
Similarly, it does NOT say that collaboration REPLACES documentation.

Fabien's points are important since both of these misconceptions are common in newly transitioned agile environments. Teams seem to forget that anyone on their team can be pulled off at any moment and replaced with someone else. If enough of this happens, then their tests, code, and DOCUMENTATION are the only thing left after they are gone.

Part of my comment left on Fabien's post:

The manifesto clearly states that documentation is valued, but conversation is valued more. (Hence your important qualifier is already built in, people just overlook it!) What they were really trying to combat was the old-school philosophy of writing a set of requirements, believing it was done and pitching it. This lack of review and collaborative thought always led to a breakdown and finger pointing somewhere later in the process.

UX and Agile (part 2)...

One of my highest visited posts is the one I wrote about usability. I've since added updates to direct people to other ideas. Sometimes I feel like I should write more on this topic because there is a large void on it within the agile community, and I spent more than five years focused on it. But the reality is that I have been focused on process, PM, agile for the last 4 years now. Usability is like SEO, you need to be living it today to be an authority. My history in it allows me to carry good conversations, but I'm not going to pretend I'm still an expert.

With that lengthy, wordy introduction... here is a good second part about usability in agile. I just happen to not be the one who wrote it.

70% accuracy + Speed is better than perfect...

Artemgy has an interesting post about agile decision making.

"...it is important to make the right decision… …or is it?
Not according to Percy Barnevik’s “7-3 formula”! The man who ran Swiss engineering giant ABB for a decade insists that you can still be successful if you make nearly half as many wrong decisions as you make right decisions!"

I think a big part of embracing agile is understanding the fail quickly mantra. You have to accept the boundaries of your day, iteration, and release and use them to force forward progress instead of falling into an analysis paralysis state. This is a by-product of all the feedback loops found in agile (pick your agile denomination). It's okay to make bad decisions sometimes if you can recover quickly.

The more transparently you can do this, the more trust you build with your customers and users that you will always do the right thing for them in the long run. This creates loyal followers.

UX and Agile, how do they mix?

So there has been some discussion lately about usability and agile, and whether the two work well together. Alan Cooper's keynote at Agile 2008 was a rally for the agile community at large to start folding in the UX role and taking advantage of it. I spent 7 years in the usability field, and hearing him speak on this almost made me want to get back into it. This topic has also come up recently in LinkedIn group discussions and also with Mike Cottmeyer at VersionOne.

I commented to Mike's blog post about Agile and UI Design with this summary: "Agile engineering practices (especially TDD) are supposed to reduce the time between writing code and finding functional bugs. User experience skills are supposed to reduce the time between writing the code and finding usability bugs..."

Something we have to recognize is that user experience is a greatly misunderstood and undervalued field. Like Agile, UX folks have been struggling for a few years (since the '70s in software) to get the masses to understand the need for a user advocate and user modeling. Agile has started to push the concept of getting close to the customer, but some people think that this is enough to bridge the void when in fact it is not.

If you are working on a simple commercial website, then there is a good chance that you can be a follower of others and simply borrow from the best. This assumes that your leaders either lead because they have the most usable product, or because they spent a lot of money on usability studies.

If you are working on a true application, say an operating room management system (something I did for 4 years), you have a different view to usability. It is one where a system can functionally do exactly what it should, but a human might make an error using the software that can lead to a patient death. A decimal point error in medication dosage can equal death. A unit of measure error can equal patient death. This is a place where usability is imperative to the process. Most systems/projects fall somewhere in between these two points and usability is a differentiator and an added value, but not necessarily a requirement for entry.

UX folks are experts at understanding what the user can't understand themselves. Just like agile teams are taught that customers can't explain all the requirements up front, UX folks know that users can't understand how the screens should look/work. But there are scientific ways to figure this out by working with and observing users. Remember that the "customer" might be the head of the OR in a hospital making the decision to buy your software, but they won't be using your system like the nurses and surgeons directly in the OR. The UX person quickly realizes that the colors on the screen need to be changed for the lighting in the OR, even if during the sales demo they look ridiculous. UX is about uncovering user behaviors that aren't obvious to the developers, product owner, or even user themselves.

Can these folks fit into an agile team? Definitely. They are kind of like an SEO expert that reviews everything going out the door and mentors the team on certain standards and consistencies that need to be met. They are also like the lead architect that needs to look across the backlog and start creating a high level plan for system flow and structure. They can't just whip out screens on the first day of the sprint and reach perfection. UX sometimes requires focus groups and real user testing (think one-way mirrors and mouse recording). These are the sessions where the size and color of a button can be changed slightly to reduce error and increase efficiency.

My summary is this: there's a lot of gray area today on how much up-front design should be done on an agile project. I believe that same issue will arise with UX resources. UX people are going to struggle to fit in the agile culture because of the nature of their role and difference in speed between the agile team velocity and the delay of setting up controlled user tests. But, they will figure this out over time. It's more important to involve them early and let them see as much as they can so they can start adding value.

Update (11/26): Here's a great example of what usability can add to the process. Here's a great example of specific tasks the usability role can add value to.

Ambler rocks...

He's an industry leader. In my limited experience, there is very little I can add to this. I can't say it any better. I can only sit at the back of the room and look at everyone else to see if they are getting it as clearly as I am.

For those of you who haven't seen his work before, here are my favorite excerpts to entice you to read the full article:

Starting a project- "You don't need anywhere near the level of documentation, or detail for that matter, that you've been led to believe over the years. For example, although you'll likely be asked for an initial estimate, you don't need to spend weeks or months doing detailed requirements, analysis, and design so that you have the input into some form of complicated estimating process. A ballpark estimate will often do, and frankly it is just as accurate as anything you'd produce counting function points or following COCOMO II."

Should you do a project? "An important consideration during Cycle 0 is the economic, technical, operational, and political feasibility of the project. So we ask ourselves if the system will pay for itself; if you have the ability to build the system (or to manage the project if you're outsourcing the effort); if you can keep the system running once it's built; and whether your organization can tolerate the successful delivery of this system."

Cost? Deal with it- "Agile or not, someone is going to ask the questions: "How much is this going to cost?", "How long is this going to take?", and "What am I going to get?". The real answers, respectively, are "As much as you're willing to spend," "As long as it takes," and "Whatever you tell us that you want," but few organizations are willing to tolerate this level of honesty and instead ask for "exact" answers. Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy to show for it. I believe that it is time to admit that we can't predict the future accurately and cast off the shackles of traditional thinking."

Business Analysts have to stick around now...

Karmark96 is a budding business analyst in a company starting to borrow practices from Agile. He was surprised that his new role follows the product life past definition and through testing and support.

I explained how this was true while at Siemens after going agile also. My nugget:
"Before we went agile, the BA would write documents and then dump it on the dev and test teams to deliver and fix. In this scenario, a lot of flaws were found in the requirements and the BA could be long gone onto the next project. Agile was about removing this waterfall and bringing these timelines together."

The Boundaries of a Sprint...

How do non-developers get involved in the iteration rhythm? How does a business or UI person have all the answers on the first day of the sprint when developers need them? This is a great problem and people learning scrum seem to evolve through different levels over time.

This was the point to Karl Scotland's MMF post, and he did a great job of modeling it for easy digestion.

I commented on the sprint boundaries in general and my experiences through this process in other teams and how it was predicted by our agile coaches at the time.