Edge of Chaos

Yesterday Google alerted me about a review of TargetProcess  by Boris Gloger. I started reading this review and I couldn’t believe my eyes. How could Boris Gloger, such a respected Scrum trainer, overlook some important features of an agile tool he’s reviewing?

Writing reviews  is a very responsible task. It only seems that web can tolerate all. There’s no censorship, no security checks on whether the info in a review can be trusted or not. Reviews are about knowing all the facts. Only when you make sure that you know all of the subject matter, then you can write a review.  I’d never stand up as a guru and claim – my people, I’m your guru, I know all about this tool –  and then – ooops.. – I’ve got some essential flaws in my knowledge of this tool.

Now, let’s see what Boris Gloger overlooked. Comments on Boris’ page do not work(!!!), unfortunately.

Target Process is a tool created by Target Process Inc. to manage agile process. They can support Scrum, Extreme Programming, Lean and others. The tool have a good set of features and some nice ideas to speed up the addition of data for your project. They also provide a Eclipse and Visual Studio add-in so each developer can see their to-do list right on the IDE. If you like to try it for yourself there’s a 30 day free trial available.

Ehm.  TargetProcess comes for free not only as a 30 days trial. It’s free for small agile teams up to 5 people. It’s our humble donation to the growing agile community. Boris, it’s a fully functional free copy with free updates and subscriptions for agile teams of 5.

The “Features” works like an Epic or Theme for your stories and if don’t care for that it can be totally skipped. If you’d like to use it’s possible to determine an estimation and priority for the features but it really doesn’t make much sense to me.

The Features DO work like Epic or Theme and you can rename Features to Epics or Themes or any other name of your choice. The names are completely customizable and it’s up to you which name to choose.

I’d prefer to see something simpler like tags for the stories.

What??? We’ve got tags for user stories and for all the other entities! We’ve got bundles of tags. Tags board. Tags are powerful tools for categorization and filtering, so if I were a certified Scrum Trainer I would have quadruple checked before making such a blunt statement about no tags in any agile tool.

We talk about estimating feature so, of course we can estimate stories also. That’s the first problem i think the tool have, it’s only possible to estimate using time units, ideal or not. That’s no mentions to story points at all, this miss, pushes Target Process to field of time tracking tools, which is not a good thing.

Wrong, wrong, wrong. You missed the point with story points. They’re there, and you can choose between ideal time units and story points. This bold statement of no user story points in TargetProcess pushes you, Boris, to field of shallow reviewers that do not take enough time to study the agile tool they’re reviewing, and then spread this distorted knowledge to their students on Scrum trainings.

Target Process is supposed to work with different agile models, so they use the term iteration instead of sprint.

Foul and a miss. As I already mentioned, one can customize terms and rename the term “iteration” to “sprint” or whatever. TargetProcess is supposed to work with different agile models, so we’ve made our terms and processes completely customizable.

On the Taskboard there’s an awkward choice, there’s only two columns available Open and Done, where’s the WIP ? It’s on another tab Kanban Board, I really don’t understand why they went that way, but it’s no good at all.

Ugh. I really don’t understand how Boris could have overlooked such essential part of TargetProcess as customizable states and processes flow.  Two columns Open and Done on the task board are available for dummies. For advanced reviewers, all the states they want are available. Users can introduce as many states as they need to their development process, and they can give any names to those states. Kanban Board states are customizable as well. It’s no good at all that our honorable reviewer missed this..!

It’s hard to say what I think about Target Process, they had good ideas, like the shortcut flows, but really bad ones like the Kanban Board. Overall the tool is ok but not very intuitive, could be more polished on the user experience, and of course the common problem of too much focus on time tracking hurts a lot.

Boris, I promise you will not be that hurt as you take a closer look at TargetProcess. You seem to have some special inkling with too much focus on time tracking, that’s why you see it where there’s no special focus on it. Time tracking in TargetProcess is just in the right amount, no less, no more. IMHO, it’s rather less of it, than more.  As for user experience – draw the curtain… look in here :)

I read Agile development grows UP article written by Mark Lines. It has quite a strange taste… Is it an attempt to advertise new methodology? I hope it is, otherwise Mark is completely missing the point and agile development trends.

I want to review the article. Just can’t resist, sorry.

Many of us don’t have the benefit of co-location, where the entire team works in close proximity (ideally in the same room), with the user representative present at all times to answer questions

Sure we all know that a co-located team is better. It is not a surprise that consultants advise to co-locate team members. If you need to win the race, it is better to drive BMW M3 than Ford Focus. There are so many discussions around distributed agile this year. There are so many ideas and experience reports on how to implement agile remotely. Agile works in remote teams.

Pair programming i.e. 2 programmers sharing 1 keyboard is an expenditure most management will not endorse

It’s a very strange argument. Many managers will not support continuous integration, iterative development and BDD. It does not mean that these practices are bad. Context is everything. In some companies and on some projects pair programming will increase productivity. While on other projects there will be no benefits or even degradation. How many agile coaches insist on pair programming and say “You are not agile without PP”? Not many. It is wrong to spread this argument to the whole agile community.

Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes.

C’mon! User stories can be VERY detailed. For example, you may use BDD-style user stories format and write many cases that will describe functionality in some format, that can be directly converted to unit tests! It is an incredible thing, to be honest.

Fixing architecture as you go (i.e. refactoring) without some initial architectural design is not appropriate for large-scale enterprise systems

Most people in agile community believe that it is required to spend some time on architecture. Again, it is so context dependent. If you create a simple application, one day may be enough to nail down all important decisions. If you create a complex system, it may take several months. Common sense is a critical factor here. There is always a danger to over-architect things and working software is the best proof of concept.

Also something called “emergent architecture” is being developed. I like the idea and maybe it is a right direction.

Most projects are not completely independent and cannot be built in isolation. Dependencies and integrations with other systems are required and require some co-ordination.

Agile adoption is spreading rapidly and indeed there are no common/standard approaches to solve this problem. But I believe it will be resolved during agile enterprise adoption (and we already stepping into this phase).

Organizations usually have some governance practices in place (such as PMOs, ISO, CMMI) that necessitate a level of bureaucracy and documentation

Does it all mean that PMO, ISO and CMMI are good and we should give up and follow the rules? Agile community tries to fight bureaucracy and I personally love that. Documented process means NOTHING for success of software development project. In 90% of cases it holds you in the spider’s net and blocks creativity. There is NO software development without creativity. Wake up, Mark.

We live with these standards, but we should fight them.

Deploying software to users every 1 or 2 weeks is usually not practical in most organizations. Just migrating software through development, test, system test, user acceptance, production environments is a major undertaking. Having many projects trying to do this in parallel on a weekly basis simply isn’t feasible.

This argument is so common… and “not practical in most organizations” is a truly masterpiece. Any statistic data? Did Mark try to deploy anything outside the enterprise-scale Java mastodon applications world? Many SaaS services do painless weekly updates. Some services do painless updates on a Daily basis! It is unbelievable, but I like that. Customers like that!

Mark promotes OpenUP methodology (based on Unified Process). Only advantages in the post, no disadvantages or context at all. Folks, I think it is a so long-awaited silver bullet! Finally it is there! Let’s bury Scrum. Let’s bury XP. Let’s burn Kanban and all the other processes that spark agile movement. God bless the OpenUP silver bullet. Amen.