agile > chapter 2 launch and planning > 4 knowledge management areas

Knowledge Management Areas

Traditional management approaches address various knowledge areas that we must consider in the agile context, some of them being a part of the triple constraint (time, cost and scope).

Time

It is common for agile teams to assign pointsinstead of counting the time in hours. The problem with this is that it introduces too much mental overhead for the team. People are generally bad at giving an estimate of the time it will take to complete a task, worse yet an entire iteration. This issue becomes more complicated when we factor in working with dependencies and time taken to do research into solutions for unfamiliar tasks.

The best thing to do would be to overestimate the time and maximize the work done in that time. Assign more hours than needed thus leaving room for corrective work, research and dependency resolution. Eliminate the mental overhead required for assignment of points.

Scope

The agile approach has the project backlog as its centerpiece. The scope of a project is determined by the number of requirements that can be fulfilled with a given schedule and budget. Recall that agile dictates that in the triple constraint, the scope depends on the cost and time we have available.

Each requirement is based upon personas we create to serve as representations of the users of our product/system. The scope grows as we complete requirements in the backlog and satisfy the various personas. Our project ends when all of the requirements are complete.

We should not worry about creating an "incomplete" product because every iteration serves to produce a result that delivers business value to the customer. If work on the project has to end because of a lack of funding or a strict deadline then our work has not gone to waste because the product delivered value since the first iteration.

Even the requirements that are deemed no longer desirable are of value to us because we learn what does not serve to add business value.

Cost

From the first iteration, we can determine the projected cost per iteration and thus we can estimate the total cost of the project.

We should keep track of the actual cost compared to the projected cost of each iteration. From this, we can gain insight on factors to consider when estimating costs in the future.

Risks

By overestimating the time required to complete a set of tasks, we can reserve time for risk detection and mitigation. The project roadmap will thus include time for the team to handle risks and errors.

If the project would take about 30 days, we can reserve to have an extra 5 days buffer time. If these extra days cannot be allowed by the stakeholders then the number of requirements will have to be reduced to leave time within the 30 days for handling errors and risks.

By using a kanban board, we can see easily where work is slowing down due to errors and lack of technical knowledge. Less wastage leads to lower risks - by improving efficiency we lower the risk of fulfilling all the requirements on time.

For the retrospective meetings, we prioritize informing the team of issues from the previous iteration to ensure that systems are put in place to reduce the chances of these issues recurring.

Stakeholder management

Stakeholders are present when we decide on the requirements and their priorities. Stakeholders are present in the daily meetings, demos and retro meetings. Information is easily accessible to them and the tools we use are information radiators to help stakeholders.

Quality

The quality of our product is determined by how well it fulfills the requirements. Having many features should not be valued above having a few features that deliver a lot of business value to our customers. A to-do list mobile app that runs quickly and allows users to keep track of their completed tasks is much more valuable than one that provides more features like fancy animations and many customization settings but takes very long to open and slows down the user's device.

Types of requirements

There are two types of requirements:

A product must have both before it is considered to be usable. Do not make the mistake of saying that work is complete when only the functional requirements have been met.

Do not add unnecessary features to "gold-plate" your product. If it cannot fulfill the functional requirements as well as the non-functional requirements then it makes no sense trying to add other features in hopes of convincing customers to use your incomplete product. Solve the real problem.

Human resources

The work team is pivotal to the project. All of the tools and meetings are utilized and owned by the team. If a process does not serve to motivate or benefit the work team then it is a hindrance to the project.

Acquisitions

Managing procurement is done in the same way as in traditional methods.

Communications

Communication between and within the work team and stakeholders is important in agile. We use information radiators to make information readily accessible by all parties.

Information radiators include Kanban boards, roadmaps, delivery plans and improvement plans.

Integration

The agile facilitator serves to support the work team through procurement of resources and management of external dependencies, encourage communication between work team and product owner, promote agile practices and coach the team in agile.