I spend a fair portion of my time working with Project Management Office (PMO) and Project Support Office (PSO) groups helping them integrate agile methods. One simple concept I’d like to outline today is the idea of Agile Interfaces.

Agile methods provide a great feature delivery engine, they iteratively feed on features from the backlog and produce tested functionality of high business value.

To external stakeholders this also represents a daunting and unfamiliar process to connect to. Its cyclical, seemingly never ending process is about as appealing to interact with as putting your arm in a washing machine while running. However there are a couple of friendly, safe interfaces that can alleviate mid-cycle arm twisting (how we normally extract information from the team.)

As mentioned, while agile methods focus on delivering features, they often do not provide the information required for PMOs, PSOs and other supporting groups. They typically do not encompass the entire enterprise lifecycle omitting important pre-project work and beyond delivery activities, as shown below.

Why wouldn’t you always use agile methods? Well, shock-horror, maybe they are not always the best approach for the circumstances! So how do we decide?

It is tempting to thinking that all projects should be handled in an agile way. Indeed, I am convinced that all projects would benefit from the improved collaboration and communications encouraged on agile projects. However, collaboration and communications are just two attributes of agile projects and we must consider wider parameters that influence project success or failure.

I am working with the assumption that the end result we are looking for is a successful project with satisfied stakeholders. It would be better to have a successful traditional project than a failed agile project. Others might disagree, but I’d classify them as purists rather than pragmatists.

Our choices typically include using a Package that may or may not require customization and integration, running the project using a Traditional (single pass waterfall) approach, or running the project as an Agile project.

So, how do we indentify and assess the project characteristics that determine what “shape” project we have? Fortunately there is a wealth of good research to draw on and build upon. This post outlines some popular and some less well known agile suitability tools:

1. The Slider
2. DSDM Suitability Filter
3. Alistair Cockburn’s Project Criticality and Team Size
4. Boehm and Turner – Radar Chart
5. Dave Cohen’s Agile Factors
6. The Organizational Suitability Filter
7. The Methodology Bias Hammer

I am looking for an experienced .NET 2.0 developer to join our team at Husky Energy. This is a challenging role on an established agile team building a complex oil pipeline management system. The skills we are looking for include:

Must Have

• NET 2.0 (advanced)
• OO/design patterns skills (advanced)
• Experience in enterprise application development (advanced)
• SQL (intermediate)
• Unit testing (intermediate)

Nice to Have      

• Crude Pipeline knowledge
• ReSharper
• MSBuild
• Subversion
• iBatis
• Developer Express suites
• WCF

The role is a contract position for one year. The project has 18 months left to go so an extension is likely. We are using a practical set of agile techniques and have the benefit of three full time users dedicated to the project – which in my experience is rare.

Candidates with strong .NET development abilities, a passion to join a high performing agile team, and availability to work in Calgary should send their resume to me at [email protected]

The team will be doing the technical interviewing so expect some code reviews and coding assignments in the interview. We have a great team in place that work well together so we are particular about finding the right person. Fit is more important than availability, we will wait up to a couple of months to accommodate the availability of the right candidate.

If you have analysts working ahead of development, or have testers working significantly behind development, then you may have “Pipelining” problems.

Pipelining is the term used to describe the situation when business analysts are working ahead on the requirements for a future iteration; the development team is working on the current iteration, and the test team is engaged on a previous iteration.

In some circumstances analysis may be several iterations ahead and testing several iterations behind. To some people this may seem an efficient use of resources with each group running at their optimal speed, unfettered by the co-ordination constraints of different groups. However from an agile and lean perspective this is problem, a bad-smell that needs fixing.

Here are the problems with pipelining:

Three teams not one – in a project where pipelining is occurring we do not have one cohesive team we have three teams (or more). It is hard enough co-ordinating the members of one team towards a common goal aligned to business benefits. When there are three teams it is just too easy for people to claim that they did their bit and problems lie with other groups. Yet, the fact remains that if the software does not meet business satisfaction then it is everyone’s problem.

Increased Work In Progress (WIP) – Requirements whether they are in the form of user stories, use cases, or formal specifications all represent work invested that has not delivered value to the business. The same goes for code, until this functionality has been tested to the satisfaction of the business it is not valuable. As the time increases between capturing the requirement and finishing the last test two problems occur. The first is classic accounting, money have been invested for no return yet and there is a risk associated with future returns. The second is that requirements decay; the longer we keep requirements around for, the higher the likelihood that they will no longer be required or will have to change.

Increased time from defect injection to defect remediation – the cost of change increases the longer a defect goes undetected. In a pipelining project, defects introduced by faulty analysis could take months to be detected in testing or user review. Fixing the problem after this period of time will entail refactoring far more code (for the work happening in the interim) than if it was detected earlier, and will increase technical debt...

A couple of weeks ago I wrote a post called “The True Role of a PM on Agile Projects”. An attribute I did not include was “Be Enthusiastic – it’s Contagious” one reason for this omission is that it is a skill that I struggle with and I did not feel qualified to talk about. My style is more reserved and I have to go outside of my comfort zone to outwardly project my eagerness. However, the fact remains that it is an important role. 

If the leader of the project does not appear to show a passion for the cause then why should the other team members? Also the “- it’s contagious” portion is very important, as a social group team members easily feed off of each other’s energy levels. This is demonstrated by the presence or absence of those rare individuals who have the personality to be able to lift a group. When they are present everyone feels the lift and buzz, when they are absent there is hole, and everyone comes down a notch.

By introducing a positive, enthusiastic approach we nudge the team mood in the right direction. Nobody wants to work in pessimistic drudgery. We are happier, get more done, and overcome obstacles easier when people are enthusiastic. Obviously, it needs to be genuine and in character with your true nature. Some phony “Woo-hoo’s” will fool no one and undermine your credibility, but even if you tend to be quiet, true enthusiasm can be conveyed in the way in which you engage with the team and other stakeholders.

The reason I’m writing about this today is something I picked up last night from the PMISAC awards. Tana Goertz, finalist from “The Apprentice 3” gave a keynote speech that provided the tip “fake-it until you make-it”. Now I know I have just said we should not be fake when showing enthusiasm, but that was not her point. Tana’s message was that if you realize that something is important then you should do it, even if you struggle, until you can do it well. By practicing this awkward, but important skill, it will become easier.

Another take on this is, is “if something is worth doing, it is worth doing badly”, it took me a while to understand this oxymoron. However, it means if something is good and important we should try to do it (even if we are bad at it) because at least a little is better than nothing at all. (Another favourite oxymoron truism is “You lead people by standing behind them”, physically impossible, but correct in principle.)

So, if you are a little like me and struggle to project enthusiasm give it a try, do it anyway. Be sincere and express it in your own way, enthusiasm is contagious and brings the energy to push through setbacks.

To my surprise, this blog won the PMISAC award for Project Management Literature last night at the 2007 Awards Gala Dinner. This is a great endorsement, I work on the blog in my spare time and it provides a large encouragement to continue and do more.

I also think having a blog considered for a literary award demonstrates how progressive the PMISAC is. It was not long ago that blogs were more the domain of developers than project managers. It is very encouraging to see alternative media branches recognized.