Agile Project Management Tools are doing it wrong

Introduction

I have noticed many bug tracking products attempting to add "Agile" project management to their offerings. I use the word "attempting" because I have yet to use one that really works. I also find it frustrating that many of these same products are setting aside useful features (like case commenting permissions in FogBugz) and enhancements in favor of failed attempts at making an agile PM tool. Here I'll try to outline, as I see them, the problems faced in trying to make an AGILE PM TOOL.

Users Believe that they want an online Card Board (or kanban)

Unfortunately, most of us have believed for a long time that a nice Trello style online board would be perfect for managing an Agile Project. So far, IMHO, none of the tools have gotten this right AND I doubt they ever will. The great thing about a card board or board full of sticky notes is that you can grab the card, pass it around, set them out on a table, return them to board or put them on another board very easily. All of this while having a full visceral interaction with the rest of the team.
The electronic card boards fail to allow uninhibited control of the cards. You have to click then drag a card somewhere AND unless you have a huge (45+ inches) touch screen monitor many of your cards end up falling off the screen or are unreadable. We always do our planning using physical cards. Even though the tool we use (FogBugz) has a so-called Agile Planner built in. It's just to unwieldy to use BUT we keep telling these companies that this board is what we want.

Suggestion #1: Stop trying to create online card boards and focus on managing the backlog (see below) or workflows (see below). When we ask for the card boards we really don't know what we're asking for.

Agile Projects all follow different workflows

Agile teams rarely have the same exact workflow. The workflows differ from team to team for good reasons. Differing product schedules, team size, organizational demands, etc. The tools that try to prescribe a single workflow, do so at the loss of potential market share. The tools that have a super flexible workflow editor don't always go far enough or it becomes difficult to see what the workflow really looks like. The tools that try to have a one size fits all approach tend to be berated for not really meeting anyone's needs.

Suggestion #2: Workflow is one place I think these tools can make big differences. If you are going to have a workflow editor then it needs to be robust enough to allow good workflows to be described. Managing the workflows is the absolute best use of these tools. It allows developers and users to easily move cases along the pipeline that your team has described. It does suggest "kanban" but as mentioned above it doesn't need to be visually like kanban, just conceptually. It's really just a pipeline approach.

The BACKLOG is what really needs to be managed

Some backlogs have tens of thousands of user stories in them. Managing that backlog effectively and allowing product owners to more easily garden is a missed opportunity in most of these tools. Once again no visual representation of cards is going to help here. It's too cumbersome and time consuming. The ability search and order stories in a backlog based on factors such as priority, area and cost are very important BUT also being able to tie these stories to epics on a road-map is even more important.

Suggestion #3: My backlog order rarely drives the priority of work. We follow a constantly changing road-map of EPICs based on current business needs. Being able to associate stories with Epics and then to a product road-map AND have that automatically fix the backlog order would be THE KILLER FEATURE! Being able to bring up a road-map of EPICS that I can modify then have the backlog automatically changed would be amazing.

Story Points versus Man Hours

Fogbugz just recently added story points as a second class citizen but still has no good burn down chart capability that uses story points. Most tools do have a burn down but the problem we always face is that some teams use hours while others prefer story points. To further compound this is how and when do you receive story points (or hours) for a story or task? Some teams allocate points once the developer has completed the work, other teams only allocate once a QA review has been done and still other teams use completely different methods. 

Suggestion #4: This is a point I am less confident about. My gut says this capability can be fleshed out if attention is given to it (see suggestion 1). This may be a matter of allowing point allocation to be defined as part of the workflow. I believe that would work but once again the workflow editor must give a solid representation of how that workflow will be enforced.

Final Thoughts

At the end of the day my preference is for a basic issue tracker that allows me to stay in continuity with our end users and allocate engineers/QA to stories. We've used the FogBugz API extensively to build our own burn downs and other information radiators. For us having the programmatic access to our stories is of greatest importance, along with the added workflow capabilities. Enhancements in the areas mentioned above would be of most value to us.

When do you stop for UX in SCRUM?

I've been struggling with the question of integrating User Experience (UX) into our release cycle. Here is an article that suggests a pretty good solution: Fitting Big-Picture UX Into Agile Development

See what your SQL Queries are costing you

Here is a neat script that will tell you what the most costly queries are on your SQL Server:

SELECT  creation_time 
        ,last_execution_time
        ,total_physical_reads
        ,total_logical_reads 
        ,total_logical_writes
        , execution_count
        , total_worker_time
        , total_elapsed_time
        , total_elapsed_time / execution_count avg_elapsed_time
        ,CAST('' AS XML) AS statement_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY total_elapsed_time / execution_count DESC;

FIXED: "Invalid type owner for DynamicMethod" error in Nhibernate

If you recieve the "Invalid type owner for DynamicMethod" error while initializing you NHibernate SessionFactory then it's pretty likely that you are using generic methods on some of your lazy loaded/proxied classes.

Nhibernate incorporates a reflection optimization that speeds up the creation of proxy classes. This reflection optimization does not play well with generics. The error it throws is "Invalid type owner for DynamicMethod". Not very friendly.

So, to fix this you must either stop using generic methods OR turn off the optimization. To turn off the optimization you must run the following code before you initialize your SessionFactory.

NHibernate.Cfg.Environment.UseReflectionOptimizer = false;

I was Interviewed

Not sure if I posted my interview done by Rustici:

http://scorm.com/blog/2011/04/interview-with-dan-pupek-chief-systems-architect-at-advanced-systems-technology/

Good article on Mulit-Thread Applications in C#

I was very pleased to find this. Been using it as a reference:

http://www.albahari.com/threading/

Make a 5 Second Video from Image using FFMPEG

Been playing with FFMpeg and Mencoder to create videos from a list of Images and an audio file.
Here is the command I used:



ffmpeg -loop_input -vframes 50 -f image2 -i foo-1.png -r 10  foo1.avi
ffmpeg -loop_input -vframes 50 -f image2 -i foo-2.png -r 10  foo2.avi
ffmpeg -loop_input -vframes 25 -f image2 -i foo-3.png -r 10  foo3.avi
ffmpeg -loop_input -vframes 25 -f image2 -i foo-4.png -r 10  foo4.avi
mencoder -audiofile foo.wav  -oac copy -ovc copy -o output.avi foo1.avi foo2.avi foo3.avi foo4.avi




Making the leap to QueryOver

So, if you are using the ActiveRecord/NHibernate stack I highly recommend switching to query over. The syntax is cleaner and it's type-safe.

Here is an example of a criterion based query:


Here is an example of the same query in QueryOver:



Unlike the Linq language for Nhibernate QueryOver is just a translation layer for Criterion.