Something I have been whining about for years

Syncable tools for the offline web

SD is a peer to peer bug tracker which can sync to itself, RT or Hiveminder. You can extend SD to sync to other bug tracking tools by writing simple adaptors. If you’d like to help make SD work better with your bug tracker, drop us a line.

With all the cool kids (and me) moving to distributed version control tools it’s been obvious that that there is a gap because our bug databases are centralised. Why is that a problem? Because code changes should always be booked against either a user story or a bug report. The link needs to be hard! i.e. I should be at least warned when I commit code without a ticket and when I look at a completed ticket I should be able to find the corresponding code. When you are committing code changes at 11,000 meters above sea level that can be a bit hard.

The only thing I know about SD is what I’ve read above, but already I want it!

[update 25/July -- the SD website now works so go for it!]

Intresting metric for predicting code quality

The Joel Test: 12 Steps to Better Code - Joel on Software

The Joel Test

The article explains it well and I have to say that it would make a very effective first test for team and process maturity. Try and see how well your team does…

Powered by ScribeFire.

Scrum humour

Now that I have discovered how to embed video here an amusing piece of geek humour on how not to run a scrum meeting. Funny and educational, and it’s generally good advice for running any meeting as well.

Learning about Scrum

Google Video presentation from Ken Schwaber, one of the founders of Scrum, about the basics of Scrum. Well worth looking at, especially if you come from a XP background.

Great Quote “Exercise profession competently”

Core messages:

• Say no to cutting quality — make product management drop features instead
• It’s easy to end up with a design dead product, it takes about 5 years of cutting corners

Intresting tit-bit

• Drive Architecture and Infrastructure from non-functional requirements
• Scrum was not successful until the advent of high quality IDE’s

I read this and thought of Peter

Business of Software Blog: From project sluts to strawmen: An interview with Tim Lister

Cramblitt: What do you think about the reliance on best practices?

Lister: I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices because that implies generic software development.

A intresting piece on patterns for project management. Makes me want to get the book.

The reference to my old friend Peter is because he said this to me many years ago and still I cringe every time I use the phrase. Unfortunately I still use phrase because it has such a cachet. so I must be a marketing tart (when I’m not being a Geek of course)

Powered by ScribeFire.

Capturing ALM Metrics

Useful Software Metrics « Alec the Geek

Using a ticket management and capturing all issues, not matter where in our lifecycle they occur

Not all software teams have tools that allow metrics to be gathered. Without metrics we cannot answer questions about productivity, process improvement or estimating other than by (hopefully) intelligent guesswork.

How might we address that in the short term?

1. Introduce a time sheet system: That’s complicated and requires tools to analyse the data
2. Ask people to fill on project work sheets i.e. a time sheet for a project, rather than for an individual. It should be filled as each project work product is delivered (e.g. domain model,  fully dressed use cases, test cases, etc.). The sheets should be simple i.e. the deliverable, the project name, the project phase, dates and a summary total of effort and the number of people involved.

Armed with this simple information it should be possible to start gathering some more intelligent insights into how well the software process is working.

Powered by ScribeFire.

I should be so lucky

BBC NEWS | Business | Complacency ‘rife’ in IT projects

Many European IT workers are not being held responsible for delivering projects late

It’s an interesting question. Should people be ‘punished’ if their projects, sometimes for reasons they cannot control, are late? What does punishment mean in this context? Sacking, being moved sideways, lack of promotion…

Suggestions on a postcard please…

Powered by ScribeFire.

Dimensions of Change

In the past when I’ve looked at Change Management issues I’ve tried to concentrate on lower level more practical topics. However recently I have the opportunity to think about change processes at the a higher level and of course that let me to want talk about it.

When looking at a change process it is tempting to see it as a single process, one size fits all, i.e all changes can be treated identically. However life is never that simple because changes have multiple facets. As well as identifying which change process needs to be followed, change dimensions provide information to assist us in prioritising work.

The most obvious difference, and the one that most people first come across, is the budget difference. Depending on who is paying for an change (IT or customers) has a direct bearing on the approval process. If the customer is paying (either directly or indirectly) then they, or their delegate such as the marketing department, must be involved in the financial approval to spend money. If it’s ‘free’ then the customer involvement may be limited to status updates.

A second dimension is size. The larger the size of the change the greater the process complexity and check points. How do we measure size? A variety of metrics need to be used, typically financial cost to implement, architectural impact on the software system, impact on other systems, how many project owners/stakeholders exist (this increases the issues involved in communication and resolving conflicting needs). This concept is reflected in the ITIL change process which recognises three levels of change impact and has different process flows accordingly.

A variation on the ‘financial cost to implement’ value is that different software systems may have different costs to deliver a similar level of business value. So a legacy application that contains a lot of cruft might cost $x to deliver y benefit, however in a different part of the business a different system might take a lot less than x dollars to deliver the same amount of value. So when comparing changes in a priority list, looking at a pure financial cost may not be enough.

The third Dimensions of change can be considered as political, i.e. who is sponsoring or controlling our changes? Often the executive team are able to generate a significant amount of strategic work which could absorb the all potential development and related resources. However an organisation also needs to exist on a daily tactical level and there are significant improvements to be made by implementing as many improvements to the current business as possible. However these changes often appear less significant to executive sponsors because of their more tactical nature despite their possibly huge business value.

When the various facets of a change are taken into account we can then make some decisions about the change e.g. Who will make the change, what level of process maturity will the change need to follow, which budget will pay for the change, who will be involved in acceptance testing, when will the change be released and so on.

Next time I will discuss some practical consequences of this and how to avoid some of the resulting pitfalls

How to avoid task dependency hell

A rather obvious point really, but often teams and organisations stagnate in a cesspit of inactivity because everything depends on something else, which of course also depends on something else. Soon it feels as if nothing can be done and everything is delayed waiting for someone else to do something.

There are two answers. The quick fix and the long term management of work.

Quick fix
The answer is to “Just do it”. Break the work in hand down into smaller pieces and find something that does not have a dependency, then do it! Repeat as required.
If you can’t find anything without a dependency then work around and do the best you can without needing the dependency

Long Term Answer

1. ‘Design’ work as a set of loosely coupled activities with small, well considered, dependencies. Of course the activities need to be coherent and internally cohesive.
2. Make sure you document and track your tasks and the tasks you assign to others.
3. When the dependencies get too complicated then package the work up into large bundles that can stand alone; re-examine the package as a whole and start attacking the work by ‘nibbling’ at the edges. Apply the ‘Quick Fix’ if needed.

At this point any analogy to software design breaks down. In software we are better off having simpler tasks (objects) and more dependencies (interactions). However for activity management we often (but not always) need to lean the other way. Providing our tasks are basically coherent then we can  make each chunk of work bigger if it  helps reduce the dependencies between activities.

This approach scales to teams and larger groups. The more we can package work into independent projects and just get on with them the better. If our work is not perfect because of a missing dependency we are still better off anyway because at least we have started to break the logjam.

Powered by ScribeFire.

Software Development: Managing in the dirty trenches

When you talk to many consultants about managing projects then they tend to offer the ‘helicopter’ view of the world. The conversation is based around concepts like vision, planning, delivery, scope etc etc. Whilst this is key to project success — you can’t complete a successful project without a clear roadmap, there is often a disconnect between the management view of a project and the work that is going in in the trenches.

The reason? The devil is in the detail and someone needs to be down in the trenches tracking activity and issues on a daily basis.

What does that mean? It means someone needs to:

1. Understand (the relevant portion of) the project plan at the detailed task level
2. Identify and track all issues and risks
3. Monitor daily progress (this can be a lot easier when using test driven development and testable features style approach)
4. Have a good grasp of the technical and project impacts that issues create when they occur (NB — The business impacts are the job of the project manager and customer)
5. Have the courage to describe things as the really are and suggest unpalatable options

Now in my view that should be a major portion of the activity performed by a senior team lead. However in my experience team leads rarely have the inclination or authority to fulfil this vital role, they seem themselves as ’superior’ developers focused primarily on technical and architectural issues (which are also important of course).

So it’s up to the project manager to either do this work themselves or identify suitable individuals who can take on this role. It is important to think outside of the box and consider all possible options when looking for these people, they usually don’t jump and down saying ‘Oh me sir, please sir!’.

If you do find people with such potential then mentor them and nurture them well. They will become future project managers and will help save your bacon on the current project.

Software Development: Where are you now?

When you start to think about a software project one of the things you absolutely need to know is “Where are we now?” (along with “Where do we want to go?” and “How are we going to get there?”). This question is usually not thought about that hard, and if the team have been working together for some time they generally “just know” anyway. However for an ousider it’s an important question to think about. I generally look for the following:

• What version control tools are in use and how is the information set up and used
• Is there any documentation of process and
• Does anyone follow the process documentation
• How do the customers feel about the work the team does - how do they think the team should change (that can be a hard question to get honest answers for)
• How are requests and issues documented (e.g. emails, post-it notes, bug tracking tool …) and how is the information used
• What is the technology used (e.g. frameworks, languages, build tools, IDEs, deployment …)
• What are the current ‘pain’ points (e.g. too much rework, too hard to understand code base, can’t refactor etc.)
• How much budget and autonomy does the team have

This will help you build an informal map to assist in in planning any work and identifying issues that may need addressing outside of the current project work. The information should be maintained in some easy to understand form e.g. a Mindmap or WiKi and updated every month or two.

I got a new book, Fit for Developing Software

FIT

Fit is a tool for enhancing collaboration in software development.

I just bought Mugridge and Ward’s book on using the Framework for Integrated Tests. I have only got as far as Ch 4 but I am very excited about how this approach might:

1. Help my conversations with customers by encouraging the use of Fit documents and
2. Reducing development overhead by making it easier to implement automated testing for business rules

I hope to get a chance to try this on some projects in the next 3-4 months so watch this space.

powered by performancing firefox

Software Development: So what do your users need?

If you noodle around the Internet you can find some very gloomy reports showing the number of software projects that fail to meet users expectations. Whilst many of the reports are paid for by vendors of Requirement Management software, they are still pretty depressing. Why are we so bad at delivering software to our customers? There are many reasons and volumes have been written about it, however I think we can distil it down to three main issues:

Adding Personal Accountability as a VALUE to Extreme Programming

Steve Hayes had a pointer to this

InfoQ: Kent Beck on Agile Adoption & Values

Customers don’t seem to mind fewer defects and more predictable schedules and programmers who are willing to have conversations and follow through with their commitments. The problems come when customers start to expect those things and programmers don’t want to provide them. Calling yourselves agile without a commitment to the values and principles of agile development can lead to some uncomfortable relationships.

When I read this paragraph a little light went on in my brain. I’d always thought the Values of XP a little odd so I just concentrated on the Practices and Techniques. Now fundamentally XP Values are values for the whole team. The reason, I now realise, that I could not place the Values in my own personal model is that the list does not generally contain accountability or commitment as a personal value for each team member, although it is often implied.

What might individual Accountability and Commitment mean for XP team members?

Beware the 9-2-5-er!

So, (first question) are project managers a different breed? Are they motivated by extrinsic incentives (like salesmen) when all the management science literature tells us that knowledge workers are motivated intrinsically (I never have been sure I believed all that science but we hear it repeated often enough from many in the agile community)?

AgileManagement

I was reading a post about project managers when this phrase leapt out and bashed me over the head, only where the author wrote “project manager” I saw “developers-who-don’t-give-dam”. It is an unfortunate fact of life that many developers display a 9 to 5, this-is-just-my-job, attitude (9-2-5-ers) that is at odds to the ‘I want to always do things better and learn’ approach required to be a member of a successful Agile team.

There are several reasons why this attitude creates a problem:

Top Tip for managing project politics

When I started my first (and last) official project management position someone gave me some useful advice, which I pass on here.

Project politics is very important and you have two choices

A Girl’s Guide to Project Management

Thanks to Kate I found A Girl’s Guide to Project Management, a blog by Elizabeth Harrin, which has some excellent resources. I look forward to trawling through the posts over the next few days. There are even some references to Australian material… :-).

On a separate note, do some women find it easier to be better project managers because they might have better developed social skills than many men? Or is that just sexist claptrap?

powered by performancing firefox

How to get the most value for your consulting dollar

Mr Angry makes some comments about employing contractors. A few weeks ago I made a presentation at the OSDClub on how to get the greatest benefit from using consultants. i.e. paying project budget for outsides to perform services for you. As it was very much a personal perspective I would be very interested in people’s comments, just click the mind map on the left to see the full size version

What was also interesting from this exercise was that I used the mind map, instead of the usual slides, to present my views and the novel format for the material meet with great approval. The mind map was created with FreeMind