Edge of Chaos | Agile Development Blog

Since I started to work for TargetProcess and use the product for my daily working routine, I’ve experienced some problems. One of these problems was  navigation. All the links were grouped under sections in primary navigation level or administration level at the top. It took quite long to learn which group of links  should I select  to find some specific page.

The mind map of old navigation

Later I grew up to an experienced TargetProcess user as I’ve been testing new features or build every day but I still was mistaking the groups almost every time  (e.g. trying ‘Tracking’ instead of ‘Planning’ group when looking for Builds list).

Since navigation was the common pain we started to think how we can revamp its look and feel. We wanted it to be flat, customizable, easy to use and quick.

Wireframes

Complaints and requests from other TP users have been considered as we’ve been generating ideas for first wireframes:

We’ve been thinking if we should hide or show the whole group of links as on the screen below:

…and ended up with the concept of customization by links as we enabled users either to pin each single link to primary nav tab or to keep the link in ‘More’ group, create their own groups and rename the links:

All these wireframes emerged after long meetings, hot debates and multiple changes.

Concepts

As a result, by mid-January ‘10 we’ve had two different navigation concepts ready to be shown to some customers, members of TargetProcess UX group. We asked the customers to review two navigation concepts implemented as dynamic and static PDF and give us their feedback on both.

Here’s the first navigation concept:

1. One-level menu for quick system navigation.
2. Configurable tabs order.
3. Quick access to all pages grouped logically in “More” pull-down menu.
4. Easy-to-use advanced tuning mode.

The second navigation concept:

1. Two-level menu.
2. Configurable tabs with the possibility to re-group links.
3. Easy-to-use advanced tuning mode.

Most of our customers-UXers voted for the first concept and we went along with this design. Development of dynamic prototype was started simultaneously with the nav coding so we had usability test results available by the end of implementation.

Dynamic Prototype and Usability Tests

We wanted to run a usability test with our customers as early as we could and the interactive dynamic prototype for navigation was ready in a week (with IxEdit). The prototype replicated TargetProcess tool and was available on the web. Not like in the real web app, there were just screenshots with static pages:

In this proto users were able to navigate from page to page and to customize links selection for their primary nav menu. The only major thing at that time was re-ordering of pinned tabs which didn’t work in the proto.

Test scenarios were rather simple:

1. As we drastically changed the layout and re-grouped some links, we wanted to check if users will find particular pages easily with new navigation . So the first scenario was about simple pages browsing.
2. The second scenario was related to the customization of primary navigation level.

We asked our customers from the UX community to take part in the usability testing of new navigation, and four of them agreed. The testing was done via GoTo meeting.

Usability Tests Results

Based on the results of this testing, we’ve become aware of some areas in the navigation where users slowed down.

Most of the users who saw the nav for the first time tried to drag and drop links right away and guessed slowly that tuning and re-ordering tabs works in customization mode only. After customization was done, they forgot to switch customization mode off. Also we noticed that [Reset to default] button appeared uncalled, so it was removed in the final version.

That’s why we went on and tried to emphasize with different styles when navigation is in customization mode and when not.

Now the highlighted menu background under the button [Customize] shows that the button should be pressed to start tuning (customization).

That’s what one can see in the tuning mode (check the screen below):

• [Customize] button disappears; yellow background rolls up to the primary nav level where [Done] button appears.
• Only the primary nav level and  ‘More’ menu are active, content of the page is grayed out and disabled.
• Links selected for relocation in ‘More’ change their background from white to solid blue; mouse cursor changes shape to cross.

We believe that it’s hardly possible to mess up with the navigation modes now. The navigation is quick, one-level and simple for personal customization.

And - what’s most important - people like it as well. Out of many feedbacks, here’s just one from Igor France:

I have just installed the latest version of Target Process with the intention to start using it on my own projects (the company I worked for at the time didn’t adopt it) and I am again really enjoying using it! Apart from the positive things already mentioned, the main navigation itself in the meantime not only stopped being confusing but is now fully customizable as well!

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:

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.

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.

Hammer and Warm Wax

See Part I

.

Let’s take an average software project with full plan created up-front. It appeast that it is hard to support project plan in actual state using MS Project. It is hard to reflect real progress. But why? MS Project is great software, it should be easy. And it is easy in many cases, but not in software development. MS Project is useful when:

1. Project is very small (a month or two). But in this case maybe it is not required. Use Excel, make simple features list with estimates and that is it.
2. Project is very large and requires high-level plan. You may create very good project plan for Bridge building, Airplane or Space Shuttle construction. PERT is great in this case and project plan reflects phases, not tasks.

But most software projects have specifics:

• Average project duration is several months
• They change a lot and require fine-grained plans (”This feature will be implemented by two people. Joe will create GUI screen within 1d and Matt will program controller within 2d”).
• As a result, it is very hard to keep fine-grained plan in actual state for medium and large projects for WHOLE project life-cycle (the keyword is WHOLE of course).

No matter what tool you are trying to use. Most managers and executives improperly think that Waterfall requires such detailed plan somewhere in the beginning. Waterfall is not the best way for software development, but incorrectly understood and implemented it becomes a real pain in the neck.

You may say that MS Project is just a tool and all I wrote above do not directly depend on MS Project, but on methodology and process. I partially agree, but, once again, MS Project was not designed to support anything but Waterfall or its modifications. It is used for Waterfall and not so many people tried to use it for something else. MS Project + Waterfall = Hammer, but software development in most cases is not a nail, it is a warm wax. You can’t make anything but a flat from wax using a hammer.

As you see, there are plenty more reasons to find a better way. Let’s step back and look at another process.

Iterative Development

If we can’t have fine-grained plan for whole medium/large software project, let’s split it on chunks and create fine-grained plan for each chunk when it will be necessary. This idea is not new and called Iterative Development. Whole project split on iterations (exact iteration duration depends on many factors, but usually it varies from 1 week to 3 months) and iteration planned just before start.

This may sound astonishing for some executives. “So we don’t know project end date??? We don’t have a plan??? Our customers will not deal with our company! What the hell you are talking me?” How can anyone answer these questions? There are two ways to go.

On the first road there is no exact project end date and this road called Customer Satisfaction. You respect them, trust them and produce software they want. Feature by feature, iteration by iteration. Exact date of final release is not required since customer knows that you’ll implement as many features as possible based on defined priorities. It is real trust and it is quite rare.

On another road there are many signs with a big red “Deadline” in the end. While everyone wants to be on Customer Satisfaction road, most of us are on Deadline road in fact. This is a real world and, while we changing it, we have to drive some projects on this road. Can we apply iterative development? Yes, but with some restrictions, since there is less trust between developer and customer. Customer expects a fancy project plan, so we will create one, but low-grained. MS Project is good for low-grained plans. The plan will contain project phases and major milestones and, of course, it will contain end date. If customer asks why there are no tasks, you answer that you don’t like micro-management and fine-grained plan will be developed later. In fact, customer doesn’t care about exact plan, it does care about delivery dates and you’ve already provided them. Then you may break down each release on iterations and follow first road.

Some off topic. The other trick is to leave project/release scope flexible and this is really hard to achieve. It is harder than make a sculpture from warm wax with a hammer. If customer insists that he should get these features till that date without any deviations - you are in trouble. All you may vary in this case are people and process. And often you can’t vary people as well. So the process becomes a single life-saver for you and your team. While it is powerful life-saver, it may not help. Once again, do your best to leave scope or date flexible and focus on Business Value whenever it possible. If not, use iterative development anyway and try to release something useful as early as possible. Maybe customer will appreciate your effort, trust you and you slowly turn to Customer Satisfaction road.

“OK, we may use MS Project for low-grained plans. But what should we use for fine-grained plans?”

I can’t point Best-of-the-Best solution, but some important things that your tool of choice should do:

• Fine-grained plan for iteration should be visible and understandable for all developers without any restrictions
• Person who performs a task should track time spent on the task. PM shouldn’t ask everyone how many times he/she spent on this and that.
• Plan should be easy-to-change (no dependencies, easy re-allocation)
• Iteration status should be visible for all (and preferably tracked automatically)
• Iterative planning should be supported by the tool

In short, the tool should be opposite to MS Project, it should be strong in those areas where MS Project becomes frustrating.

Stop! I Can Plan Iterations in MS Project!

Yes, go ahead and try. You’ll quickly discover how it is useful for iterative development and how it is designed for iterative development.

I’ve planed iterations in MS Project for several projects and it somewhat worked, but this method lacks visibility. Developers don’t see plan and don’t see progress. You should update actual effort manually and assign tasks using Outlook.

How many features in MS Project you will use for Iterative Development? Gantt Chart, Resources and Tasks. That’s it. Tasks will be independent, so critical path is useless and Gantt chart is not very helpful. Leveling… OK, sometimes it helps, but in most cases conflicts may be resolved very easily for one iteration. Reports? Useless in most cases, but you may need something for executives. It appears, that MS Project is too complex and don’t bring enough value to justify its usage in iterative planning.

On the other hand, there are many features that you’d better have for iterative planning:

• Product/Release backlog. The main issue. If you use MS Project, you will have to store backlog in Excel or somewhere else and copy/paste features when required.
• Integrated time tracking. May be resolved programmatically and with help of MS Project Server, but this is an additional effort and MSP Server used not so often.
• Work remaining tracking. This practice is very useful to know actual iteration state. Can be resolved the same way as previous item.
• Iteration velocity concept. If you create an iteration in MS Project, Effort will be Iteration Velocity in fact. But you don’t have clear velocity progress picture

So you really may plan iterations in MS Project, but it will be not so simple and natural. MS Project just will not help you much.