Bruno Miranda's Notebook

Here is something that may be crippling your agile project/team if you are not yet practicing it:

Story Based Customer Reviews

During the engineering meeting (you do have one of those right?) stories are assigned and to developer/s and prioritized. The developer must go back to the customer and obtain the requirements/specifications for said story (but that you already knew).

Once the developer has working code the must take it back to the customer for review and feedback. This is a crucial step that if skipped will hinder the process, delay stories and result in incomplete iterations. When an iteration is not fully completed due to reviews and feedback from the customer after the end of said iteration the entire project timeline will suffer.

I can’t emphasize how important getting customer feedback as soon as possible within the iteration is. Our team is partially distributed and so are our customers. After the request for feedback has been initiated, which is typically done by e-mail, the developer moves on the next story. Due to customer availability the feedback may take 2-3 days to come back at which point the developer has time to make necessary adjustments and is just about ready to submit the next story for customer review – keeping the project moving.

We have created a new state for stories in our PM tool called ‘Customer Review’. The predecessor state is ‘Open’ and from ‘Customer Review’ it will go to test (QA), with the requirement of the customer acceptance comment.

Open -> Customer Review -> Testing -> Done - > Done-Done

Done-Done happens after the iteration demo.

Have you ever second guessed yourself when talking about rewriting a large piece of software? Most will argue that rewrites are a bad idea. Usually these initiatives are chosen to remedy software that is full of technical debt, or when unnecessary or half implemented functionality composed the majority of the code-base.

In my opinion rewriting a piece of software is awesome, it gives you a chance to start fresh. Why so many advise against it? Because you must first fix the root cause. The reason you have technical debt is almost always because of a broken process. The reason you implemented something that no one will ever use is almost always related to poor business owner <-> developer communication. If you don’t fix the process before you rewrite, you will end up with yet another technical-debt filled application. Your team members will certainly be more frustrated. Stakeholders and managers may lose faith and your life may continue to be a living hell.

Fix your process, then fix your your code. Implement a process that makes sense, which is not always easy to follow. Make sure you follow it. Stay as close as possible to the business owner, he who holds the keys to the application’s features and their acceptance criteria.

Albeit somewhat obvious, avoid the “cave mode” like the bubonic plague. Software writing should be an open process between stakeholders and development team. Gather feedback early, make sure you are on the right path. Don’t assume you are in the right path. It is better to know you are on the wrong path than to think you are doing it right.

There is no conclusion to this post, as software processes are ever-evolving, so are the conversations about them.

Remedy before you go bananas.

At Todobebe we have adopted one of the Agile methodologies commonly know as XP (Extreme Programming). I remember a couple of years ago seeing a book called “Practicing Extreme Programming” and giggling to myself with the thought of “Isn’t programming extreme enough already, what’s next? Programming martial arts and a The coding black belt?”. All jokes aside, I really thought it was some sort of crappy idea by a big corporation like Microsoft or Sun. Little did I know had I picked up that book and studied it at that time, I would’ve been at a much better place to help my team during the past couple of months.

The principles of the extreme programming methodologies are fairly simple. Have the customer (he who holds the stake) in the room to decide which stories go in the current iteration. Complete stories (specially formatted requests) with the direct guidance of the customer. At the end of an iteration, conduct a retrospective, see what you can improve upon and repeat. There is also the concept of having managers, developers, customers and testers in the same physical room, which is not always feasible for non co-located teams.

XP definitions aside, with the methodology comes the need for a good electronic tool to aid in the management of stories, iterations, releases, retrospectives and of course, the beloved (by some) reports.

After some research we settled for Tracker, Pivotal Lab’s Agile Project management tool. It is a very simple tool, easy to learn and use. Composed of one main screen holding multiple containers for Done, Current, Backlog, Icebox, Search, etc. You can show/hide them as you please, the interface is snappy, ajaxy and usable (want any more cliche words?). You can drag and drop items between the buckets, quickly assign points and the system automatically calculates your future velocity. There is also a ton of other little features that I won’t mention here for the sake of brevity. Tacker is free at the time of this writing.

Pictured: Tracker

We have been using Tracker for about 10 weeks and it has been working fairly well. Our team is growing, and we have started to realized Tracker’s shortcomings. There seems to be no easy way to transfer stories between projects. Also release planning is very elementary, the interface does not help with this particular agile practice. Reporting is a bit deficient and time management is limited.

Since then I have done a considerable amount of research regarding Agile tools. Many players, a large array of losers and a few contenders. The last bucket included ThoughtWorks’ Mingle, a very expensive and complex web app, VersionOne a java web application both available as SAAS and self hosted, and lastly TargetProcess.

I have put together a comparisons table containing pros and cons for each application and their scoring categories suited for our needs. Your needs may vary but it should be a fairly good starting point.

Mingle is not available as a hosted solution. You must host the big boy on your own server. At first glance it was a bit disappointing, it seemed clunky, slow, and it requires 2GB of ram on the server to run well. Even if you go with an economical option like Linode you will be looking at a $200 monthly hosting bill. Mingle offers the first five user licenses for free, after that, it will run you $60 per month per user. The application also felt bloated, and not easy to understand at a first glance. Every time I tried to get into it, my eyes kept glancing over all the options. Mingle does have a really cool looking story card board which resembles a white board with Post-it notes on it. Perhaps the my reason why people get so excited about it at first.

Pictured: Mingle

VersionOne is both available as SAAS and a on-site app. This app is very customizable and versatile. The same customizability greatness arose my first concerns about it. It is incredibly bloated. Some nice features like a place to record individual retrospectives and extremely extensive reporting capability don’t quite offset how complex this thing is. Yet it is surprisingly easier to work with than Mingle, don’t ask me how. I did notice that VersionOne is not very Safari friendly, which was a small turn-off at the time, it did work fairly well in Firefox. Version one also integrates with Subversion which may be useful if you are still stuck in the land of non distributed source control management (god help you). VersionOne will run you about $30 per user per month.

Pictured: VersionOne

TargetProcess came to me in a late night google search rampant . I am not quite sure how I found it or what the search term was. I do know however that I had done a lot of searching on the topic before and it never came up. Perhaps they need to invest some more time on SEO. TargetProcess caught my attention fairly quickly with their quick start demo. What was premature excitement heighten as I uncontrollably watched all the available demos on their site.

I have yet to get my hands on it (currently waiting for a trial password), but what I saw brought back the hope that perhaps there is a good tool out there. TargetProcess is both available as a hosted solution and on-site application. At a fair price-point of $25 per user per month it is much more achievable than most of the other solutions described above.

Even though it is a massive application somehow it feels very intuitive. Reports are easily customizable, processes can be changed to fit your style such as XP or SCRUM. You can comprehensively organize your stories into iterations by dragging and dropping. In-place editing almost everywhere allows for super quick updates. Overall the app seemed extremely configurable yet uncluttered. Also available is a public API, support for Subversion integration and a rich story card board that seems easier to use than Mingle’s. I should have the login credentials for the test account shortly and will be posting an extensive review on TargetProcess in the near future.

Pictured: TargetProcess

We will be picking a tool to work with in the next couple of weeks. At this time my heart is leaning towards TargetProcess but I can’t be sure until I get in there and conduct a proper colonoscopy. I will make sure to report my findings and hopefully provide a conclusive resolution to this dilemma.

Correction: VersionOne is built in ASP.NET

Also check out TargetProcess’ new UI