Thursday, June 25, 2009

Reality check for Agile projects- project management tool vs "no tool."

We all have an ideal view of the world surrounding us. That is OK as long as we are aware of the real world and know how to rationally deal with it. We as agile practitioners have our own view of an ideal world. I will talk about some of the "aspects" of this ideal agile world in a series of blogs. Last time I talked about "collocation vs. virtual collocation." This is second in the series. The topic is "project management (PM) tool vs. no tool." Interestingly enough, Mike Cohn recently blogged about an apparent conundrum of using a physical task board with a distributed team. Both of my blogs in this series are very relevant to what he talked about and the discussion followed it.

Since an agile team is expected to be collocated, general thought is why need a tool? Excel, physical cards, and boards are good enough. I hear people transitioning to Agile say-
"We are new to Agile, want to focus on the process, not the tool."
While I understand and appreciate the underlying intent, I find it difficult to understand why would using a project management tool get in the way of adopting Agile. It is to me same as saying-
"Well, we are new to Ruby on Rails, want to focus on learning the language, not an IDE tool."
I am sure teams that use a PM tool appreciate the importance of such a tool. For distributed teams, such a tool is essential, not optional. For collocated teams, here are a few reasons why you should consider using a project management tool,
  • A decent tool will allow you to focus on what you should be focusing on rather then wasting your time in managing artifacts (time, requirements, tracking velocity, bug, traceability- linking related items together etc. etc. ) manually.
  • Keep a trail of all conversations organized in the appropriate context even the conversations happen face to face. We all tend to forget the details we talk about. Later that comes back to bite us. A documented trail helps avoid conflicts (not to be used as finger pointing though).
  • You want to gain insights into your project so that you can do effective "inspect and adapt." Doing this manually will take away your time from your core responsibility.
  • You will get an audit trail of what happened for free. In some industries, it is a requirement.
  • If it is a client project, it can save you from legal hassle should such a situation arises. Yes, I know Agile spirit is about collaboration over contract negotiation. Remember, I said it is a reality check. In real life s**t happens even after all the good intentions from all parties.

I save the topic of what to look for in a decent Web-based project management tool for another day.

If you are not using a real project management tool (not Excel, Google docs, or even worse Microsoft project kind), please do yourself a favor and switch to a decent Web-based project management tool today. While you are at it, check out ScrumPad, the next generation project management tool. Please let me know what you pick for your team.

If you are still not convinced that a Web-based project management and collaboration tool is essential for the long term success of any development team, I would love to hear your side of the story.

Reality check for Agile projects- collocation vs virtual collocation

We all have an ideal view of the world surrounding us. That is OK as long as we are aware of the real world and know how to rationally deal with it. . We as agile practitioners also have our own view of an ideal agile world. I will talk about some of the "aspects" of this ideal agile world in a series of blogs. This is first in the series. Today the topic is "Collocation vs virtual collocation."

We all agree that face-to-face communication is the best. So much so that it has an explicit place in the Agile principles. However, we see growing number of projects have distributed teams for many reasons- outsourcing and offshoring, telecommute, multiple offices, lack of local talents etc. I think it is time for us to embrace the reality (as Agile was born from the realization of embracing the reality vs fighting it like the waterfall camp did) and update the Agile principle to say
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation in person or virtually."
Outsourcing and offshoring has become mainstream. It is here to stay for foreseeable future. It is elegantly explained by Thomas Friedman in his famous "World is flat" book. If you haven't read this book yet and want to understand the dynamics of today's connected world, I would highly recommend it.

Having a team distributed across continents is not any more a "tactical step," it is a "strategic need." Think where would Jason Fried and 37signals be without DHH, if it were not for "virtual collocation." There are many such success stories. If you are not open to working with the right talents irrespective of their location, you are at a great disadvantage compared with your competitors. Let me be a little blunt here- forget about competing.

In an increasingly crowded world, it is a growing trend for people telecommuting. Why would we require people to come together at a designated physical location everyday when a significant time and energy is wasted on the road? Why not we enjoy living in home town and being able to spend more time with family, yet have the opportunity to work on projects that could benefit from my skills and experiences?

Next generation (generation Y) are growing up in a virtual world (Facebook+SMS+Twitter+blog+iPhone). Virtual collocation is in their gene. They are forging lifetime friendship in this virtual world, coming together to support a cause, interacting on a daily basis as if they are in the same room. When they enter the workforce, they would not know anything different. In fact, they would prefer to work in companies where it is part of the culture.

So, agile practices should evolve to embrace virtual collocation rather than ignoring it, even worse resisting it. In fact, Agile is not at odds with virtual collocation. It is rather a necessity for distributed projects. There are many examples of successful adoption of Agile on distributed projects- large and small.

Yes, it is not easy to get it right. We may have to work a little harder to get it right. I would argue that getting communication right in a collocated environment isn't a cake walk either. Right communication is more than just being collocated.

I make a prediction here- in a decade or so most projects will have distributed teams. Collocation will not be a topic of conversation any more. 895gsubzpr

Tuesday, June 23, 2009

The most important software engineering practice

Continuous Integration (CI), hands down. I hope you have already heard the term if you are in anyway associated with software development. If not, I would highly, highly encourage you to read this article by Martin Fowler.

There are many practices in the Agile community, specially among XPers. Among those, TDD (test driven development), refactoring, and pair programming are other three most talked about practices aside from CI. Most of these practices have believers and non-believers.

TDD. Recently Uncle Bob preached TDD to all developers in his keynote speech at RailsConf 2009. Although I am a big fan of Uncle Bob and learned a lot from his writings over the years, I am afraid I have to side with DHH on this practice. Don't get me wrong. I like TDD, but I do not think it is a key to "clean code." Test first approach is not natural, it takes a lot of practice. Even then it may seem difficult to many developers. I am of the opinion that whether you write test first and then code or vice versa, you must write tests. But, follow what feels natural to you. That way you as a developer will have fun doing it. I agree with DHH that it is important that we have fun while writing clean codes. At the end, as a client/sponsor I do not care whether tests were written first or not, what matters is whether the software comes with comprehensive tests or not (code coverage). By the way, if you haven't seen Uncle Bob speak, you must. He is very animated speaker.

Refactoring. Although most projects/products go through refactoring at least once (if not more), it meets with resistance from all sides. Because, it comes with the connotations like low quality, incompetence, waste etc. Developers do not want to admit that their own codes need rework. The project managers do not want to ask clients to pay for something that is already done and working. The clients when hear "refactoring" becomes anxious thinking that the software that they are paying for is of low quality. The other end of the spectrum is teams can get overzealous and end up spending in this endless cycle of refactoring. So, it is difficult to implement "just enough" continuous refctoring that helps a team to maintain a sustainable forward pace on the project. When that right balance is struck, refactoring helps design to emerge/evolve as well as keep technical debt to a minimum.

Pair programing. One of the most controversial practices. I have to admit that I was a non-believer too until recently. My team has recently started doing pair programming and found it to be very helpful specially for refactoring type and complex works. It probably is not as effective for all types of work as well as every team. The most challenging aspect of adopting this practice is to justify upfront increased, however small or large, development costs and time and convince clients to pay for it. At least in the minds of clients, two persons working together on one thing at any time will look like they will be paying twice as much for the same amount of work and probably will take twice as long. It is a hard sell.

CI. It is the most accepted practice with very tangible benefits that both technical and non-technical persons can appreciate. If your team is not currently doing it, you should push for implementing CI immediately. If your team is already doing it, make sure you have the 10 elements mentioned in Martin Fowler's article. The diagram below shows the main steps involved in CI.



Most tools will generate Web reports and send email every time CI process runs. As a client, or PM, or manager, you would want to be on the distribution list for this report. Also you should learn how to read the report so that you understand what it means for your project. Even if you are not following Agile process, you can still benefit from CI.