ProjectPro.org.uk

Most organisations that do not use Agile methodologies for managing software development projects, I’m sure hear of the benefits of Agile and would like to enjoy the advantages. What follows is my experience of implementing Agile (from a practical perspective).

With the understanding that Agile is a Development Methodology, rather than a Project Management methodology, the interface between the development and the business is key.

The first step was to establish certain assumptions (basically in accordance with the Agile Manifesto):

1. Code can be compiled and run at any time

2. Nominated ‘Customer Champions’ (or Proxies) contribute directly to the project and make decisions on behalf of the business/users at large

3. Requirements can be prioritised and success can be achieved without every requirement captured being delivered

To achieve the first point, the technical teams adopted Test-Driven Development. Requirements were defined in ‘use case’ format and tools employed to automate the running of tests. Committing would perform all tests automatically and highlight any errors throughout the system, so that code ‘checked-in’ should never break the build. Tools to automate the generation of intelligent test data were used.

To achieve the second point, a Customer Champion was identified and assigned to the Project Team, providing feedback and representing the business/users.

Thirdly, the requirements were assessed to establish a core set of features that would satisfy the basic purpose of the project. My rule of thumb (using MoSCoW) was that 65-70% or lower should be ‘Must-haves’. Your judgement may consider a higher or lower proportion, depending on likelihood of change and complexity in the solution.

Since the Clients required traditional reporting (i.e. MS Project Plan) the following approach was used:

I defined the plan to describe the Sprints preferably 1 or 2 weeks duration, the pattern I used was as follows:

• Each Sprint starts with a Sprint Start session where the backlog is reviewed and work items agreed.
• Each day a Scrum meeting is scheduled to monitor progress of the sprint and to resolve any obstacles.
• Each Sprint ends with a Sprint Demo session, where the team reviews the achievements with a demonstration of the new features.
• Define a Stage Review period between groups of Sprints in order to perform any necessary optimisation/refactoring and business/project reviews.
• The Customer Champion may approve the build for deployment to a ‘User Test’ environment at the end of each Sprint. They would then manage any critical feedback and update the  Project Backlog accordingly.

I implemented three Stage Reviews, so that the project should have all the ‘must-haves’ completed for the second Stage Review and the third stage becomes implementation of lower priority requirements or possibly outstanding rework of items previously complete (due to recent changes in the business).

Incidentally, the Sprint construct also works for non-technical deliverables (i.e. documentation).

The Project Plan does not describe the work to be done (therein lies the flexibility) it describes the process, and other tools should be used to manage the work items, therefore the plan should remain constant and it is convenient to establish a ‘template’, that can be reused for projects of varying scale.

We used 37signals ‘Tada List’ to manage the Backlog and development activity during the Sprint. The team established items for the current Sprint and maintained work status through the Scrum.

Note: For the benefit of those unfamiliar, ‘Use Case’ is a way of expressing low-level requirements in the form:

“As an X will be able to Y in order to Z”

For example:

• As a “logged-out user” I will be able to “enter correct username and password” in order to “change to a logged-in state“
• As a “logged-out user” I will be able to “enter incorrect username or password” in order to “see a login warning message”
• As a “logged-in user” I will be able to “upload a photo” in order to “associate with my profile“

(It is usual to group these use cases into ‘features’, which form the work items in the backlog).

The adoption of Agile Methodologies in a ‘Client-facing’ arena appears to present challenges to conventional wisdom, these most commonly being, the customer needs to know:

• what they will get
• what it will cost
• how long it will take

This is however to set a boundary for an agile project between the client and the supplier. In order to be successful all stakeholders must buy-in to the Agile process and become more involved. Interestingly surveys show far higher satisfaction with Agile, but applying this approach in the Client-facing context requires broader considerations:

Framing the negotition

Agile operates with different metrics to classic, so it obviously needs to be sold and negotiated differently, as it is managed and measured differently. Rather than focus on the intangibles (budget, effort), consider the benefits and success factors directly. These, after all, are what ultimately matter to the Client, even if they are not so easily quantifiable.

The Tendering process

It could be argued that the quantitative nature of traditional planning provides hard data for clients to contrast and compare competitive tenders, but I would suggest that in most cases bids are won in the final stage because of ’softer’ factors. Through the proposal process the client should establish confidence that the supplier is competent, understands their needs and has the required experience and ability to achieve their objectives. The planning and preparation for an agile project addresses these aspects more directly than traditional (Classic) methods.

Establishing the ‘one team’ philosophy

Agile projects succeed where the project team is cohesive and there are no boundaries. In the ‘client-facing’ environment this requires integration of both parties into a single unit. Formal agreements (i.e. Statements of Work and Contracts) are just as important but need to be consistent with the approach, i.e. stressing commitment to objectives and each parties contributions.

Some customers may not wish to be so integrated into the process (for example they may not have the resources to devote) and this should be a sign that an Agile approach is not suitable.

In overall terms a client that can define in detail what it needs up-front (and is willing to commit to these as the outcome) does not need an agile approach. Where there is uncertainty or the potential for change, the supplier recommending an Agile approach is acknowledging these factors and responding appropriately.

This enterprise started back in late 2009, with the ambition to create and provide mobile applications (’apps’). The rationale being to focus on the needs of the user and provide apps which are as flexible and as simple as possible to use. The development process involves repeatedly ‘boiling-down’ to get to the heart of each feature implemented.

Fundamental to that process is Titanium from ‘Appcelerator‘  which aligns perfectly – enabling developers to build apps rapidly for multiple platforms from a single technology (in this instance Javascript).

In March, www.keepitsimpleapps.com deployed it’s ‘maiden’ app: AppNotes v1.0 for the iPhone, followed by an enhancement (v1.1) one month later. There’s another enhancement about to start which hopefully should be released in a week or two.

Aside from AppNotes, there’s a much more significant project in the works, details of which will hopefully be coming out in the next few weeks.

More from Southwest Airlines on Social Media (part 2 of 2).

I figured it was time for another video – more from Southwest Airlines on Social Media (part 1 of 2).

It may sound obvious to most but Project Management and Line Management are different roles and each brings specific skills, working together in an effective organisation.

Line managers have the ongoing responsibility for the admin, personal development, job satisfaction and well-being of those under their charge.

Project Managers focus is on achieving the objectives of a project. He/she has responsibilities the Line Manager may not (such as managing Risk, Scope, and the Customer).

The temporary nature of projects means that good quality line management is vital to ensure staff have the continuity and stability from which to contribute effectively to their projects. A company run by Project Managers would be a pretty scary place.

Like understanding your customer, the more you know your sponsor the easier it will be to have effective communications with them.

Work out how much information they require and if necessary have a conversation openly on when they want you to advise them, what they need in reports, how often, etc.

I would always push to lower the threshold a tad, as it’s better to have raised an issue that gets quickly resolved, than hold-back on a critical problem. After all the Sponsor is the ultimate stakeholder and should have the greatest to gain/lose from the outcome of the project.

For those that may not have ventured far into the site, it isn’t all quiet. I’ve been enhancing the Career History page  to showcase some of the sites I have project-managed in my current position (with the obligatory Lightbox effect).

I have added a summary of the project to provide and maintain a site for a local business (Ammi Flowers) that I was asked to put together. It’s been well received by the proprieter and their customers and is regularly revised and enhanced as the business develops.

Click here to find out more.

Understand where you are going before you leave.

Sounds simple enough. And yet despite all the theory and experience of decades of software development, it’s amazing how often projects are pursued in a ‘pioneering’ fashion.

An impatience to start build can be overwhelming, but projects routinely fail because insufficient thought and preparation is done before cutting code.

For the project team to work effectively, developers need to know where their work fits into the whole and also what business needs they are aiming to satisfy.

A failure to adequately comprehend and define how the solution will acheive the business objectives and ‘realise the benefits’ is a big risk and can easily mean the project will be late, blow the budget and leave an unhappy customer in it’s wake.

In terms of Project Control Processes, I’ve come to consider Risks and Issues as intrinsically linked, despite that many sources and courses teach these seperately.

Here’s the logic: An Issue is a Risk with a 100% likelyhood.

Issues are problems that need to be managed, in the same way as a risk once a trigger point has been reached.

The procedures for distinct risk registers and issue logs, means that Project managers can at best incur greater administration or at worst they can lose the holistic view that a combined view would give.

Ask yourself how many status meetings have you been to where the majority of the session is spent fire-fighting the issues and zipping through the risk log right at the end – or worst still, suggesting that be looked-at at the next meeting.

If the scoring system were adequately calculated it could be that some HUGE risks should merit higher attention than minor issues and should in truth be prioritised higher up any single list.