It’s interesting to me how much people rely on formal tools for modeling. I frequently talk to individuals that tend to assert that just because a model is made in some modeling tool (like Visio) that it is *right* or at least superior to whiteboard sketches.

The Visio fan-boys and fan-girls seem to snicker and generally doubt the effectiveness of a sketch done at a whiteboard. Why is this?

Is it because of the appearance? Is it the lack of gradients? Is it the lack of the drop shadows? Is it the lack of the standard company logo in the upper right-hand corner? Is it because of how straight the lines are?

My view is exactly the opposite. If I had to summarize my stance, I’d say that the straightness of the lines has an inverse effect on the understanding of the problem.

In my experience, most of the models created with modeling-tools are done by one individual. If others collaborate on the model, it’s usually in a serialized fashion. It’s “tossed over the wall” to someone else who follows a similar process. It’s also my experience that many people spend more time worrying about the polish of how the output looks than spending time thinking about what is being modeled.

Contrast this to a whiteboard-session:

When a model is explored on a whiteboard it’s usually done with more than one person. It’s usually done collaboratively with at least two participants, a variety of view-points, and it’s iterated on quickly. Because it’s being done collaboratively, it also frequently results in break-through ideas or understanding.

Unfortunately, the modeling tools also tend to focus our attention on the output, not the creation of the model (where the real learning occurs).

It’s important to remember that the modeling, learning, and understanding is what provides the real value, not the model.

Photo courtesy of Doc Searls.

Something that I’ve noticed more and more lately is an increasing demand for “rules” in applying Agile development. Honestly, this has concerned me for the past couple of years. I always silently gritted my teeth and provided guidance backed up by a lot of “unless” clauses. I’ve usually taught from a “principles-based” approach and encouraged creativity around the principles.

Although I think that I’ve done a solid job in communicating the benefits and application of Agile methods and practices, I also feel like in many ways that I’ve left teams begging for prescriptions, rules, and best-practices. In my mind – those things have always been more problematic than helpful.

On the plane today, I started reading Pragmatic Thinking and Learning by Andy Hunt. By the second chapter, I had that OS!M (oh shit! moment) where a lot of things start to pull together in my mind. This all happened while reading through Andy’s explanation of the Dreyfus Learning Model. Suddenly, a lot of things started to make sense to me from a coaching standpoint.

The Dreyfus Model is a five-stage model that shows how individuals make the progression from Novice to Expert. The Dreyfus Model explains skill acquisition and the related ramifications of how we learn at different stages. This model was originally developed by a couple of brothers that were researching how we learn for some work they were doing around artificial intelligence.

An interesting insight from the Dreyfus Model is that at the Novice stage (the first stage), individuals need recipes. Novices are concerned about their ability to succeed and they don’t have any experience to draw from. Novices aren’t necessarily interested in learning, they simply want to accomplish an immediate goal. They are most effective when they are given the exact instruction of how to proceed. Take out context, take out the edge cases, take out the “it depends” scenarios and that’s what individuals that are new to a concept really care about.

When we move through the stages then context, the edge cases, and the “it depends” scenarios really start to matter and understanding the big picture plays a more relevant role in our learning. This explains a lot of what I have been trying to understand with the desire to have a “one size fits all” or “best-practices” approach to applying agility. In looking back at my own progression, I can see the exact characteristics that are defined in this model.

When I “prescribe” a practice or I provide exact steps for achieving an outcome then I feel like I’ve somehow cheated. This is because I know that there are not any universal truths in how we approach problems with software delivery and with agility. Maybe this feeling that I get should be re-evaluated. Maybe it’s ok to be prescriptive. Maybe it’s ok to provide recipes to new teams. At the very least, this is a great opportunity to re-think my assumptions and my world-view on how to be a great Agile Coach and to spend some time learning more about learning.

I’m looking forward to finishing the book and thinking through the information that Andy has provided in the book so far (I’m only through the first two chapters). It looks like it’s going to be another great release from the Pragmatic Bookshelf.

I just returned from the Seed Conference and all I can say is wow. This was a wonderful, thought-provoking, and inspirational event. If another one comes up, I highly recommend attending.

There was a lot of interesting information that was presented both directly and in-between the lines of the talks. It’s great to see so many inspiring individuals giving talks and hanging out at the conference. There were a ton of fresh ideas and a strong sense of innovation that was felt throughout the day.

Carlos Segura, Jason Fried, Edward Lifson, and Jim Coudal all gave great talks with good content.

If I had to boil it down to a few over-arching themes – the conference was really about truth, happiness, pride, innovation, and getting real.

I also can’t say enough about the location of the event. As someone who sits in a typical office environment most of the week, it was refreshing to be in an environment that encourages learning and has inspiration at every turn. It was also nice to be surrounded by individuals that are pushing the boundaries of our industry and unsatisfied with the status quo.

Over the next week or so, I’ll try to get around to posting some of the notes that I have from the event (1/2 a Moleskine full).

My favorite sessions included:

(Follow the links for the abstracts, presentations, and handouts)

1. Agile Enterprise Rollout–The Greening of the Software Industry (Jean Tabaka, Ryan Martens)
2. The Role of Leadership in Software Development (Mary Poppendieck)
3. Learning Kaizen from Toyota [with MindMaps] (Mary Poppendieck, Kenji Hiranabe)
4. I Don’t Like Mondays – Improving Agile Team Collaboration Events (Jean Tabaka)
5. Reaching New Heights: Learning to Adapt is Essential (Susan Ershler)
6. Agile adoption at Google: Potential and challenges of a true bottom-up organization (Mark Striebeck)
7. The Agile Enterprise: Real World Experience in Creating Agile Companies (Jeff Sutherland)

Some of the big-picture realizations that I came to:

• Mary Poppendieck has turned into the Tom Peters of the software industry (well-deserved).
• Lean thinking has started to move to the center of the agile universe (finally).
• Executable specification / story-driven development is moving to the mainstream (finally).
• Everyone wants to scale agile.
• Everyone wants to distribute agile.

A few things that I’m concerned about:

• Lean has moved to buzzword status. A lot of people are talking about Lean but I don’t think the majority understand the essence behind it. I think this will get better.
• Everyone wants to make “Enterprisey” software with agile teams.
• There are a lot of “agile” consulting firms that are full of shit.

And some other random thoughts…

I think the fact that everyone is focused on “scaling” agility to large teams and distributed projects and that there will be a lot of agile disasters over the next couple of years. Now that the bigger software companies are moving to agile, the teams are getting too big and they are adopting agile in scary ways (too big, too fast). I think that you need to evolve to big teams, not start out there. I would also (passionately) argue that you should focus on how to have smaller software instead of how to scale agile teams to accommodate large software. I seem to be in the minority.

Lastly, I really think that the organizers of the conference need to step it up. The programs sucked (hard to read, hard to navigate, mis-prints, missing pages, etc.), the event was really hard to follow (talk duration, locations, topics), the location of the conference sucked (tight hallways, hard-to-find rooms, etc.), and the beverages and food was awful (a big thank you goes to Rally for providing everyone with bottled water).

I certainly appreciate that everyone worked hard to put this together, but I expect the basics to be nailed for a major conference.

I have a presentation that I can give on this topic, but I’m not sure if I’m going to do it with the slides or not. Regardless, it should be a blast and I’m looking forward to what others have to say about the ideas. I’m also extremely excited to hear the experiences of others and letting others know of the my experiences.

Here is a (compressed) mindmap that I put together regarding my thoughts on the session…

The last I heard, registration is still open and there are already a ton of individuals that have registered to attend.

I don’t have the exact details yet, but I’ll be doing two chalk talks during the event. I’m looking forward to the event and I’m excited to see that the conference is covering some great topics and has the support of so many individuals.

I’ll post more details about my talks later this week as the details are ironed out.

I look foward to seeing everyone there.

In my experience, extensibility is usually the largest risks to a software project because it often results in the largest degree of over-engineering. This usually isn't a popular idea, but I think it's true. There are times when it's warranted and valuable, but the problem is that we tend to always think that it's valuable. We always say things like: "what if", "someday", "it's possible that", "I can imagine a scenario", and so on. These are usually things that should be considered, but not always things that should be developed. In theory, we need to pose these questions to our stakeholders and our stakeholders should be making these decisions (not the development team).

The problem with the theory (allowing the business team to make the decisions) is that they are often caught up in the same vicious cycle of over-engineering our specifications. When I'm handed a large requirements specification document, I know that 25% of it is outdated, 40% of it will never be implemented, and that the real value likely comes from 20% of the requirements. The state of the specification is a result of over-engineering by the stakeholders (and it compounds the issue of over-engineering by the development team).

I don't have a silver bullet to fix the issue, but I believe that we can at least identify the problem and get in the correct mindset of fixing the problem by thinking about how to eliminate waste. Simply considering known value vs. speculative value can go a long way. We should always be thinking about doing less. Less is a powerful idea because of the compounding growth of each additional thing that we choose to do. For every "I can imagine" scenario, we have business costs, development costs, testing costs, and maintenance costs. We also have other costs that we usually don't think about including opportunity costs.

To push the idea further, we should consider the idea of "less" across the spectrum of our activities. One big opportunity comes with documentation. I think that The Elements of Style should be required reading for everyone that contributes to documentation on a project. Our documentation should be concise and avoid all the additional "fluff" that makes up the majority of the large documents that I see on typical projects. Documents should be focused to the point that every word in the document has meaning just as every requirement should be valuable and every bit of software should be testable.

Unfortunately, the idea of more is the norm. The positive side is that we are the problem and we can all take steps to eliminate waste in our day-to-day activities. If we don't do anything else, we should at least consider how the idea of "less" can apply to our projects and our organizations. It's not an overnight change, but it is a valuable exercise in thinking about what really matters.

Ever since I saw the Visibone references (all of which are very good), I have tried to learn new languages taking a test-driven approach to learning the legend. Usually, the first thing I learn about is a test runner that I can use for the language and then I play with the language by using the test runner and creating a bunch of tests. Everything is self-documenting and I can go back and tweak examples when I want to expand on my knowledge or find out how certain scenarios work. Best of all, I have a record of my learning and when I switch versions of the language or library, I can simply run my tests to see if anything I know has changed since the last time I used the language or library.

I recently started playing with the prototype library, and this approach has been a great asset. I can learn a little at a time and review my progress at any time. The prototype library is a Javascript library and I started out by using the script.aculo.us unit testing library (which is built on top of prototype).

My approach was to create a new .Net website, create a master page with all of the javascript references, and then adding new content placeholders for each logical area that I'm learning about.

My test page looks like this…

…and the tests look something like this…

This has been a great way to learn prototype and I think I'm probably going to do this more and more moving forward. Just about every language seems to have a unit testing framework and I like the idea of having code that I can go back and execute.