I remember reading Bruce Tate’s books on Java and EJB, which were all about anti-patterns, years ago and enjoying them. It was refreshing to read about how NOT to apply certain technologies. While there were plenty of books out there on how to do great things with Java and EJB (stop laughing), many of us using those technologies also found some not so great things we could do with them.

In much the same vain of Bruce Tate’s books, I give you a Scrum anti-pattern. Most Scrum teams will use a daily task board, either real or virtual. The task board contains a Sprint’s user stories and the associated user story tasks in the form of cards. It’s normal to see a few columns across the board along the lines of, “To Do”, “In Progress”, “To Verify”, “Done”, etc. The idea is for a team member to put his name on a task card and then move the card into the appropriate column. This is done throughout the day and especially at the daily Scrum. Below is an example of a Scrum task board.

Pretty simple. Below is the task board gone wrong. The difference is subtle and deserves an explanation as to why this is wrong.

Notice the extra column, “Today’s Work”. Having additional columns isn’t an issue, but this particular column presents a problem. The way the team uses this task board is to move tasks to “In Progress” when they’ve started work. But, since the team will sometimes start a task but then need to start on something else, the team decided they needed a column that showed what was in progress currently, thus the “Today’s Work” column. For example, in the daily scrum yesterday, Joe said he’s going to get Task A done. Joe moves this task to the “Today’s Work” column. Today, Joe tells the team in the daily scrum that he needed to start work on Task B for another story to help it keep moving forward, so he moves Task A to the “In Progress” column and makes sure Task B is in “Today’s Work”, as he didn’t finish that task yet. The problem is that we have impediments hiding under the “In Progress” column now. Rather than Joe saying that he was impeded from completing Task A, he moves it to a column (“In Progress”) that makes it seem like all is fine. All might be fine, but how do we know? It would be better to mark Task A as impeded. Joe could then make it clear to the team why he made the decision to not complete Task A in order to start on Task B. Everyone would see that Task A is in progress and it’s impeded (as opposed to simply “in progress”). The Scrum Master can help the team tackle this impediment.

Impediments aren’t inherently bad, but hidden impediments are. The task board gone wrong makes it far too easy to hide impediments while also making it difficult for the team to tackle properly. We all struggle with identifying impediments, so it’s important that we make sure our management tools are setup to help us make impediments visible and hard to miss.

Jeff Patton says agile is a culture. Rob Lally says no it’s not, it’s a characteristic. Both make compelling arguments. Jeff points out that agile is ultimately a culture which promotes certain processes and practices, whereas Rob argues that agile isn’t a culture unto itself but a quality an organization can adopt and make part of its own culture.

Agile has a strong culture. Jeff makes this argument clear with vivid examples of language, legends/stories/myths, values/norms/taboos, beliefs/attitudes, rituals/ceremonies, etc. But, does having a strong culture make agile a culture all unto itself that an organization needs to adopt as its own in order to succeed with agile? I don’t think so and this is where I agree with Rob. Agile is not a culture an organization adopts, rather it is a quality organizations can choose to add. Although, I never thought Jeff was arguing that an organization needed to replace its culture wholesale for that of agile’s, as Rob positions his argument against. I interpreted Jeff’s argument more along the one I was making in my 10 Questions to Think About Before Adopting Agile post, which was an organization’s culture needs to align with that of agile in order to realize success.

Rob makes an interesting observation in regards to selling agile as a culture:

Presenting Agile as a culture is something I’ve seen many times, and it puts more people off. Agile zealots, a club I was a member of a decade ago, try to sell Agile as a culture in a way that reminds me of Mao and his Cultural Revolution; they want to come in to your organisation, declare your culture to be bankrupt and rip it out, replacing it with an idealised regime of their own.

I don’t think there is any escaping the scary part of agile. Strong cultures are often scary to those looking from the outside in, whether those cultures belong to agile, lean, open source, religious groups, political groups, social clubs, etc. Those of us advocating agile need to be sensitive to this fact, but there is no escaping it as Rob seems to imply.

In the end, I think the most important takeaway in both Jeff and Rob’s posts is what they agree agile is not – a process or a set of processes. Those that see agile in this way and attempt to adopt it as such are almost certain to fail.

Agile. Everyone is doing it, so should you, right? Not so fast. Even though it’s being sold as a silver bullet by various vendors and consultants, agile is far from easy. In fact, I’d argue that adopting agile is harder than moving to a process heavy software development methodology. At least with the process heavy approach you have the how-to guide. Agile is as much about attitude as it is about anything else. And a company’s attitude is found in its culture. Companies with cultures that clash with agile are not likely to succeed in adopting agile.

The following is a list of questions I think anyone considering the move to agile, whether company wide or at a smaller scale, should ask before moving forward.

1. Is your company policy driven?
   If employees feel inundated by policies, watch out. There is nothing wrong with policies, but a company driven by policies is likely to be at odds with agile values and principles that support people interacting with one another over contracts, documentation, and processes. A company culture overrun by policies struggles to trust its employees to make good decisions without heavy handed tactics.
2. Does your company encourage identifying and eliminating its stupid practices, policies, and processes?
   A company culture that encourages, at all levels, the elimination of the stupid things the company does will have no problem latching onto agile’s principles concerning change. Don’t have a culture like that? Good luck with accepting and embracing change in a manner agile demands.
3. Is the contract king at your company?
   Contracts come in all shapes and sizes. Some contracts are legally binding documents between two parties, like a service provider and its customers. Other contracts are less obvious but more prevalent, like change request forms and requirements docs. A CYA approach by employees is often a result of a “contract is king” company culture. Welcoming changing requirements and customer collaboration are agile values and principles that are next to impossible for a “contract is king” company to adopt.
4. Is “on time and on budget” your company’s best measure of project success?
   Agile promotes continuously delivering working software that is valuable to the customer. When delivering on time and on budget is the key measurement to a project’s success, it misses the most important point: value. And this all gets back to our previous question of contracts. Companies that value “on time and on budget” the most as a measure of project success are often the same ones that depend on the contract to determine value, not whether the project truly does deliver something the customer wants or needs. This isn’t to say that agile cares little about time or budget, quite the contrary. Agile focuses on delivering value early and often.
5. Would a fair description of your company’s structure be one of tribes at war with one another?
   A great book to read to get an understanding of what I’m talking about here is Great Boss Dead Boss by Ray Immelman. Examples of warring tribes include production versus sales, engineers versus marketers, accounting versus purchasing, etc. Most of us remember the high school cafeteria and the cliques that form. Most of us laugh at how absurd the cliques got, yet too many of us grow up and create even more absurd cliques in the business world. Agile demands constant communication between people and focusing on the customer. You cannot succeed at either of these if your company is made up of factions of tribes. A company needs to be one tribe striving for a common goal.
6. Are simple solutions ignored within your company?
   Simple is hard and yet agile calls for simplicity. Company cultures that struggle with promoting simple solutions are often the same ones that “try agile” for a bit and abandon it because “agile doesn’t scale”. Also, companies that are in love with solving huge problems with complex solutions often struggle with simplicity. Simple is, well, too simple for these companies.
7. Does your company advocate and live by the “No Asshole Rule” (in principle, if not by name)?
   My apologies if the language offends. I find the behavior and acceptance of such individuals within an organization more offensive. Companies that do not adopt this rule will struggle mightily with agile. Individuals who are grownup bullies in the workplace will make sure that anything like agile, which encourages everyone involved to make good things happen, fails in spectacular fashion.
8. Is “corporate speak” the primary language spoken at your company?
   Communication is key to everything, let alone agile. Being able to reflect and adjust behavior is also key in agile. Speaking in a language that doesn’t say much at all is a serious roadblock to effective communication. Corporate speak is also a sign that a company’s culture may value style over substance. Style can come in the form of fancy documentation but little working software.
9. Do the people at your company enjoy working there?
   Don’t show me the survey done by such and such publication. Those are nice awards to put in the job postings but the real deal is found amongst the people on a day-to-day basis. The vibe of the workplace is hard to miss. Motivated people who feel empowered to get the job done are critical in successfully adopting agile. A place where the people don’t enjoy working for the company doesn’t fit this bill.
10. Do customers enjoy working with your company?
    Customers who go out of their way to say nice things about you because of how much they enjoy your company and its products/services trust your company and are going to want to make good things happen together. Agile is all about working closely with the customer. If customers don’t enjoy working with your company now, there is no magic agile pixie dust to make them enjoy working with your company when it adopts agile.

Some might argue that adoption of agile is an answer to these questions. That may be true, but I have my doubts. Company culture is what needs to change in most cases. Changing company culture in a positive way is difficult. The temptation for many of those considering the adoption of agile is to think of it as just another methodology, process or set of practices that can be adopted. Those taking this path are almost certain to fail. With that failure will come much finger pointing. Agile didn’t scale. Agile wasn’t disciplined enough. Agile is missing X, Y, and Z. Agile simply didn’t work. In reality, agile was never understood and never a good fit from the beginning.

It’s amazing to me how many projects start up without a clear vision. I’m not talking about an idea. I’m talking about a no kidding vision. And, no, I’m not picking on those who start projects on the side or just for fun. I’m picking on the those of us who are involved with projects for our organizations and customers that started up without a clearly defined and well understood vision.

I’ve found that agile projects are especially suspect to charging full steam ahead prior to a vision being created and communicated. Dietrich Kappe from Pathfinder Development wrote a post on this topic and made a similar observation. My favorite line from Kappe is where he points out an advantage waterfall projects have over agile projects in this regard:

Waterfall, by comparison, is marginally better in this regard (but worse in most others), since the right thing to do in the face of poor vision is to not develop software until that vision has been clarified, and waterfall is excellent at not developing software until pretty late in the project.

For some reason many believe agile principles and practices will overcome the lack of a vision for a project. We get so charged up about how we’re going to deliver early and often that we get lost in developing potentially shippable software without a clear picture of what we’re trying to accomplish overall. Before we know it, we’ve got a bunch of stuff developed and that’s about it. I’m guessing that some of this is a result of the following line from the Manifesto for Agile Software Development:

Working software over comprehensive documentation

Why would this one short line cause people to not develop a vision for their project? I think it may be that too many of us have been scarred by attempts to communicate vision in multi-page documents that end up saying nothing and no one reads once they are written. As a result of our past bad experiences, we replace these nonsensical vision docs with working software. In the process, we throw out the baby with the bathwater.

I recently came across a succinct template that I think almost any project or product can use effectively to communicate vision. Joel Spolsky posted one of Jim Highsmith‘s articles on setting a product vision. Highsmith uses the formula from Geoffrey Moore’s book, Crossing The Chasm:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

To put the template into practice, let’s pretend it’s 1999 (and really, who wouldn’t right now considering the economy?) and NetFlix is getting started. The vision for NetFlix might go something like this:

For people who enjoy watching movies and similar media from the comfort of their homes, NetFlix is a web based service that provides the largest inventory of movies, TV shows, and other video available for rent with Amazon.com like product search/browse, recommendations, and reviews, combined with great customer service. Unlike the major brick and mortar video rental chains, our subscription based service can be enjoyed entirely from the comfort of the customer’s home without any worry of late fees.

Not too bad. People might actually understand and remember the vision. Imagine that!

Some may think the template above is only good for products or product focused companies. Internal projects or those that aren’t developed for resale can still make use of the template. The challenge is to think differently about certain concepts. For example, the competition for internal projects is normally one of legacy systems, manually intensive processes, or the status quo.

Bottom line, don’t start a project without a vision. If an active project doesn’t have one, stop now. Get with the key stakeholders and write one together. Remember, vision statements don’t need to be (nor should they be!) long winded, they need to cover the important points in a manner people will remember and carry with them as they get busy developing the solution.

My favorite agile software development topic of them all — tools. More specifically, agile project management tools. If you’re old school, you bust out some index cards, some butcher paper, some writing utensils, and you get to work. If you’re trying to use one of the simplest of agile project management software tools (that most are introduced to as part of their Scrum training), then you open up an Excel template. If you’re looking for something a bit more comprehensive or even just a little more automated, then you do a search on Google for “agile project management software”. You click around, see quite a few options, look at some screenshots, screencasts, and likely research mailing lists and blogs to see what people think of these tools.

At some point you’re likely tempted by some vendors making amazing promises. These vendors aren’t simply selling software project management tools; they’re selling you the keys to enterprise enlightenment. They show screen after screen packed full of nondescript icons, drop down menus, and incredibly detailed forms that make you wonder how you got by in the past without tracking all that information.  They integrate with version control systems, integrated development environments, issue trackers, testing tools, portfolio management systems; some will even have integration with customer relation management systems. What more could you want? A lot more. Actually, a lot less. But, as the saying goes, “less is more.”

The inspiration for enterprise software?

The problem I see with a number of the agile project management software offerings available today is that they have lost sight of what it is to be agile, at least when it comes to managing their own products. It seems like these solutions are trying to be all things to all people. Featuritis has hit these products in the worst way. I think the UI designers of these products were forced to get their daily dose of inspiration through slide shows of Enterprise Resource Planning (ERP) software screen shots and other “enterprisey” offerings that cause many of their users to go home each night wondering why they can’t master the art of using the software to get their jobs done more efficiently.

Beyond the usability issues I see with this new breed of agile project management tools and the attempt to “be all things to all people”, I think these tools are missing the mark in an even bigger way. If you want to provide the ultimate agile project management software, then you might as well leap frog the old project management tools by looking at what the open source community is doing and using. The offerings by sites like java.net, Sourceforge, and many other open source project hosting sites are where these agile project management vendors likely need to turn their attention to. There is a reason tools like Trac, Redmine, and others are utilized by more and more open source projects to manage development of the software. These tools acknowledge the need to manage the software development process in a distributed environment where there can be many contributors and many users. The focus of these tools does not start with a project manager view of the world, but rather with a project contributor and user focus. This means that an issue tracker becomes the central nervous system. Version control is a first class citizen, not something you leave for third party integrations. Mailing lists, forums, and RSS/ATOM feeds are often key features in these open source software project management tools.

I will admit to being biased in this post. I am not a fan (in general) of most software that is aimed at the “enterprise.” I believe that many of the best practices in open source software development should be adopted by agile tool vendors looking to address the problems faced by those involved with software development projects. I’ve held off writing a post about agile project management tools for over a year now, but after recently re-evaluating the options out there I felt it was time to give my thoughts on the topic. It’s a way more popular topic than it should be in my opinion. It’s much easier to talk about the merits of one tool over another than it is to address the more difficult (and more critical) challenges involving changes required in human behaviours.

In my last post I wrote about user stories and how it’s easy to write a user story and forget to include the value statement.  Now that we’re all writing user stories with value statements, I thought it would be interesting to look at another phenomenon I’ve seen far too often when it comes to user stories – their death.  Yes, all good things must come to an end, but the way too many user stories die is not fitting.

Let’s take the example user story from the last post, which was from the Apple iPhone product owner (who am I kidding, Steve Jobs):

As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi so that I can save money by not using my crazy expensive voice minutes.

The team working this user story thinks they’ve got it during their backlog selection. They’re excited to put the screws to the carriers as they prepare to expand beyond AT&T and turn the cell phone industry on its head.  The team does their task breakdown and they’re off and racing.  Daily scrums are happening, team members are communicating, impediments are being raised, tasks are getting done, and all is good in iPhone VoIP call land. The sprint review rolls around and the team is ready to show off their solution. They demonstrate making VoIP calls on a 3G network. Only one little problem.  The team mentions that in order to complete this story in time they decided it was best to use a VoIP service provider that would make the user experience far superior to any the team could develop in a reasonable amount of time.  The VoIP service provider charges a monthly fee. On top of the monthly fee there are hidden charges around certain types of calls. The product owner does his own demonstration following this. He demonstrates how the iPhone 3G can be used in combat by chucking the sleek devices directly at the team members’ heads.

So what happened? The user story was viewed during backlog selection, placed in a sprint management tool, and forgotten about until the sprint review. The team understood what they were doing, or so they thought. They were focused on completing the tasks to get the user story done. The team lost track of the actual user story – out of sight, out of mind.

The trick is to make sure the user story doesn’t get lost throughout the sprint and die a quick (yet too often) painful death. I haven’t figured out how to do this. Posting the user stories up on boards/walls is one idea. Temporary tattoos (that last the length of a sprint) of each user story on every team member’s forearms is another. Wait, that’s it. Sorry, I’ve got to make some calls now. My temporary tattoo parlor is calling.