Agile Software Development Experiment


We’re considering trying an experiment in agile software development at Tyner Blain. There aren’t (m)any examples of agile software development that we can watch and study that include agile requirements development. Many people still think that agility and requirements management are mutually exclusive.

If the responses to this post don’t overwhelmingly request that we not do it, we’re going to develop a website/product for Tyner Blain over the next short period of time – and write about it as we go. You’ll see the steps as they happen, watch mistakes and even help fix them. You’ll be able to provide prioritization inputs and feedback as the project evolves.

Read on to find the details of the idea, and how we we’ll approach the project.

Why Say No To An Open Agile Project?

The first question is why you might want to say no. Blogging about this project as it happens means that we won’t be doing the other blog articles while the project is ongoing. There’s a lot of great stuff being written by other people, and we discuss those ideas fairly regularly. We won’t be doing that if we focus on this internal project.

train wreck

This project and product may end up being a big train wreck. That might be a reason you would want to read about it – so feel free to hang out and chime in, even if you’re rooting against us. But it does qualify as a reason for us to not do it.

I almost said no to this idea because its risky. We’re putting a lot of credibility on the line with this exercise. But I said yes because credibility is a big part of what we all risk every day as part of our jobs. If the ideas we believe in are as powerful as we’ve demonstrated them to be in the past, there’s no real risk that they won’t work on this project.

What you do every day is important, and you are important to me. If we’re not willing to “eat out own dogfood” on an internal project, then we really should stop sharing our advice and opinions.

Someone commented on one of our articles a few months ago that my writing sounded like [paraphrasing] a bunch of platitudes by an agile fanboy. Well, this project is definitely not platitudes. It also won’t result in proof that anything we do is good or bad. It will just be anecdotal data.

One person suggested that we just blog about it after we’re done. That’s what a rational company would do. I believe the ideas we discuss and the lessons we learn will be far more compelling if we do it with real-time visibility.

Another argument against developing a product publicly is that “the competition” will be able to steal our ideas and beat us to market. I guess we just have to do it better, do it faster, and have more of your support if that happens. That is a challenge I’m eager to take.

What Types of Articles Will We Have?

In the last section, we mentioned that the “normal” articles on Tyner Blain will be curtailed while we do this project. We’ll still be writing the same general type of articles, but we’ll reference other people’s articles far less if at all. We’ll be focusing our writing on our internal activities of the day on this project.

I expect that the rapid pacing of this small project will make for good articles on a daily basis. If we need to, we’ll do “normal” articles on the days where there’s nothing new to report.

We’ll start this project with goals and a focus on the users. We also have constraints that are placed on the project by Tyner Blain – like selection of a particular technology. From there we’ll work on use cases, prototypes and requirements. We’ll be asking you for feedback on all of this, as well as prioritization inputs. We’ll look at design approaches, interaction design, and usability. We’ll look at object models and some of the implementation details. And we’ll ask for help.

What Kind of Help Can You Give?

The most valuable thing you can do is give feedback, input, and encouragement.

Every article has a section titled “Join the Discussion…” at the bottom of the page. When we ask for feedback, or when you want to contribute (consider this a standing invitation), just comment on the article there. You can now subscribe to comments on any individual article, so if you want to follow the discussion, just check the box when you add your comment.

We’ll use the individual articles both to request help and collect it. Of course you can always send feedback via email (scott at if you don’t want to share with everyone. Either way, thank you in advance!

Who Is This “Product” For?

This is for you and me – all of us. The readers of Tyner Blain are the target “customers” of this new “product.” The product is going to be an extension of the the that will be free to use. Our objective is to have this extension be the first place that you (and we) go to get the best information and read the best articles about our niche.

If you read or write articles about product management, business analysis, requirements, agile development, software product quality, business rules, business process modeling, uml, or any other topic. Everyone who cares about the things that affect the success of the software products we deliver. There may even be enough value in these articles for people who make products that aren’t software.

What Is It?

That’s a bit of trick question. We just spent several paragraphs telling you that you were going to help define what “it” is. Imagine squinting your eyes on a foggy day at dusk – “it” is defined about that much. You’re going to help us open our eyes and clear the fog.

What we end up with may not look at all like what we think we see right now. That’s half the fun!

How Did We Get Here?

Like every good product, this story starts with a user’s pain. This section reads a bit like the elevator scene from Working Girl when Meg Ryan’s character explains how she came up with her product idea…

I find that I spend too much time trying to find good articles in our niche. I can easily spend an hour trying to find a conversation that should be extended on Tyner Blain. And when I’m trying to learn something new in our space, it can be frustrating to scour pages of search results to cobble together the pieces I need to start out. As a consultant, I’m constantly applying what I already know and extending to learn more. The internet is great, in the abstract, for doing this – but it is a lot harder than it needs to be for us.

Last fall we had an article reach the front page of Very exciting stuff, and while it is a good article, I would say two things about it. First, it is not the best article we’ve ever written. Second, it was clearly the most mainstream article we’ve written (Top Ten Tips for Preventing Innovation). Out of ~500 articles, it is the only one that made the front page. is awesome. For some stuff. When I wanted to learn about php or css programming, or a particular hot gadget like an ipod, I could go to digg, and without digging very far, I could find the articles that digg users rated as being “the best.” That made searching awesome. Good articles were promoted, and I didn’t waste time on bad articles.

The problem is that our niche does not have enough critical mass at to make the system work for the articles that we care about.

We need a better way to find great articles about the stuff we do.

Sandy Kemsley writes Column2, a great blog about business process modeling. She used to have a feature where her tags would get automatically published to her blog. I loved it. Sandy turned that feature off becuase he blog has a tighter focus than she does. She felt that her readers were being forced to read about other things that were interesting to her, but off-topic for her blog.

There are a few people who regularly send me suggestions on articles to read or write about, or just send me pointers to good articles in our space. That’s awesome. But I wouldn’t get those emails if we didn’t have a popular blog. And it doesn’t scale – unless they send that email to everyone they know who might be interested.

We need a way to tell other people in our niche which articles we think are awesome, on a scale larger than we can achieve with a handful of active blogs in our niche.

Some really good writers in our niche have stopped blogging, or write less, possibly because they don’t have the audience they deserve. I’m sure we all have at least one in mind. When they write a great article, we need a way to tell other people about it. And while a link from a blog is nice, it only represents one opinion. If 50 of us like an article, we need to be able to tell people that 50 of us liked it, so that author can get the recognition they deserve.

We need a way to help the great writers and thought leaders to get the attention they deserve.


In a nutshell, we’re going to create a software / website solution to the above problems. We’ll go into more detail in the next article about goals, and start asking for feedback publicly from everyone who wants to participate.

We’ve had this conversation with a few other people offline already yesterday and today. Tomorrow we’ll start doing it on a larger scale.

So – what do you think?…

9 thoughts on “Agile Software Development Experiment

  1. Great idea!
    It would be perfect if you could publish the documents you create along the project. A lot of people tend to think that agile means almost no documents, and an example of documents used during an agile process would help a lot.

    Looking forward to see your next post!

  2. I think the major risk in this experiment is that the key to “agile” is not following a process, it’s understanding a mindset. Anyone can have their own implementation of a process that is following the principles of agile, but not necessarily get agreement from anyone else on the details.

    That’s the primary reason for so much confusion on the topic – people are seeking a set of instructions, like a back-of-the-box receipe. Instead, they should be trying to develop knowledge and skills to understand the bigger picture, and become an chef.

    That said, even Emeril Legasse had to start somewhere…so I say, go for it!

Leave a Reply

Your email address will not be published. Required fields are marked *