Tag Archives: project management

Agile Pre-project

Posted on by

Agile Lifecycle Pre-Project

There are some important questions to be addressed before the start of any project like “Why are we doing this project?” and “Should we do this project?” Project Initiation is the phase where these questions are answered but some work has usually been done before.

Find/Write Project Brief

Projects don’t happen in isolation. The key question during project initiation is “Should we invest more?”, i.e. is the project worth going ahead with?  There must be a reason for the project. The first step during Agile Project Initiation is to find this reason. Often with software development there are just too many choices for what the team could do. A Project Brief can help remove this confusion by pointing the general direction in which the team is meant to head.

The format of a Project Brief document might be a Project Vision, in part of a Product Road Map or a Project Mission Statement but the key thing is knowing why we’re spending this money on this activity.

Marty Cagan of the Silicon Valley Product Group suggests we provide good answers to nine questions to know if we are pursing a good opportunity. The nine questions of the Opportunity Assessment are:

  1. Exactly what problem will this solve? (value proposition)
  2. For whom do we solve that problem? (target market)
  3. How will we measure success? (business metrics)
  4. What alternatives are out there? (competitive landscape)
  5. Why we are best suited to pursue this? (our differentiator)
  6. Why now? (market window)
  7. How will we deploy this? (gentle deployment strategy)
  8. What is the preliminary estimated cost? (small/medium/large)
  9. What factors are critical to success? (solution requirements)

I encourage Product Owners to answer these questions before launching the project proper.

High Fidelity Prototype

The Silicon Valley Product Group recommend a a High Fidelity Prototype rather than using documents to describe the target system.  If the Project Brief gets the go ahead then invest some time in putting together a click through prototype of the system.

References

Silicon Valley Product Group

Agile Project Scope

Posted on by

According to Wikipedia: Project Management project scope is:

The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.

We can talk about what is “in-scope”, i.e. what the project is meant to delivery, and what is “out-of-scope”, i.e. what won’t be delivered.

Typically the project scope is a subset of the scope of the product under development.
Continue reading →

Agile Project Management

Posted on by

Traditional project managers are often uncomfortable with the apparently unstructured nature of agile software development. This article gives a definition of project management, and then goes on to cover traditional project management, why software development is different, how agile project management is different, and the role of an agile project manager.

Definition of Project Management

According to Wikipedia: Project Management

Project Management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.

Unlike operational activities, which are on-going, a project is finite with a beginning and end. Each project is trying to achieve a clear objective and bring about change. Not surprisingly in the software development world that typically means building software. Project management has to balance scope, quality, time and budget to achieve the given objective.
Continue reading →

Agile Project Initiation

Posted on by

One company I worked with called the start of the project the “Blueprint” as it is about roughly shaping the project and product. “Inception” is another common term for this phase in agile projects. This article outlines traditional project initiation then delves into more detail on Agile Project Initiation.
Continue reading →

Agile Lifecycle / Agile Heartbeat

Posted on by

All software development methods, including the Agile ones, have some sort of underlying project lifecycle. System Development Lifecycle (SDLC) is the common name for a software development process, but in the Agile world I prefer calling it a “heartbeat” reflecting the organic nature of an Agile project. Some of the big Agile methods don’t make a big deal of the heartbeat and others do. Some have such abstract lifecycles that it is actually hard to know what activities to schedule. And they all use different terms for the same thing. I have pulled out the common activities to create a generic agile lifecycle.
Continue reading →

Agile Risk Management

Posted on by

Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project. This article outlines traditional risk management, how Agile is a risk mitigation strategy, and how to do Agile risk management.
Continue reading →

One Page Agile Standard for team of 350

Posted on by

For the last two years I have been rolling out a standard Agile approach to a department of 350. One part of the roll out strategy was to have a published standard. This was to make the goal / end-game obvious even if we didn’t initially mandate everything.

The first version of the standard, published Oct 2006, was a 50 page document. Earlier drafts had been quite short but in reviewing the document people kept asking “What does that mean?” so we’d add another section explaining it. All rather worthy but, aside from the initial reviews before publication, nobody read it. And it diluted the document as a standard, defining what must be done, as opposed to a guideline about how to do it.

We published version 2 today. This version of the standard is one page. I want to give people a simple checklist so they know whether or not they are following the standard.
Continue reading →

Scaling Agile Software Development for Larger Projects

Posted on by

“Small projects can succeed through sheer force of will and a bit of luck.  Medium and large projects require a more systematic approach” (McConnell, 1998, p. 36).

Most of the Agile Software Development methods are designed for small team sizes, for example the original XP team had 8 people, but what if we’re talking about 30 developers (let alone customers); what process should we use?
Continue reading →