Quality Management, in a project context, is concerned with having the right processes to ensure both quality product and a quality project. This article describes Traditional Quality Management, Agile versus Traditional Quality Management, Agile Product Quality, Agile Project Quality, Agile Product Quality, Agile Quality Assurance and Control, and Agile Quality Improvement.
Continue reading
Category Archives: Article
Agile Project Estimating
Estimates are an essential part of Agile Project Planning. Software estimation has always been problematic and people have proposed many different ways to do estimating. Different methods are on a spectrum from formal to informal and from supposedly objective to seemingly subjective. Different methods also get individuals estimate or groups. And some methods estimate size and derive effort while others estimate effort directly. Estimating in the Agile world has settled a certain approach which might be characterised as expert group estimation of size. this article covers Traditional Project Estimation, Agile versus Traditional Estimating, Estimating User Stories, Estimating Tasks, Contingency, and Agile Ballpark Estimates.
Continue reading
Agile Project Execution
Executing is one of the five project management process groups in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).
Project Execution is where you build the project deliverables and hand them over to your customer, i.e. where you build and deliver the software. This is where most of the project effort is invested. Agile Project Planning says what you intend to do, when, and Agile Monitoring & Control helps you stay on track but Agile Project Execution is where you do the business.
Continue reading
Agile Project Monitoring and Control
No battle plan survives contact with the enemy
Field Marshal Helmuth Graf von Moltke
Life is what happens to you
while you’re busy making other plans
John Lennon
Agile Project Planning tells us what we expect to do, but, to paraphrase the quotes above, plans often turn to custard. The job of the Agile Project Manager is to guide the team to successful delivery despite the challenges the world throws at the project. This article is about monitoring the project against the plan and intervening when we notice things going off track. In particular it covers Traditional Project Monitoring & Control, Agile versus Traditional Monitoring & Control, Agile Project control, Agile project metrics, Agile Project Reporting, and Agile Project Monitoring.
Continue reading
Agile Roles and Responsibilities
Each of the Agile methods includes defined roles. Some have more, some have, less. DSDM is the only one of the methods that makes a big deal of making role responsibilities explicit but I think this is important. To work effectively as a team people need to know what their role is and the roles of their peers. I have often had to coach teams on the demarcation between key roles on the team – typically the leadership roles, i.e. project owner, agile project manager (or scrum master) and technical lead.
Continue reading
Agile Change Management
My background is running Agile projects for external customers in the context of a contract, often fixed price. That influences my focus on good project management and specifically change management. Change Management is the mechanism to combat scope/feature creep.
Within the Agile world scope change is expected and time is considered more important than functionality. So if something has to give to allow change then functionality/scope loses and time wins. To do this the customer must make Requirements Trade-offs. The Customer directs development in Timebox and minor changes are just accepted. Big changes are handled different depending on whether it is a change to the Release Plan or Timebox Plan.
Continue reading
Agile Project Closure
Agile Project Closure is about handing over to the operations team, tidying up any loose ends, reviewing the project, celebrating, and going home.
Continue reading
Agile Post-project
The Agile Post-Project phase is not really concerned about the project that preceded it, but is instead concerned about the product that resulted. It is a good idea, but in my experience uncommon, to check that the product meets the business need for which it was created. Often this can only be done some time after the project ends, say 3-6 months. The Product Owner is responsible for organising the review and accountable for the results.
Agile Project Planning
No battle plan survives contact with the enemy
Plans are nothing, but planning is everything
Field Marshal Helmuth Graf von Moltke
I believe that Agile Project Management provides certainty of delivery. Planning is what lets us answer the question “When will you be finished?”. Planning is, however, just the start of the process. As Moltke pointed out planning is more important that the plan because once you start the project you’ll find the plan is wrong and you have to adapt. All plans need revisiting and you will have to use Agile Project Control, Agile Change Management, and Agile Risk Management to get the promised certainty of delivery.
Continue reading
Agile 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:
- Exactly what problem will this solve? (value proposition)
- For whom do we solve that problem? (target market)
- How will we measure success? (business metrics)
- What alternatives are out there? (competitive landscape)
- Why we are best suited to pursue this? (our differentiator)
- Why now? (market window)
- How will we deploy this? (gentle deployment strategy)
- What is the preliminary estimated cost? (small/medium/large)
- 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.