Category Archives: Agile

Everyone is doing Agile and Lean

Agile and Lean are old news. Everyone uses and abuses the lexicons. Have a short daily meeting? Call it a daily Scrum. Trying to deliver something in a relatively short period of time? Call it a Sprint or iteration. Have a board with post-it notes in swim lanes? Kanban at your service. Writing some tests? Call it TDD. Attempt to improve a process? Continuous improvement! Use a CI server to run a job here or there? Tell the world you’re doing continuous integration. Code on production? Continuous deployment! Meanwhile, people who list experience with Agile and Lean on their resumes more often than not talk about how painful and all around chaotic it all was. The underlying reason for this bad aftertaste is most often due to the adoption of practices without an understanding of the principles behind them.

The temptation is to read an article, watch a short video, attend a conference session and latch onto a particular Agile or Lean practice without the fuller context. This is especially popular in tech where many (most?) of us have a natural tendency to chase after shiny new objects. Instead of a collection of tools that serve their purpose within a greater context, we latch onto the hammer and start pounding everything in sight. A team struggling on a project decides to try a daily standup because they like that part of Scrum. They don’t realize the nuances behind a daily Scrum. They don’t grasp the commitment demanded by Scrum as a whole, and how the daily Scrum helps enforce that commitment. A standup is easy; building teams dedicated to consistently delivering something tangible in a short period of time is not. Every ceremony within Scrum is there because the principles drive it. Adopt one ceremony out of context and the result is less than satisfying – far short of transformative. Ditto for Lean. The practices are easy to grasp and implement poorly without knowing the “why” behind them.

Wrestling with and forming an understanding of the principles behind Agile/Lean requires perseverance. There are no shortcuts. Trial and error is expected, but not without wrestling with the reason why we’re trying to implement a practice in the first place. Racing from one good idea to the next requires little discipline. Little is learned when a practice is implemented without a grasp of the underlying principles. The failed practice is tossed out and a new one takes its place, awaiting a similar fate. The only way out of this rat race is learning why a particular framework, practice, methodology is the way it is and then identifying and carefully evaluating the problems we’re trying to solve and how the two align (or don’t.) There are no shortcuts. No silver bullets. No buzzwords to save the day.

Bitter Scrum: A Task Board Gone Wrong

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.

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.

Scrum task board gone 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.

This entry was published on March 22, 2009 under the following topics Agile

Agile – Culture or Characteristic?

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.

This entry was published on March 8, 2009 under the following topics Agile

Review The Tests, Then The Code

magnifying-glass

Last week I was talking with one of the developers at work and he was telling me about improvements his team was making in regards to (informal/desk check) code reviews. I told him that was great and then followed that up with a recommendation on how to improve even more.  Next time there is a code review, start with the tests. This will do two things: 1) Stress the importance of having tests 2) Make the review go quicker, as the tests will either be there and make the intent of the code clear or they won’t be there and the review is postponed until tests are in place.

I know I’m not the first to make this suggestion, but I felt it was worth repeating. Code reviews do have value, even when you pair program. At least, I think they do. Pair programming provides two sets of eyes on the code at the time of creation, but it’s surprising what someone who hasn’t seen the code before will find during a review.

Oh, and if reviewing the tests during a code review doesn’t make the intent of the code any clearer, then I suggest the team investigate behavior driven development (BDD). I’m becoming quite partial to the Cucumber framework for BDD, as I like it’s emphasis on user stories with acceptance tests/examples written in plain text and backed by executable steps.

The Customers Disappear Right Before Our Eyes

Tonight I was foolish enough to think my family and I could waltz into a restaurant on Valentine’s and get a table without much trouble. We were trying a restaurant we hadn’t been to before and I realized as soon as we pulled into the parking lot this probably wasn’t the best night to experiment. We went inside anyway to see how long the wait was. Much to my surprise, the hostess told us it was only about a 15-20 minute wait. I looked around the restaurant and, while it was full, there wasn’t a large number of people waiting on tables. We got on the waiting list and then proceeded to wait.

What I saw during the wait was kind of surprising. I noticed that the staff were diligently doing their jobs, quickly moving from one spot to another. I had to be careful not to step too far away from the waiting area or I was sure to bump into one of the busy bee workers. And while the staff was incredibly focused on the operations of the restaurant, I couldn’t help but notice they were almost oblivious to their customers, whether those customers be waiting for a table, eating their meal, or somewhere in between. I looked around the restaurant of about 40 tables and noticed that at any given moment there were numerous people looking to get the attention of their waitress. Customers coming in through the door were rarely greeted in a timely manner. Those of us waiting for a table were ignored completely, even as our original wait time came and went.

It dawned on me that this situation is not unlike what happens with some software development projects. We get in the groove of producing the software and never take time to make sure we’re satisfying the customer. Yes, those of us practicing agile have the advantage of delivering in short iterations which, at worst, won’t allow a project to go too long before the customer is back in the mix. But, even on agile projects, I’ve seen teams go through an entire iteration without giving much thought to the customer’s needs beyond the initial planning meeting. We think we understand exactly what the customer wants, can’t or simply don’t get continuous feedback from the customer during the iteration, and we develop the functionality. We become like the restaurant’s staff, who are so busy running the restaurant that they forget about the very people who really keep the restaurant running, the customers. Sure, the orders are taken, the food is getting out to people, drinks are refilled, new people are put on the waiting list, etc., but the customers aren’t satisfied, let alone happy. The software gets designed, written, documented, tested, etc. but the customers aren’t satisfied, let alone happy. Sound familiar?

Tonight was a good reminder that technical and operational excellence is critical to delivering a good customer experience, but if we lose sight of the customer in that process then we will fail miserably. We need to be diligent about keeping constant contact with the customer and focusing on the value we’re delivering. We don’t want our customers to walk away from us like my family and others did on the restaurant we attempted to eat dinner at tonight.

One Smart Cucumber

I was messing around with some Ruby stuff tonight and was reading up on the Cucumber project. Cucumber is a behavior driven development (BDD) testing tool.

Anyone who talks to me about user stories knows I’m kind of a stickler on the value statement.  I think I’ve found a kindred soul in Aslak Hellesoy, the creator of Cucumber. The following comes from the Cucumber documentation.

You should discuss the “In order to” part of the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:

  • Protect revenue
  • Increase revenue
  • Manage cost

If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.

Here is an example taken from an IRC chat session in #cucumber:

I was impressed to find that section in the documentation. Not only do the docs detail basic usage but they go into the deeper discussion of how to apply agile principles using Cucumber. The balancing act of teaching principles and practices at the same time is no small feat. To find that in software documentation is pretty amazing.

P.S. One of my worst titles ever, I know. I think I was subconsciously inspired by the Hallmark Movie my wife had on a couple nights ago. I now realize I missed my calling as a greeting card writer.

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.

This entry was published on January 6, 2009 under the following topics Agile

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.

This entry was published on October 30, 2008 under the following topics Agile

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

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.

This entry was published on August 18, 2008 under the following topics Agile