10 Questions to Think About Before Adopting Agile

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.

Project Vision – Don’t Even Start Without One

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.

Agile and Estimates and Contracts! Oh My!

Over the last six months, I’ve been mulling over one of those subjects that has often been a stumbling block for IT providers considering adoption of agile for their customers’ software development projects. The dilemma revolves around contracts and estimating projects. The two tend to go together. Once you have one figured out it seems you’re left with even more questions with the one remaining. I have some ideas on how to make agile contracts and estimating better based on what I’ve learned and observed over the years.

WARNING: This is a long post. I try not to write long posts. I think this one is worth it, mainly because it’s building off the ideas of those much smarter than me. Continue reading “Agile and Estimates and Contracts! Oh My!”

Oxymoron: Enterprise Agile Project Management Software

The ultimate agile project management tool?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 applications?
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. Open Source logoThe 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.

Death of a User Story

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.

RIP User StoryThe 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.

So That…

One of the most overlooked parts of user stories is the content that follows those two little words, “so that.”  I’ve found that we (those of us working on agile projects) tend to do a good job of writing user stories until it gets to those two little words.  For example, let’s say the iPhone team has a backlog and one of the stories is:

As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi.

iPhone 3GSounds pretty good in terms of a user story. It’s likely more an “epic”, but I won’t get into the size of user stories. Let’s start the conversation with the product owner and the team and estimate this story. Not so fast. Notice that we have no idea why the user would want to make voice over IP (VoIP) calls over the 3g network. I think the assumption is often made by whoever is writing the user stories that the team and others already understand the value of the story. That is not a safe assumption to make. Not only is it not a safe assumption to make but the focus of the team will turn to “how” to make the user story a reality. I think we’d all rather discuss the value of the user story before we start jumping into questions about how it might be implemented. But when the value isn’t present in the story it’s easy for everyone to overlook. Let’s see what that story might look like with the value statement added to it:

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.

Now we understand why the user wants this functionality. Before we could’ve assumed it was for any number of reasons. The cost savings is the driver for this story. The team and anyone else reading this user story can now better understand what the real drive for the desired functionality is.

I read a while back an InfoQ article about changing the format of user stories.  The traditional format is what we’ve already used in the example above:

As a <type of user> I want <some functionality> so that <some benefit>.

The new format suggested by the Elizabeth Keogh, the author the InfoQ article points to as the one suggesting the new format, looks like this:

In order to <achieve some value>, as a <type of user>, I want <some functionality>.

I think the new format is worth considering in light of how many user stories lack value statements. TYodahe only thing holding me back from this new format is that it reads too much like Yoda speak. Yoda was always known for putting those awesome sentences together, like: “Named must your fear be before banish it you can.”

I think whether we change the format of user stories or simply use the existing format, the important thing to remember is to communicate the value driving the user story. As Yoda might say: Focus we must on business value lest we lose reason why user story exists.

Your Search is Over: The Definition of Done in 3 Easy Steps

Has your team struggled to define “done” for user stories? You are alone. Everyone has this one figured out.  You must be new to this thing called agile software development. What’s that? You’ve been doing this agile thing for some time now?  Wow, that has got to be depressing. I’m sorry to hear that you’re struggling with such a simple concept.  Fortunately for you I’ve got the answer. Follow these three simple steps:

  1. Listen to this podcast with Scott Hanselman interviewing one of the founding fathers of Scrum, Ken Schwaber
  2. Sit down with the team, Product Owner, Scrum Master, and maybe even major stakeholders to define what success is for your project in a clear and simple manner
  3. Make a list of all the activities required to achieve the level of quality required by step 2 for a typical user story in the backlog

Easy, right? That’s fine.  When you punch the picture of me on the screen I don’t feel a thing. I’m still smiling, see?

Distributed Agile Teams Don’t Work

Collocated TeamThe title of this post is misleading. I think distributed agile teams do work, but only if everyone is remote. I’ve come to the conclusion that what doesn’t work are what I call “semi-distributed” teams. Semi-distributed teams are those where some people are co-located and others are not. I’ve seen all sorts of arrangements over the years. Everyone collocated but one person (experiencing that one currently – me being the odd man out), some collocated in one office and some in another, a few people distributed remotely and others collocated, on and on it goes.

The reason I argue that fully distributed agile teams work is because everyone is in the same boat. Everyone is disconnected and therefore looking for solutions to the problem of connecting with one another. With semi-distributed teams you have some people who are desperate to be a part of the conversation, while others are often quite content with their little collocated circle. I think this fact is often overlooked when people point to Open Source Software (OSS) development working in a distributed fashion and equate that to proof that semi-distributed projects can work just as well. One of the reasons OSS development works is because everyone is (typically) working remotely. The ease of looking across your desk and striking up a conversation with one of your team members is not an option with most OSS projects. Everyone on the OSS project needs to put forth an extra level of effort to strike up a conversation, even if it’s just chatting in IRC, sending an email, or doing a screen share session.

Distributed TeamA majority of agile proponents will argue that collocation is a requirement for highly successful agile projects and I agree. The level of discipline required to make distributed agile projects work cannot be understated. But, you can be successful with distributed agile projects. What you cannot be overly successful with are semi-distributed agile projects. The level of effort to make semi-distributed agile projects work is too great for most of us mere mortals to overcome. I’m sure there are those that will point to their success stories of semi-distributed agile projects, but I will argue those are the rare exceptions rather than the general rule.

Some may read this post and have a moment of truth smack them right in the face, “Wait a second, I’m on a semi-distributed agile team!” What do you do in that case? My suggestion is that you figure out a way to make the team collocated. There are many creative ways to make this happen. For example, the team that I’m currently on and am the lone remote person on the team (Scrum Master, nonetheless!),is going to get a local replacement. If you can’t go collocated, then a radical idea might be to go completely distributed. Have everyone work from home and force themselves to deal with being remote. It’s amazing how well teams can stay connected these days when they’re all working from a different location. In other cases, it might be possible to create one team that is collocated and another that is truly distributed. Team to team communication is often tricky, collocated or not. At least with a collocated team and a distributed team you’ve eliminated the avoidable problems of a semi-distributed team. The problems you’ll deal with in this case are the same problems anyone scaling agile is faced with. It’s not an impossible mountain to climb.Semi-Distributed Team

If you’re still stuck on a semi-distributed team after trying some of the suggestions mentioned above then I wish you luck. The best advice I can give is to enforce use of constant connectivity through technology like video conferencing. People will likely object to this due to a sense of loss of privacy (understandably so), but it gives you a fighting chance of keeping everyone in the loop. Cool apps like MeBeam provide the ability to have more than two participants on a video conference. You’ll also want to investigate technologies that allow you to share whiteboards. I don’t have personal experience with these but I’ve seen them in a variety of places, especially schools. I can see electronic whiteboards helping where collocated members step up to a whiteboard on a whim and start jotting down some new design, architecture, notes, etc. These whiteboard sessions often turn into important moments of team collaboration. It’s moments like these that get lost by the part of the semi-distributed team that is not collocated. Use every communication and collaboration tool in the toolbox if you’re stuck on a semi-distributed team, you’re going to need them.

I Think I’m Going To Write a Book

Today was a real break through. I was talking to two senior developers here at Gestalt this morning about how to test some code one of the teams in the Joplin, MO office is working on. I came up with this awesome idea that I threw out there to these two devs. I said, “We need to be able to automagically take some test data, pump it through our module, let it do its voodoo, and then compare the results with what we think we should see in the end. Oh yeah, and this should be able to run constantly, whenever someone makes changes to the code base, this kind of test should run.” They were speechless. I think it was because of my brilliance. I know, that’s not being very humble, but this is a HUGE break through I made today. I can’t blame the guys if they were in awe of a Scrum Master’s ability to revolutionize the world of software development in less than a minute of thought. I wonder if this is how Alexander Graham Bell’s colleagues felt when he invented the telephone?

WTTBYC BookThis new way of testing software certainly demands a book. Imagine, being able to write tests in code that are run continuously as the code evolves. The confidence you’d have in the quality of your code would go way up. Ideally, you would write these types of tests before you write the code. BAM! Another magic moment just happened as I typed that last sentence. Write the tests before you code. WTTBYC is pretty catchy, no? I think I have the title for my first book right there: Write the tests before you code (WTTBYC). Imagine how writing tests first might help improve the design of your code. If you need to think about how you’re going to test the code it might force you to write things a bit cleaner.

I think the only thing I need to work on now is fighting off all the tech book publishers with a stick. I may need to get an agent. What a game changing day it has been!

Top 10 Signs of a Troubled Daily Scrum

  1. Takes longer than 15 minutes
  2. All team members aren’t answering these three questions clearly:
    1. What did I commit to and get done since the last daily scrum?
    2. What am I committing to getting done by the next daily scrum?
    3. What obstacles are impeding my progress?
  3. ScrumNo one can remember what anyone else said 30 seconds after it’s over
  4. Team member says he’s not sure what he’s going to do today & no one on the team says anything
  5. Impediments are rarely reported
  6. Scrum Master isn’t capturing impediments
  7. Team members who can’t make it in person don’t call in or email/tell a fellow team member their answers to the three questions prior
  8. Not reporting out against tasks in Sprint backlog tool (task board, ScrumWorks, etc.)
  9. Team won’t hold it without prodding from Scrum Master
  10. Team members report out to Scrum Master