If you follow the links above, you’ll notice a theme and, though it’s not explicit in the class’ title, Extreme Programming is a significant influencing factor in the course content. Like most software developers, XP has had a major positive impact on my pursuit of the craft, and it’s great to see the practices hold up so well over time.

The ADS course utilizes some lecture, but it is primarily a hands-on workshop giving participants the opportunity to experience developing high-quality, working software using Agile principles and practices. This is the second time I have experienced the class (the first time was as a participant back in May) and it has remained an intense, thoroughly enjoyable way to either learn the practices for the first time or to delve deeper into Agile. I find it hard to believe that anyone could leave the course without learning a great deal. It is both challenging and insightful.

I think my favorite part of the class are the questions and how they help shape and guide the content. That feedback is crucial to the success of the course (maybe any course) and, as an instructor, I find the questions leave me thinking about these principles long after the class is over.

Next time, I’ll share a couple of the questions and some of those thoughts. For now, though, I encourage you to take a look at Agile Skills Network and consider taking the course. Regardless of where you are in your software craftsman journey, the ADS course will encourage you to push further down the path!

It has been a busy year. I knew that new ventures are all-consuming, but knowing it and living it are two very different things. I’m closing in on a full year as an independent consultant, the last six months of which have been with one client. Things have been going great and the client is looking for ways to extend the contract; possibly through the end of the year.

That’s a long time to spend in the same environment, and this comes with a significant danger. In Weinberg’s book, The Secrets of Consulting (you can find the book online, but you’ll probably have to buy it used), he refers to this as “Prescott’s Pickle Principle”:

Cucumbers get more pickled than brine gets cucumbered… A small system that tries to change a big system through long and continued contact is more likely to be changed itself.

I experienced this first-hand in a recent conversation with a friend and colleague who just started working with the same client a little over a month ago. I had just had a closed-door meeting with a member of upper management in which they laid out their plan to address several challenges in their organization. I didn’t completely agree with the plan, but I have worked with this group long enough to know when the decision is final so, except for a few clarifying questions, I accepted the news with very little feedback. As I explained to my friend how this might impact him, his response was “this is the wrong solution. It’s going to cause more problems than it solves!”

My initial thought was “technically he’s right, but he doesn’t have enough experience with this client to know when to accept the inevitable.” And that’s when it hit me: I’ve been pickled.

My job as a consultant is to be a change agent. “Long and continued contact” with a client diminishes my ability to fulfill that role. That is why Weinberg gives the following advice:

To avoid getting pickled, a consultant must not spend too much time with one client. If you can’t avoid this, at least break up the time by working with other clients, even for free… It’s hard to be effective, though, if you’re always switching jobs or clients. Change generally takes both time and continued contact, or at least one of the two. The challenge, then, is how to get the client in long, continued contact with some kind of brine, without the consultant even being present.

The challenge indeed! There is a natural tension: time and continued contact erode a consultant’s ability to affect change, yet affecting change takes time and continued contact. I think there are ways to counteract this and I hope my efforts to do so in my current situation will prove effective. But it is also important to recognize the warning signs and to act in the interest of both your client and yourself.

What are some ways you’ve found to keep your clients “in continued contact with some kind of brine without even being present?”

Brushes is an iPhone app that was highlighted during the introduction of the iPad a few weeks ago. One of my hobbies is Graphic Arts and I have often bemoaned the fact that I can’t find more time to spend on it. I even carry around a Wacom tablet… that rarely gets used: partially because there is a (very little) bit of setup required, but mostly because I’ve never been able to get comfortable with drawing in one place (on the tablet) while watching someplace else (the monitor) to see how it looks.

Once the iPad rumors hit a fevered pitch, my first thought was that it would make a great graphic arts platform. When Apple highlighted Brushes during the iPad unveiling I decided to purchase it for my iPhone. I played with it a little, but found the lack of accuracy due to using a fingertip somewhat off-putting. I’ve put in many hundreds of hours sketching with a pencil or pen so that approach is completely natural to me. I thought using my fingertip would be close enough to be satisfying, but… well, it isn’t. I really need a writing utensil in my hand.

While I’m really excited about the iPad, it’s looking like it will not ship with a stylus and this is a bit of a disappointment. Enter Ten One Design and the Pogo Sketch, a stylus that works with the iPhone, with newer Macbook trackpads and the iPad (well, once they’re released anyway… Hurry up Apple!!!).

But wait, there’s more! The pièce de résistance: due to a built in Web server that allows you to transfer drawings from Brushes on your iPhone to your Mac and a companion Mac app, Brushes Viewer, you can get a high resolution version of your small-screen artwork. Since the iPhone app actually records your strokes, it can replay those strokes at a higher resolution. Not only that, you can actually watch yourself create your masterpiece and save it off as a Quicktime movie! The max resolution for a static image is 1920 x 2880 and it looks incredible. While I wasn’t happy with the results I was getting using my fingertip, I’m very happy with the results using a stylus. Here is a medium quality (960 x 640) version of my first attempt using a stylus (click on the image to see it full size):

Paul Nelson, 15 February, 2010

The combination of the Brushes app, the Pogo Sketch stylus and Brushes Viewer means I can carry an art studio in my pocket… well, close enough.

I can’t wait to play with Brushes and the Pogo Sketch on an iPad! Oh… and look for a nice tie-in with my Agile Blind Spots series of articles soon!

Fortunately Agile is about executing, learning and adapting and I am beginning to see a push in two directions: both into the activities that lead up to the project’s visioning exercise and into assessing the value the project is providing in the real world.

One of the things that I really appreciate about Agile is the vetting process that helps a team prioritize the work in the backlog based on Business Value. This insures that those features having the highest potential for the most business value are completed first. This is highly effective in the confines of a given project. However, nothing in this process addresses: 1. how this project fits into the overall vision of the organization, 2. how the value of this project compares to other projects in the organization, and 3. A sense of whether or not the actual user will find the product useful.

In all fairness, it can be argued that these concerns fall outside the responsibilities of the project. But I submit that if an Agile team successfully delivers a feature set that does not fit in the overall vision of the organization, or is of less value than other projects that were passed over in favor of this project, or fail to prove useful to the end user, the project is a failure, ergo Agile has failed.

That may seem harsh, but I believe it is accurate. In order for Agile to continue to thrive, it must push forward into the process (or lack thereof) that precedes kicking off the project. Fortunately this is a fairly simple concept. An organization can apply the same vetting process used within the project to the process of selecting which projects actually get worked on and in which order. It is not hard to envision creating a prioritized queue of products or feature sets at a level above the actual project execution.

It is not enough to successfully deliver a project if the project itself is improperly positioned. Agile needs to push upstream. We need to start asking the tough questions:

• How does a given project support the overall vision of the organization?
• Where does a given project fall in the overall prioritization for all work on deck?
• What research have we done to provide a reasonable level of confidence that a given project will provide real value in the real world?

If you are OCD… er, detail-oriented like me, you may have noticed that I have only addressed two of the three concerns I listed earlier. I’ll save the third one for next time. In the meantime, how do you envision your company pushing the Agile values upstream in an effort to provide the right thing to the right people at the right time?

• I am not trying to incite a religious war over the merits of Agile or any given Agile methodology
• I think Agile has been a significant positive force in the IT Industry, driving a focus on continual improvement, quality, incremental delivery and, overall, bringing back a fair amount of science to computer science.

Let me state my assumptions: first, Agile is IT process-centric because it was created by software engineers. The reason the term was coined and the movement birthed is because we in IT were tired of a heavy-weight process that had a track record of setting us up for failure. I am extremely grateful that a group self-organized back in late 2001 to stop the insanity and blaze a trail in a new direction. As is often the case, that which gives us our strength is also our downfall.

My second assumption is that the direction of a project and the details of a process should be driven by providing real value in the real world. I’m sure that some of you are already jumping ahead of me and planning my lynching, because I obviously have missed the point that Agile is all about “Business Value.” Hopefully you’ll give me time to explain. While business value is firmly espoused in principle, I’m not convinced that the concept is well understood and, therefore, misses the mark in execution (this statement is based on direct observation of dozens of teams who are doing their best to follow Agile principles and continually improve). The reason for this is straightforward: Agile is being driven by IT. Our focus is on “working software.” Yes, “working” should include the concept of providing real value in the real world, but does it? How do we know? Are we utilizing objective measurements to show how real customers are using the product in the real world? Or are we satisfied validating this through the tacit approval of a Product Owner?

More importantly, is anyone stopping to ask these questions before we get started? I am continually surprised by how many software projects are given the green light or continue to live without anyone asking the hard questions: how will we justify the significant expense incurred to create and maintain this? How many users will actually use it? Will those who we expect to use this find it valuable? What problems will it solve? What problems will it create? How can we know the answers to these questions before we have a product for someone to use? It strikes me that there are very few products who could get away with making it to production without answering these questions. I think the days of software products getting away with it are numbered.

Let me pose a simple question: how many non-IT business professionals can you list who are making a significant contribution to the Agile movement? How many Product Managers? Product Marketers? Corporate Executives? I know my circle is small, but I can’t think of any. It seems to me that if we were truly engaging “the Business side of the house”  that they would eventually have a significant presence as speakers at conferences, authors of books on Agile and the like. Yet the Agile landscape is still dominated by geeks.

This is not to say that Agile has failed, but I do think Agile can only go so far: it can only solve certain problems in its current state. Agile has performed splendidly, moving us away from a draconian focus on process, but I am not convinced it can take us all the way to where we need to be: focused on providing real value in the real world. IT cannot lead us there. We desperately need someone without our blind spots to show us the way.

Fortunately, many in Agile circles are already wrestling with this issue and I intend to delve deeper into some proposed solutions in my next article.

So what do you think? Am I completely off-base? Are we already there and I’m just late to the game? As always, your comments are welcome!

I’ll start with the patently obvious (pun intended): exactly like their introduction of the iPod, and exactly like their follow-on introduction of the iPhone, the iPad’s primary raison d’être is to provide yet another portal to content. Steve Jobs brazenly admitted as much in Wednesday’s product announcement, citing a couple of facts:

• Apple has 175 million consumer credit card numbers attached to iTunes accounts.
• Customers have downloaded 3 billion apps for their iPhones and iPod Touches

That’s just applications! What about music and videos?

• As of a year ago (Phil Schiller’s Macworld keynote) iTunes customers had purchased 6 billion songs.
• Over a year and a half ago, customers were purchasing 50,000 videos per day on iTunes. Assuming that hasn’t changed (and the daily rate is likely much higher today), that would be over 18 million video downloads per year.

Interestingly, as the iPhone and iPod Touch opened up new content sales for Apple in the form of videos, the iPad also adds ebooks. So Apple wants you, me – all of us – to purchase our content from them. The devices are simply the conduit. Granted, the folks at Apple are software and hardware artisans, so using their devices to consume all that content is a joy in itself. But I think Apple figured out a while ago that hardware will continue to be marginalized and that “content is king.”

So enough stating the obvious. I’ve heard a few people (geeks, mostly) ask questions that basically boil down to “So what? Who cares?” I have an iPhone. I have a Macbook Pro. The last thing I want to do is lug around a third device that doesn’t give me anything new!

I’ve also heard it stated that the iPad is a let-down because it’s evolutionary, not revolutionary. I disagree with these sentiments. I think the iPad is revolutionary and I think we, as geeks, need to sit up and take notice. It has been a very long time coming, but the way we interact with computers is finally becoming a bit more… human. Lately, there has been a lot of buzz in the IT world about User Experience, stating that it has been a second-class citizen for far too long. We are striving to simplify interfaces and improve user experience. Yet we still expect every computer user to be proficient with a keyboard and a mouse, to understand hierarchical menu systems, keyboard shortcuts, archaic command line incantations, etc.

Years ago, I had an idea for a computing device. The impetus for my idea was the simple thought that “a computer should be as easy to use as a piece of paper.” The iPad is not that device, but it is much closer than a device that uses a keyboard and a pointing device. What is more natural than pointing at something with your finger? The iPad is revolutionary by being a full-scale computing device that we interact with very naturally; directly. It eliminates a layer of abstraction at the most fragile, yet crucial part of any system: user input. This is a Good Thing, and I can’t wait to see where this latest step in improving user experience leads us!

So I, for one, will be lugging around three devices… at least for a while.

I have been a casual Go player for about two years now, ever since being introduced to the game by a friend and former teammate. Around that same timeframe I read somewhere online that all software developers should learn the game of Go (sidenote: if there was ever a case for Semantic Web, it is Go. Googling “Go” is… pointless).

I’ve written about Go before, and looking back on my approach to Go so far (I am probably rated around 20 kyu, which is a rank beginner) gives me plenty of object lessons.

One such lesson is looking at the game as an emerging design. I have no idea what the end state of a game of Go will be. The way I currently approach the game is to quickly survey the entire board with a bias for the area in which my opponent just played, in order to narrow my focus to a few strategic moves. This usually leads me to a smaller section of the board, where I will play out a series of moves in my head to determine which of my possible moves seems the most valuable (value being defined as the right balance between potential gains and potential losses).

I have found the same approach useful in improving the design of legacy code. In dealing with very large codebases (over 500K lines of code), I find it impossible to determine what the end-result of design improvements should be. However, I can look at small parts of the system and see small ways in which the design could be improved. Many times I am looking in a certain section of code because a search for the root-cause of a defect has led me there (my opponent’s last move?). Writing Unit Tests allows me to explore the problem space and find the best course of action. All of this leads to incrementally improving design, which in turn increases value.

The hard part, both in the game of Go and in software development (as Kent Beck clearly articulates), is dealing with ambiguity. I cannot lose sight of the big picture: staying focused on a small subset of the overall problem space almost certainly results in failure. Yet allowing the insurmountable complexity of the big picture to paralyze me is as detrimental as losing sight of it.

Like so many things in life, it’s all about balance: balancing potential gains and potential losses as well as balancing focus on the big picture and focus on the details.

So in the spirit of eXtreme Programming, I propose what I believe to be an interesting thought experiment: if self-organizing teams are good, then we will always treat the team as a unit; never drawing attention to specific roles.

This is interesting because success or failure should be measured as a team. If a developer on the team does a great job, but no working software is delivered, the team failed: therefore, the developer failed. If a tester on the team does a great job of providing test coverage over one, small part of the overall work for an iteration but no Stories are completed, the team fails: therefore, the tester failed. If the Iteration Manager does a great job of removing roadblocks and insuring work is driven from a prioritized backlog, but the requirements are unclear and the Demo fails, the team fails: therefore, the Iteration Manager fails. In short, any individual team member’s success is completely dependent upon the success of the team.

This should lead to a team where the concept of roles is, at a minimum, blurred. The team does whatever is necessary to attain the stated goals: meaning, individuals on the team do whatever is necessary for the team to succeed. There is only one role: team member.

So why is this a thought experiment? When it comes to getting real work done, we need competency in certain skills. It would be difficult — even silly — for a company to list job postings seeking “Team Members” without any specific skill set. We still need experts. We still need people with the specific ability to turn ideas into code; to effectively facilitate a team; to expertly test a system. Those roles, and more, are crucial to making real progress on software development projects.

Being an individual is easy. Working effectively on a team is a worthy challenge. What are some ways you are encouraging your coworkers to become teammates: to put the interests of the team ahead of their own interests/concerns/agendas?

The irony of the situation has not been lost on us. Our job is to create a franchise model of Agile, so that the company can start stamping out Agile teams like a manufacturer churning out Happy Meal toys. This has been the topic of discussion among the consultants over many lunches and dinners, and even during trips to the airport.

Somewhere along the line, one of us observed that “maybe we should look at this as an opportunity to institutionalize flexibility.” This is, of course, somewhat tongue-in-cheek, but I also believe it is indeed our challenge. In fact, I think it is the greatest challenge facing Agile adoption today: how do we make Agile work in a large organization, where conformance, governance, systems integration and the like are valid constraints? It is not enough for a team to know where they are: the organization needs to know where they are, how what they are doing will impact other efforts, how much time and effort is involved, etc.

Several large companies are seeking to provide tools to solve this problem, including one that likes three-letter acronyms that begin with “R”. As far as I can tell, the only thing that has been accomplished so far is to add complexity to an already daunting task. Honestly, I don’t think I’ve ever seen a process problem solved by throwing tools at it, but that seems to be the first and most frequent solution landed on in Corporate America. Yet the problem is real, pervasive, and needs addressing.

So how do we institutionalize Agile without violating Agile’s core values? I’m not sure, but whoever figures it out stands to make a fortune!

But I am not completely alone. I’ll be working very closely with these guys. Just to give you an idea of how hip this group is, take a look at their office! Yep, it’s a boat and, yes, they have a nice view of Lake Erie and the Cleveland skyline.

This new opportunity will give me the privilege of continuing to pursue my passion: helping software development teams have a lot of fun making real progress on real projects.

It seems that the current Agile Hype is around Kanban, so I thought I’d tie that in as well. I am both impressed with and concerned about kanban for software development, a new-ish methodology taking ideas from Lean and from the Toyota Production System (TPS). There are many great ideas in this newest evolutionary step in Agile: a focus on quality, limiting work-in-process, balancing demand against throughput, effective prioritization, pull don’t push, continual improvement, eliminating waste, and many more. All of these are powerful concepts (David Anderson gave an excellent talk on kanban, which you can find here).

Why the concern? Well, it seems that certain other Agile methodologies have ended up being more about creating marketable intellectual property than solving real-world problems. And I think that’s an easy trap to fall into. Marketing an idea is important to it’s survival, and that is going to create tension. As long as those behind the Kanban approach stay focused on solving real-world problems, we’ll be fine, but they will have to fight against the urge to over-market their ideas.

I hope they succeed, because I think this latest incarnation of Agile is a very good thing! And I’m looking forward to proving that out over the next several months while watching kanban for software development continually improve!