Edge of Chaos | Agile Development Blog

New Year time is the time when people give resolutions and are particularly enthusiastic about keeping up to their resolve.

One of TargetProcess resolves for this year (another resolve is our roadmap for 2010) is coming up with more blog posts. We promise to keep up feeding  practical and insightful content!

Since everything around is all about newness at this time, let’s think a little bit of how we approach new tools that we use in our work.  Say, you want an agile project management tool, like TargetProcess, and you’re certain that you know very well how to manage agile projects, so all you need is just a tool that would replicate your model of management.

There you go: you sign up for a trial, you start looking at a tool, you take time to see what and how works in there, you discover that this tool is very customizable, but in some cases the tool does not do things the way you do them.  That’s the point where you can submit a feature request and give up, or that’s the point where you can thoughtfully look at the way you do things and see if probably the tool guides you and allows you do agile project management in some better, more lean, more lightweight way?

Imagine that you have an axe but you’re totally unaware that hammers exist in this world. You’re used to fixing nails to their place with the rear part of your axe, and you have no idea that there’s another tool that allows you to do the same task with the same goal — that is, to put the nails where they should be — but in an easier and more straightforward way.  So, when someone hands you a hammer — you look at it and think — how do I use this thing to fix the nails? This tool doesn’t chop wood at all, it has no blade, no powerful rear part — it’s just a small piece of  iron (remember, you’re a man with no idea about hammers, this might be difficult to imagine ) Then someone shows you how to hammer nails. You see that hammer is definitely much better for this task.  A hammer head is well-balanced against its handle and it allows to put nails in place with more control and precision as opposed to a heavy axe head.  Then you understand that this new tool does things in some new way that you haven’t known about before. And you like that new way — you grab the hammer!

Sometimes, however, hammers and axes are mixed into one monster like this one:

axe&hammer

You might choose to go and worship the monster praising its versatility. It’s really a fine line between following guidance of a tool that suggests more practical way of accomplishing your tasks and worshiping functionality of a monster, sacrificing your working process and taking time to learn the tool just for the sake of the tool itself. You do learn something new, but is it worth while to nurture a monster, when you can take hammer for hammering,  axe — for chopping wood, and see if you probably need to add a saw, pliers and drill to your set of tools?

The message is: whenever you need a tool to do whatever you need to do, watch out for monsters eating up your work and effort just to learn how they work.  At the same time be open to looking at things from new, unknown angles and don’t stick to old schemes. Who knows,  maybe the tool you’re trying out right now will help you build your ideal working process.

I am really glad that finally we released v.2.14. Check the press release: TargetProcess Announced v.2.14 Release With Full Waterfall Support.

As you probably know we at TargetProcess develop agile project management software. We have a free community edition that is becoming popular and have about 1300 downloads already. People who request the free edition or trial provide comments. Sometimes these comments really disappoint me. Especially if I see comment like “I hope this community release help me dive into scrum. Thanks.”

What’s wrong with it? Well, I don’t know any software tool that can help understand the agile process better. If a company starts SCRUM implementation or any other agile process implementation we do not recommend to start with a tool. Hire agile coaches, read books, try simplest tools like whiteboards and sticky notes, visit conferences, try best practices, and learn! Do not invest into any software tool till you feel the need.

The team may be distributed, or large, or needs real-time progress reports desperately, or anything else. But the team should try to operate with simplest tools first. And focus on live communication. It is the only way to “feel” agile spirit. It is the only way to dive into agile.

Do not rely on a tool. It may help to resolve some problems. It may even help a lot if you have a distributed team. But it may dictate or recommend some best practices, project structure, process structure and the way how you develop  software. That is something to avoid in the beginning of agile adoption. The team should invent their own best practices,  project structure,  process. With this in hands the team can decide to use a tool to resolve real discovered problems.

Agile PM tool is not a silver bullet after all. Do not rely on it blindly. It should adopt to your development process, not vise versa.

Peter Stevens has interesting posts about different agile tools. In this article we will find out whether whiteboard can beat software tools.

Let’s assume that we have a large and shining nail. What is the best tool for the nail? Hopefully, the answer is obvious for the most of us. Now, let’s assume that we have a development team and a “shining”, promising, cool new agile development process. Most likely the hammer will not help (well, perhaps, but certainly not recommended, as a surprise weapon against irresponsible team members who ignore daily meetings).

To tackle this problem, it is essential to have at your disposal a tool that enables requirements gathering, iteration planning, progress tracking and reporting. You can’t rely on memory for requirements gathering, you can’t rely on the universal perception for iteration planning and definitely you can’t rely on telepathy for progress tracking and reporting. You need a tool that will do the job with minimum effort and minimum side effects.

There are two approaches: simplest tools (I mean index cards, whiteboards, etc… no hammer or nails) and software tools. Some people think that index cards and whiteboards are the only possible tools for agile development and all the other tools jeopardize communication in a project team. Some people laugh just seeing a photo of a burndown chart sent by email as a weekly progress report. Obviously I shall say that there is no silver bullet, environments are different and grass is green. Let’s try to find out if the grass is truly greener on the other side by subjecting tangible tools and software toolkits to a comparative analysis.

If you ever tried Extreme Programming or Scrum, you would be familiar with the simplest tools commonly used for the fine-grained short-term project plans creation and progress tracking: Index Cards and Big Visible Charts. These tools have one major advantage over all others’ — they are tangible. You can take an Index Card and move it into another place. You can stick Tasks on the wall thus creating fine-grained plan. Then you can take a marker and draw a new segment on a burn down chart. Sweet! Whiteboards, markers, post-it notes, index cards, board magnets, paper and scissors — many people love to use them. It is entertaining and you have more reasons to get your butt out of the chair.

However, tangible tools do have some significant limitations. For one, no matter how big Visible Charts are, they are still visible to project teams only! Executives should visit the room to see the plan or check on the progress. When was the last time your CTO dropped by? Time tracking and remaining time calculation is manual and someone should update the charts. And for remote teams this approach will simply not work.

Let’s try to compare simplest tools with the web-based tools for the collocated team. Some areas are definitely more important than others. Obviously, communication is more important than fancy plan update or automatic time tracking — therefore we’ll use weights to assign relative values. There are three weights (1-3) and four scores:

1 - Poor

2 - Average

3 - Good

4 - Great

The formula is quite simple: Category score = Weight * Score.

Total score is just a sum of all categories’ scores. In the end we expect to have some numbers that we will use in our analysis.

We have 56 for tangible tools, 52 for web-based software tools and as little as 43 for spreadsheets. Are you still using spreadsheets? Although the above scores are somewhat subjective, it is still clear there is a better way than spreadsheets or other tools not designed for Agile! The totals show that you are better off taking a trip to Staples and getting post-it notes, index cards and markers. If you decided to choose software route, visiting www.targetprocess.com and getting the best agile project management software is certainly another option.

Tangible tools are more preferable for agile processes — use them if you can! But remember, that it remains the case for collocated teams only! It is impossible to use usual tangible tools for remote teams. Remote teams hardly can share whiteboards and task boards. They need more formal processes and more formal tools. Agile offshore development is there and definitely is better than traditional waterfall process. More and more distributed teams use agile development processes successfully and that is the fact of life. What should you use in this case? Obviously, web based software is a great tool for sharing knowledge, project state and other project information. It coordinates remote teams nicely.

In fact, there are some guidelines that you may think about when reviewing the comparison table.

You should prefer White Boards, Cards and Markers if:

• You are trying Extreme Programming or Scrum for the first time (that’s important).
• Team is collocated.
• You tried simplest tools, achieved great results and don’t feel a need to change anything.

You should prefer web-based software tool for project management in agile projects if:

• You have a distributed team (offshore development).
• You have large collocated team (20+ people).
• Your executives need status reports and without them would not accept the agile process (”OK, if I can see real-time project status somewhere, you may try XP/Scrum/Lean”).
• You tried simplest tools and for whatever reason they did not work in your environment. (In that case, you should try to define exact reasons for the failure. Perhaps, there are communication problems or something else that can be fixed).

We may combine results is a small matrix.

Another important question is how can we alleviate potential problems that may arise with web-based tools for project management in agile environment? Some thoughts:

• Focus on communication and collaboration. Do not think that email is OK and enough. It is just not true. Use Skype, use web cams, whenever it is possible — travel and meet in person. Try to break the borders in all possible ways.
• Plan iterations as usual — using cards! Enter data into the system at the completion of the planning game.
• Integrate information radiators with software. For example, you may bind Ambient Orb to project status. It will be green if everything is OK and red if iteration is in trouble. You may print out iteration plan on A3 paper and stick it to the wall.

I think agile software vendors (and TargetProcess as well) should invent new ways to support communication using software and tangible devices. I truly believe it will happen in the very near future.

We are excited to announce the availability of the Free Community Edition of TargetProcess!.

You may request and download On-Site version with 5-users licenses included.

The amazing thing is that the Community Edition has no restrictions at all! It is a full featured version (yes, you have ALL features included: integrated bug tracking, test cases management, subversion integration, time sheets, Web Services API, etc). Moreover, Community Edition has no expiration date - it is simply Free…forever!

We hope that TargetProcess Community Edition will help you to move your Agile development forward.

I’ve manage one small project (3 developers - 6 months planned). Project was canceled due to some reasons (project progress was great, so the reasons are not in development :-). I briefly describe here what we’ve tried and what was useful for us. I think this information will be interesting. This is a real example after all. The project was on Perl.

XP-style Planning. Small 2 weeks iterations. Small iteration helps to track project progress and create better estimates. Planning is quite easy and can be done in Excel without sophisticated tools like MS Project. We are going to use XP-style planning in future for high-risk projects (with new technologies, new team, or whatever make project risk high). Sure, web based tool for XP-planning can help.

Customer Feedback. Manage a project without client representative is a hell on the earth. You are working like in a vacuum. No response, no feedback and no attention. You can’t establish rapport with a client, and there is a chance that system will not satisfy client expectations. And sure it won’t. Project Manager must make every effort to get a person from the client side for the constant feedback.

Info for Top Managers. All information for top managers should be in a short and clear form. Do not send 20 pages requirements docs or lengthy emails. Top managers do not have enough time to read such docs. It is better to extract most important features and ideas at a single page and attach full document to be on a safe side.

Phone Calls. Phone calls are much better than emails or IMs. Sure, phone is impolite and it is hard to clear express your thoughts, but, anyway, phone is better. Many issues can be resolved faster and easier.

Test-Driven Development. We wrote unit tests for all business objects before actual code, and it worked great. However, we did not have tests for controllers. Controllers are very close to GUI and they changed often (during first month). Maybe we should write unit tests for controllers as well, maybe not. This is unclear. Anyway, TDD is good and we will use it as a mandatory practice.

Acceptance Tests. About 50 tests were created based on SAMIE. We modified tests quite often and spent near half an hour hour per day to keep ‘em working. These tests helped a lot when we performed major refactoring in controllers and GUI layers. But it seems that SAMIE is not the best tool for acceptance testing. It is easy to use, but sometimes unstable and Win32 restricted. But I did not find a better one so far.

Refactoring. It helps to reduce code duplication and keeps system architecture clear. We had doing refactoring constantly, and sometimes we spent whole day on major refactoring. As a result, new functionality implementation appeared easier than we expected. We will use refactoring as a mandatory practice in future.

Walking Skeleton. This is a first, fast and small release, which contains single system feature ‘in depth’. For example, show projects list, add project into the database, check user permissions on project. Walking Skeleton for the system took near 2 weeks. We managed to investigate many architectural decisions and choose the best. Small and fast release is a great thing.

Pair Programming. We created the most important system modules in pair. The code quality and overall system architecture appeared significantly better when pair programming used. Constant code review, communication and experience sharing are really great things. It is not easy to program 7 or more hours in a row, and you feel exhausted in the end of the day. But work satisfaction is great. We will use pair programming for teaching, experience sharing and critical modules implementation in future.

Code Metrics. LOCs dynamic, Unit Tests # dynamic, Acceptance Tests dynamic. Code metrics helped to track project progress and predict team velocity and project size.

Project Site. Helps to organize important project related information (news, documents, actual project state, links) in a single place. However, Project site update should be more simpler. For example, we can use a basic CMS for project site maintenance in future.

O/R Mapping. Tangram was used as an O/R mapping tool. It took about 2-3 days to resolve some tricky issues, but in general O/R mapping speeds up development and supports database abstraction. Maybe OODBMS is a better solution, but if you stick to RDBMS, O/R mapping will help. However, for small systems or web sites O/R mapping is not required.

System Prototypes. Helps to resolve many issues on the early stage. In general, the prototype should be created if project budget allows to do that. But I do not recommend to create a comprehensive prototype, since it just wastes time. Prototype should contain major system modules and maybe some secondary.

Honesty. Just be honest with your teammates. They will trust you, and trust is one of the major factors for jelled teams.

Documentation in Source Code. Almost all system architecture related documentation was in source code. We used a tool to build linked html pages from POD documentation. As a result, documentation maintenance was easier.