Jun 26, 2008 / Agile Tools. When is Whiteboard a Better choice than Software?
3 commentsPeter 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.
|
Category |
Weight |
Simplest Tools |
Web-based Software |
Spreadsheets |
|
Planning process |
3 |
4 - Tangible and exciting |
3 – simple, but less exciting and visible |
2 - doable |
|
Plan visibility |
2 |
2 – good for the team, poor for execs |
2– good for execs, poor for the team |
1 – poor for all |
|
Plan update |
1 |
3 – re-stick some notes |
4 – several clicks, from anywhere |
4 – move some rows or mark them for release |
|
Velocity tracking, Time tracking |
2 |
1 – manual, asking each person |
4 – automatic |
2 – manual, asking each person |
|
Burn Down Update and other charts update |
1 |
1 – manual |
4 – automatic |
4 – automatic |
|
Communication |
3 |
4 – just great |
2 – exists |
1 – no |
|
Reporting |
3 |
1 – poor reports since all data offline |
4 – almost endless reporting capabilities |
3 - good reporting capabilities |
|
People involvement |
3 |
4 – everyone involved |
1 – may become a problem |
1 – may become a problem |
|
Cost |
2 |
4 – almost free |
1 – may be quite expensive |
4 – almost free |
|
|
|
|
|
|
|
Total: |
|
57 |
52 |
43 |
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.
|
|
No Status reporting required |
Status reporting important |
|
Small Collocated Team |
Tangible tools |
Mix of tangible tools and web based agile tools |
|
Large Collocated Team |
Mix of tangible tools and web based agile tools |
Web based agile tools |
|
Remote Team |
Web based agile tools |
Web based agile tools |
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.
Labels: agile tool, card, whiteboard
posted by Michael Dubakov @ 1:02 PM
Jun 23, 2008 / TargetProcess Free 5-Users Community Edition Available
1 commentsWe 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.
Labels: agile tool, community edition, free
posted by Michael Dubakov @ 3:28 AM
Jun 11, 2008 / Software Development, Problems and Framework Solutions
0 commentsSolving problems! Most of us would agree that is the ultimate goal of any software. It is especially difficult to create a tool that resolves several large problems. For example, effective project management is a huge problem that may be split into several smaller ones such as: easy planning, effective tracking, quality assurance, etc. What makes it extremely difficult is companies’ diversity. There are a lot of businesses with unmatched variety of processes, goals, people, cultures, tools and environments.
OK, we at TargetProcess have a niche, by supporting companies on "agile" road. However, we still face too many differentiators that need to be satisfied.
Some people want Gantt charts and Start/End dates for their tasks. To such requests we have been consistently saying “No”. Others want better high level planning, improved time tracking, easier UI, – the list is endless. We can't say “No” to all of them, since many of such requests are quite reasonable and most importantly - solve real-life problems. However, we can not add requests blindly into the Product. If we did, we would create a "bloatware scary monster" and people would start running from it.
What is the solution? The solution is to provide frameworks for solving problems. Sounds weird, but here are some examples to support this point.
Example 1.
Requests: "We badly need a report that includes all features, stories and bugs for current release", "I want to have a quality report that shows count of passed/failed/not run test cases for each user story in current iteration", etc.
You get the idea - people want and endless array of reports. One solution is to start implementing these reports as they coming — one by one. We feel the better yet solution is to simply allow people to build such reports without our help. Powerful reports engine resolves these types of concerns in a single hit. Moreover, people are creative and once familiar with the approach - will start to produce very useful reports that address all of their needs. The key is to make them feel in command and provide necessary tools!
Example 2.
Requests: "We want to group features by module! How come you don't have modules in a project?", "We have several teams in a project and want to plan and track them separately", "Your software really sucks! I can't even find all the bugs and user stories related to Safari easily!", "I played a little more with your software and I can't use it without relations between entities."
Did you get the problem? It is not an easy guess. They all look like different problems. Straightforward solution may include:
- Module entity in a project.
- Multiple teams concept implementation, including changes in relations, reports, etc. (will complicate product a lot).
- Custom fields for several entities at once.
- Dependencies between entities.
Wow, it will take time to implement all of the above features. Scary part is that these requests are just a tip of an iceberg. After implementation we will more likely receive even more "related" requests. Is there any magic bullet that hits all the targets in one shot?
Yes, there is! OK, all the requests are about categorization and relations. Categorize by module, categorize by team, categorize by browser, see all related entities that have the same value in a defined category. And the real solution is to provide an easy and flexible categorization. The answer is... tags and bundles! Let's see how all the problems above may be resolved with tags.
| Problem | Solution |
| We want to group features by module, why you don't have modules in a project |
|
| We have several teams in a project and want to plan and track them separately |
|
| Your software really sucks! I can't even find all bugs and user stories related to Safari easily! |
|
| I played a little more with your software and I can't use it without relations between entities. |
|
Common solutions for different problems. Tags and Bundles is a framework that will resolve almost all categorization problems. And be sure that people will find creative ways to solve other problems as well. If it is possible to plan with tags, I can't even imagine what tags will be used for (in a good way).
We at TargetProcess are trying to provide frameworks rather than straight-solution-to-one-problem. The latter approach works exclusively for the stand alone problems that cannot be grouped with similar issues.
Generalization mindset is a must in Product development, but beware premature generalization.
Labels: problems, reports, software development, solutions, tags
posted by Michael Dubakov @ 7:35 AM
