Archive for July, 2009

I’m working with a lot of the Atlassian tools lately, and I do like them a lot. Though I know there are a lot of alternatives out there, I like the fact that these play nicely together and of course JIRA is a kick-ass tool. But enough of that.

I found a little annoyance in the latest fisheye release, which I wasted about an hour or so on.

We just decided in a moment of inspiration to use Gravatar to enable custom avatars, free, already comes integrated and seems easy enough to use. So we went off and created users and were careful to use the company email address etc and waited for the disclaimer amount of time to have it refreshed, but nothing happens. So I read a little more about it and think, maybe our firewalls are causing problems – I’ll use the HTTPS mode! I reconfigured and full of anticipation refreshed the people page, but again – nothing.

After ruling out general firewall and networks issues (I can see the image in a browser on the server Fisheye is running on) I looked closer to the URL itself, and it turns out the image source fisheye is constructing was not at all the same as Gravatar claims ot be using.

So I trawled through more of the details of both Fisheyes integration with it (not much), some forums, and how Gravatar generates the image itself and thats when I spotted a potential flaw..

"[…The next part of the URL is the hexadecimal MD5 hash of the requested user’s lowercased email address with all whitespace trimmed…]",

Noticed the lowercased bit??

Exactly…

We are using CROWD to feed the user details from AD, and even though we have set it up to only serve up lowercase output, that only formats users, groups and roles. Attributes like Email is still Camel case, and as we all know hashing is case-sensitive. But fortunately this field is editable in Fisheye in the local user details, so I can lowercase it myself – and Job done!

So while there has been a lot of thought and work going into this the devil is in the integration details.

Currently, we’re not really running projects to implement functionality. Its more like small requests which are usually undertaken by an analyst, a single developer and a single tester, loosly connected, but with very specific roles and responsibilities.

  • The analyst works with the business owner to formalize a specification and is responsible for the completion of the work on time and within budget.
  • The developer is responsible for implementing the functionality and ensuring that the release of the patch (usually we are working with maintaining existing applications) goes smoothly.
  • The tester is responsible for ensuring that the functionality described in the specification.

This is not an uncommon division of labour and there is no reason why this should not work however we are experiencing some problems.

  1. The requirements are usually completed without much involvement from developers or testers resulting in specifications that are incomplete and sometimes impossible or undesirable to implement.
  2. Since we are using a waterfall approach any problems with the requirements are discovered inside the development phase .
  3. Once the development starts the tester is usually disconnected and any subsequent changes that occur are not communicated and therefore not reflected in the test plan.
  4. Documentation is not coherent – each project may or may not provide documentation about the functionality and overall architectural documentation is scarce and out of date.
  5. Poor support for new joiners since the process and the division of responsibilities between the roles are not documented

This all leads to a lot of projects being delayed in various parts of the process, because they have to jump back up the waterfall, and that leads to our biggest problem. : There are too many projects going on at at the same time, with people working on multiple tasks simultaneously, and this is bad!!! Not only are there overheads for each person involved, but different projects have different staff so people are on several teams at the same time. That will lead to resource contention and prioritisation failure since no one is able to see the wider picture and therefore everyone optimises their own workload, even though that might lead to the entire chain (all projects) being less efficient (p 38 onwards of this book describes just that).

What this leads to is a lot of incomplete work that will have to be pulled last minute, a lot of rework because of poor communication, wasted efforts and inconsistencies – both in functionality and quality.

New methodology

To solve all these problems we have been working on introducing a project management methodology that will allow us to address these problems.

  • Flexible enough to apply for several different sizes of projects
  • Well established in the industry to ensure that new joiners will be able to grasp it
  • Enforce communication
  • Focus on Iterative and incremental development

How do we turn this agile?

Now, my goal is hand has always been to turn this agile, and to be completely honest we do have some practices and procedures in place that can be used, but there are ‘buts’

  • We have a backlog of ‘features’ (or various sizes of projects) , -but they are in different queues.
  • We are developing in a feature driven way , – but these ‘features’ or projects can be decomposed further
  • We already set up a team and project organisation around a ‘feature’ , – but teamworking is an issue
  • We have scheduled monthly releases and release what is ready when the date arrives , – but we frequently fail to meet the release date
  • We use source control and version management in this manner already , – but we only just started

Now this we can work with…

As a starting point, we have chosen to go with RUP, because

  • it comes with a nice set of role and responsibilities descriptions,
  • it has a large repository of predefined processes
  • it is much less contentious than ‘Agile’ and is likely to be approved politically
  • it can be scaled down enough to become Agile, and still please management in having a ‘phased approach’
  • there is some prior experience within the organisation, which will help introduction and learning
  • it will force us to document our systems in a coherent manner.
  • the focus on ‘team’ is strong, it will allow us to build a cross-functional feature team.

We’re basically thinking of the Dreyfus model here. RUP will be able to give ample support to take us through the Novice and Beginner phases, after that phase when we have learnt enough we can start chopping away the fat. And there will be a lot of fat to chop. In the initial incarnation the project manager and the architect will be inundated with documentation, so the first couple of projects will be slow and painful. But with each project we’ll start building up our repository of documetnation and the next project will get it slightly easier and we’ll soon have a decent view of our applications.

Rolling it out will start with with general presentations, so the entire organisation is aware of what is happening, and in agile talk, making us all pigs rather than chickens.
Once that is done, the nexts step is workshops for those involved in the early projects in order to get familiarised with the process. Hopefully this will reduce the friction within these projects and people would like to work in another RUP project once the first one finishes.
But these projects will also need a lot of guidance, hopefully we’ll get a mentor in to guide us through the first couple of iterations wh can steer us in the correct direction

This will no doubt require a lot of discipline and support by management. Hopefully, by setting the expectations from the start and making it clear what the benefit is will aid that.