Agile Development Blog / SCRUM, Extreme Programming, Tools, Tips

Jun 26, 2008 / Agile Tools. When is Whiteboard a Better choice than Software?

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.

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

Jun 23, 2008 / TargetProcess Free 5-Users Community Edition Available

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.

Labels: agile tool, community edition, free

Jun 11, 2008 / Software Development, Problems and Framework Solutions

Solving 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	Add Modules bundle Add required modules as tags into this bundle Set required tags when adding feature See all features grouped by tags in Tags area
We have several teams in a project and want to plan and track them separately	Add Teams bundle Add required teams as tags into this bundle Assign user stories and bugs to teams in Tags area Track progress in custom reports filtering by team tag
Your software really sucks! I can't even find all bugs and user stories related to Safari easily!	Add Browser bundle Add required browsers as tags into this bundle Set required tags when adding bugs and user stories Search by Safari tag and see all user stories and bugs with tagged with Safari
I played a little more with your software and I can't use it without relations between entities.	Search by required tag to see all related 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

Apr 15, 2008 / Should We Have Parallel Releases and Iterations in a Project?

The story began few months ago when we restricted creation of overlapping releases in TargetProcess. What does it means? People lost a possibility to create several parallel releases. The answer is pretty simple if you have several teams working on the same large project. Definitely you may have parallel releases and in fact each team may have own release schedule which should be approved/synchronized with other teams, but it may have different end date. It is not a mandatory to have all releases from all teams in the same day X.

But what if you have one team and one project? The main concern is something like that: “We are working on version 1.5 now, but we need to releases some patches for version 1.0 and also some people from our team working on version 2”. Sounds like a natural situation. Indeed we have to release some patches with bug fixed as soon as possible since it affects current customers and they need resolutions right now. Indeed we are developing new version with defined set of functionality. And hey some our gurus started prototyping several killer features that are not will be a part of version 1.5, but may be released in version 2. All it may look reasonable. Isn’t it?

Well, the simple answer is no, it isn’t. Let’s dig into details. For example, we have a team with 6 developers (skip QA and other team members for simplicity). You have 1 month releases schedule. You have defined scope for release 1.5 and some features for release 2. You know that you should also release 2 or 3 patches during this month for version 1, but the scope of the patches is undefined at the moment. How will you plan the release(s)? “OK, Joe, you will work on patches when some important issues will be reported by customers. But till that time you may work on Feature X for release 1.5. Mark, Beth and Teddy will take all other features from release 1.5. Also we have some very important and complex features that planned for version 2. We should mitigate risks and prove the concepts right now. Tom and Jerry will work on that”. What we have in the end?

Joe belongs to both releases. Other people do not have multi-tasking. Everything looks good. In reality we may end up with some bad things:

Some issues assigned to release 1.0.x are hard to fix and Mark will help Joe to fix them.
Joe spent too much time on bug fixes and unable to complete Feature X on time. So it will be required to exclude the feature from release 1.5 (or call someone from release 2 to help Joe).
Beth’s feature appeared to be more complex than expected. Again two options (drop it or call for help).
Jerry did not finish his work for release 2, since he was helped Beth and Joe in release 1.5
Tom did all fine, but in the end it appeared that customer decided to drop the feature from the release 2 at all and replace it with another feature.

I agree that all above sounds pessimistic. But didn’t you have similar problems in the past?

Now we have 3 people with multi-tasking and all Tom’s work out of context (he did not add any value to the releases). Obviously, our plan failed. Why? We violated some core principles of agile development:

Make decisions as late as possible. In fact Tom and Jerry’s assignment to release 2 was a mistake, since the release 2 will happen next to release 1.5. Important addition: It is OK (and even recommended) to proof all possible concepts before project start or in release 1.
Reduce Work in Progress (WIP). The more WIP you have for given resources, the later you will release something. If we have 10 user stories and all of them will be in progress, we will have waterfall process in the end. We will have 90%-done problem and all related risks.
Avoid Multi-tasking. Something related to point 2, but with such plan we really increased multi-tasking. Depending of context it may be better to assign Joe full time to Release 1.0.x (if you are struggling with de-motivation problem, you may just rotate developers for patch releases for example).
Avoid 100% people loading. You may want to load all people 100%, but that’s a mistake. People should have some free/spare time. It is a proven fact that 100% load decreases productivity/throughput. So if you assign Joe to release 1.0.x and he will do nothing 1-2 days that is not a problem. He may do some minor refactoring or some minor bug fixes. But he will be available just in time when first issue request will be received.

Is this plan better?

Well, maybe. We eliminated all work from Release 2, which is good. Could we eliminate work from release 1.0.x? Probably, if fixes are not very important and may wait till release 1.5 availability. And often they can! Most likely you will have several fixes that MUST be released ASAP. It may take 2-3 days from one of the developer to handle them.

Turning back to TargetProcess ask me a question “Will you make it possible to have parallel releases in a single project?” I am answering “Yes, we will”. In reality things are more complex. You have pressure from top management who knows nothing about lean and agile and you gave up explaining the reason behind one release at a time and 100% people load problem. You have a large team inside one project and want to separate work with releases (why not?). You have maintenance releases and want to track them separately (why not?). Maybe there are more cases. Real life is complex and teams are learning doing agile.

Labels: agile, parallel releases, planning, release planning

Apr 1, 2008 / TargetProcess Announced Integration with Microsoft Surface

It looks like a magic, but soon it will be possible to manage projects using TargetProcess on a very cool Microsoft Surface table. Releases and iterations planning using drag and drop with usual human hands and fingers (throw your mouse and seal up your touchpad), nice sorting and grouping, fantastic user interface and experience!

"Microsoft Surface brings real tactile feeling into software world. You may operate with entities using hands on a table, almost like with usual cards. You may take a bunch of user stories and throw them to release. You may drag the slider to move release date. You may give a flick on user story to delete it! It really sounds like a miracle. I think such experience is a huge step forward for whole software engineering industry.", commented Michael Dubakov, founder of TargetProcess, Inc.

We are creating new appealing user interface with really handy functionality and unsurpassed usability. Stay tuned and find additional details here!

Mar 18, 2008 / We Have Released TargetProcess v.2.8

Enjoy Customizability: Plugins, Bugzilla Integration and Custom Fields per Process in TargetProcess v.2.8.

Mar 7, 2008 / TargetProcess On-Demand Won Second Jolt Productivity Award

TargetProcess won second Jolt Productivity Award, now in Project Management Tools category!

Jan 9, 2008 / Should We Measure Individual Estimates Accuracy?

Individual estimates accuracy is another metric requested by several TargetProcess users. First of all it may be useful if and only if:

Task estimated by one developer only (if whole team estimates tasks you can’t measure individual accuracy, only whole team accuracy).
You are using time tracking to track all spent time for all tasks

For example, Ted subscribed to Quick Search user story. He broke down this user story to tasks, estimated each task and got 50 hrs of effort for user story. Then he implemented the user story and spent 60 hrs. It means his estimate accuracy for this task is 50 / 60 = 0.83 or 83%. In the end of iteration we can calculate all Ted’s assignments and spent time and define estimate accuracy for next iteration, let’s say it is 0.7.

OK, but how we can use this metric? Well, if Ted subscribed to 60 hrs work it means he will spend 85 hours and for 2 weeks iteration it means at least 5 hrs overtime. Ted should take this information into consideration and remove some tasks from his ToDo. This works if Ted estimate accuracy remains the same, but is that always the case? In reality Ted’s accuracy may vary from 0.5 to 0.9 and exactly for next iteration it may be 0.9 and in this case Ted will be able to do all committed work.

As you see estimate accuracy coefficient should be used as a recommendation only, but if Ted insists on his commitment Project manager/Scrum master should agree and let Ted do the job. Again we have similar problem as with individual velocity when Scrum master may demotivate developers with numbers in hands.

I see value in individual estimates accuracy, but I see some danger as well. This metric should be used by developers, not by Project managers/Scrum masters.

I think we should care about team estimates and team velocity, not about individual estimates and individual velocity. Agile development is all about jelled teams.

Labels: agile, estimate accuracy, metric

Dec 26, 2007 / Should You Measure Individual Velocity?

We are receiving more and more requests to add individual velocity measurement in TargetProcess. People want to see this information and use for iterations planning. But is it required to measure individual velocity? What caveats such calculation has? It may be not clear initially, but there are some problems with individual velocity for sure.

What is an individual velocity? It is a measure of how much effort a person may complete in a defined time frame. In agile development time frame is an iteration. If Ted completed several tasks with 40 hrs of effort in total and Jerry completed tasks with 25 hrs effort only, we should say that Ted has better velocity in last iteration. Does it mean that Ted is a better/faster developer? Not at all. There are hundreds of reasons why Jerry completed less. He helped other developers with tasks and mentored them; he got serious headache during two days in a row and did almost zero progress; he had two birthday parties last week and his performance was no good next day after each party; one of his tasks was underestimated due to unexpected performance problem with third-party component. We can bring many more reasons on the table. Performance in last iteration says nothing.

OK, but what about average velocity? Surprisingly, Jerry’s average velocity is 54 hrs per iteration. Gosh! What happened with Jerry last two weeks? Will his average velocity help us to make correct iteration plan? If we sum up individual velocities all developers will it help us to create a better iteration plan? No, since we already have Iteration Velocity metric and it will be exactly the same. Why should we care about individual velocity in this case? To make better assignments for each person? But we still don’t know how much effort Jerry will complete next iteration. The good guess is from 25 hrs to 60 hrs. Is it helpful? Maybe, a bit. Is it worth the darkside of the individual velocity measurement? And sure there are some problems with it.

Individual velocity measurement has wrong focus on individual performance. The focus should be on team performance, individual performance is not important. If Jerry knows that his velocity is measuring, he maybe will not help other team members a lot. He will focus on his performance as an individual developer. The worst thing company can do is to bind bonuses to individual performance. This nips teams in the bud. The right solution is to measure team performance, but in agile development we already have team performance metric, it is a well-known iteration velocity - very good, very simple and very helpful metric that enough for iteration planning. Individual velocity will not bring additional benefits there.

Individual velocity measurement forces work assignment, while in agile teams it is all about work commitments. Team should do a commitment to complete as many user stories as they feel can be completed during next iteration. On iteration planning meeting Jerry may feel bad about his poor performance in last iteration (yes, developers know their performance without measurements) and will commit to 70 hrs work items in total and complete them all with courage. If you measure individual velocity you tend to assign stories based on numbers you have in hands. “Hey, Jerry, are you kidding? You did only 25 hrs last iteration, how are you going to do 70 hrs?” It is good if Jerry has courage to answer something like “Just believe me, I will do that” and project manager/Scrum master agrees and allows Jerry to make such commitment. But Jerry might think “oh, he doesn’t believe me… Well, let it be, I will take 50 hrs, it is close to my average velocity”. Individual velocity may demotivate people, and many managers having it in hands will use it incorrectly. It is very common to revert back to muscle memory of waterfall days and make assignments instead of commitments (especially when your project is in troubles).

I don’t see much value in individual velocity, but I do see many problems it may cause (or hide, or support).

Labels: individual velocity, metric, performance, velocity

Nov 30, 2007 / Failure Rates In Early Stage Venture Deals

No, we are not seeking for VC, but still it is interesting to know success/failure rates for Venture Capital.

read more | digg story

TargetProcess. Agile Project Management Software