Introduction
Schedule driven projects are often run as waterfall projects. This assumes requirements will be done up front. What happens when a project is schedule-driven and there
is no clear vision for the product? What happens when the deadline is approaching and there are still no requirements?
How do you succeed in an environment where the project sponsors do not know all of the requirements? How do you succeed if the project sponsors
do not trust the development team to implement rules as they interpret them?
"I want to know exactly what I am getting before you start", says the sponsor.
"But," the developer starts, "you don't know quite what you want yet. I can give you the parts that you already know you want while you decide on the rest."
Trying to be agile in a schedule-driven organization
What could help us? We need requirements at least one sprint before we are meant to work on them. This gives the team ample time to review them for completeness.
Although it sounds obvious, the point must be made that requirements must be complete and correct at some point before implementation on those features is to begin.
When new requirements change requirements that have already been implemented, this simply needs to be prioritized in the backlog along with the other new requirements.
Every item in the backlog needs a High Level Estimate and a Customer or Business Value. The priority of an item in the backlog is a judgment call between the HLE and the CBV.
Each organization’s measure of CBV is different, but it should be more scientific than seat-of-the-pants – otherwise, the features presented by the business sponsors with more
clout can take priority over the features that are more important to the customer.
While requirements can come in effectively any time before work is to begin on implementing them, there should be a clear vision for the product set from the start.
The development teams can't simply turn away changes. A formal Change Control process is not strictly necessary, either. How do you determine what is change when no base
line of requirements has been created? Everything is a change or nothing is! Obviously, this cannot work. Rather, work to promote a middle-ground strategy.
A "Change Control"-worthy requirements change is not significantly different from a new requirement or enhancement. It needs to be prioritized and estimated,
and then managed in the backlog to be re-prioritized whenever the sponsor sees fit. It is like any other backlog item in that it takes time to implement. This means that
the sponsor, the backlog owner, needs to actually analyze whether re-prioritizing a certain feature truly equates to a happier customer.
When the delivery date is the most important factor in a product development cycle, the scope needs to be properly adjusted to ensure that something of value
will be delivered on the due date. Ideally, the due date is driven by the estimates for the features included in the release's scope, but there are times when rather
than the scope dictating the date, the due date dictates the scope. This makes the sponsor's job harder because the high level estimates have a built-in degree
of inaccuracy as the requirements are still forming, and when there are set-backs, the backlog needs to be carefully managed so that the team can deliver a product with value.
In an agile project, there are some tools and strategies to deal with this type of uncertainty.
Applying Agile
In the daily stand-up, all team members give a summary of the state of their work. This gives greater visibility into any hold-ups that may be impeding progress,
but it also calls into question the validity of a team member's estimates.
Initially, team members may take offense to being questioned regarding their estimates and actual work, but it does encourage better accuracy in both estimates and tracking
work on other tasks. In addition to the standard scrum questions (what did you do yesterday, what will you do today, and what is standing in your way), add to each report
on a bug or development task the actual hours worked against the estimate, if there is one.
Overall cost is an important factor to project approval. High-level estimates are factored into the cost estimate, but since each release is based on value, a cost estimate
based on scope should be acceptable. This means that while the overall program vision will dictate the scope and direction of the product, the actual projects themselves
will be much smaller. The program as a whole is not "The Project". A project is made up of the work and scheduling surrounding implementing features and changes (and fixing defects!)
that will improve the value of a product release. When projects are iterative, rather than monolithic, it is easier for the team to track progress and react to change.
Agile development does place some more work on a project manager's plate. She has to manage the overall project plan, the results from the previous release, and the progress
toward the next release. Additionally, she needs to make sure the requirements are ready for implementation by the time their backlog priority has reached the top of the stack.
In order to perform this task well, the project manager needs to be comfortable with uncertainty. She needs to understand there are pieces of the product we may
know nothing about before we implement them.
Adopting an agile project management style is difficult without buy-in from the entire product team. When a radical shift in management style is imposed on a team,
particularly with team members who are set in their ways and uncomfortable with change and ambiguity, there will be resistance. Additionally, the sponsors and business
analysts need to understand the process when creating their requirements. Constant change is allowed, but change has a cost, and it has to be prioritized like every other requirement.
What's missing?
Many teams with an incomplete adoption of agile methodologies across the entire organization often lack some of these:
- Complete and usable business requirements. This is to highlight that the state of the requirements being given to the developers is not complete enough.
Requirements for a feature should be complete before they are handed to the development team for implementation. The development team should have the right to refuse
requirements that are incomplete.
- Product owners who communicate with each other to identify requirements and features that might compliment or contradict other streams.
- Development tests that exercise the acceptance criteria. These identify holes in the requirements and contradictory Acceptance Criteria.
- Sponsors who understand customer value and are capable of prioritizing requirements based on that value.
- Sponsors who understand that high level estimates are estimates. Developers should be held accountable for their high level estimates,
but the sponsors need to understand that these estimates are based on incomplete information, incomplete requirements, and without thorough work breakdowns.
If a development team says a feature will take about two weeks, the sponsor should not immediately jump to the thought, "Great, I can have it 10 days from now!"
- Product owners who are actually consumers of the system.
- Business value assigned to each feature.
- Product owners with the empowerment and authority to make decisions about features and requirements.
- An iterative release schedule, with the unhindered ability to make several quick releases.
- A product roadmap with future releases and incremental scope increases.
- Project managers who value the output more than the process.
- Accurate, honest actual hours worked from the development teams.
Lessons
What have I learned?
- Assign risk, value, and priority to all changes in requirements.
- Agreement is key.
- Senior team members should understand the direction of the program.
- Do not accept requirements that are not complete. The time it takes to rework the actual work is far longer than the time it takes to rework the requirements.
- Developers should include their actual hours vs. their estimated hours in their scrum updates.
- Designing first and testing last is not agile.
- Agile architecture - just in time design. Follow the vision of the product. Don't design for requirements you don't have. Don't do "What if?" architecture.
- Designing a system to be easy to change is far more important than designing a system to handle every possible eventuality.
- The architect decides when a design or an implementation is good enough to fulfill the current requirements.
- Once decisions are made, they should be accepted by every member of the team, regardless of their agreement with the decision.
- Disagreements of team members of leaders' decisions should be raised in the sprint retrospectives.
Summary
Running an agile project requires a strong leader who has the ability to make decisions quickly and finally. The leadership team has to embrace failure. Some of those
decisions may turn out to be incorrect, but the agile methodology allows those decisions to be corrected with far greater ease than in a waterfall environment.
Each incorrect decision should be viewed as a learning opportunity and discussed during the retrospective. The project leaders must be comfortable with ambiguity
and change, and must continuously drive the project forward. The project leaders must have a clear vision about the product and its future, and its direction,
and be able to communicate that vision and direction to the team. Without this strong leadership, none of the team has confidence in their ability to deliver
a product that follows the vision. In short, it is very difficult to measure whether people are doing things correctly if they do not know whether they are doing the correct things.
