The document discusses blended agile, which combines agile practices with more traditional methods. Blended agile is useful when an organization cannot immediately switch to a full agile approach. It allows gradual introduction of agile practices while integrating existing traditional methods. Examples of blended agile include using iterative cycles but planning requirements far in advance, having teams work together for only part of the day, and applying agile practices to less critical modules before more critical ones. The document provides advice on setting up a blended agile process and addressing potential conflicts between agile and traditional methods.
2. CC Pace Proprietary www.ccpace.com
What is Blended Agile?
• Blended Agile is a term we use to describe a combination
of agile practices/techniques integrated with more
traditional methods.
• This is generally a result of a scenario where an
organization can not flip a switch overnight and move to
a full set of agile practices.
• The company slowly initiates agile practices, increasing
them over time while integrating with traditional practices
that still have value to the organization but are not part of,
or sometime might even be in conflict with, agile
practices.
3. CC Pace Proprietary www.ccpace.com
Blended Agile
• Blended Agile will utilize some of the Agile practices along
with other practices from methodologies such as spiral,
DSDM, etc.
• Blended Agile is not Agile in its purest form. Thus you will not
obtain all of the benefits of Agile.
• Blended Agile will allow your organization to improve its
current practices.
4. CC Pace Proprietary www.ccpace.com
Examples of Blended Agile
• Iterative cycles with requirements established several
iterations before
• Mini waterfall iterations
• Reduction of team time together
– Scheduling of product owners time on specific days
– Working together for a short percentage of time during
the day , perhaps just for the daily standup and doing
work at your desk
– Use of IM
• Break project into modules
– Low criticality is done using agile
– Over the course of time higher criticality modules use
agile
5. CC Pace Proprietary www.ccpace.com
What we will cover:
• High level overview of Agile
• Differences and Conflicts between Agile and Traditional
Methodologies
• The Journey to Agile and why using a Blended Approach
can be an Appropriate Approach for you Company
• Examples of Blended Agile
• Key Points to Take Away
6. CC Pace Proprietary www.ccpace.com
What is Agile?
• A conceptual framework for software development that
promotes development iterations, open collaboration,
and adaptability throughout the life-cycle of the project.
• Simply stated, the ability to respond to change.
7. CC Pace Proprietary www.ccpace.com
Agile Principles
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
Although there is value in the items on the right, we
value the items on the left more.
8. CC Pace Proprietary www.ccpace.com
Agile Practices
• Breaks projects into ‘functional slices’ for incremental
delivery.
• Consists of short development cycles.
• Supports Empirical methods to monitor progress and
allow for rapid change.
– Inspect and Adapt mechanisms
• Anticipates that baseline requirements will change.
– Resulting in a product which more closely meets
customers needs
• Agile is not without its own structure and control
mechanisms.
9. CC Pace Proprietary www.ccpace.com
Agile Process Framework
1-4 weeks
24 hours
Product Backlog
As prioritized by Product Owner
Iteration Backlog
Backlog
tasks
expanded
by team
Potentially Shippable
Product Increment
Daily
Meeting
PRODUCT
BACKOG
ITERATION
BACKLOG
BURNDOWN
CHART
ITERATION
DEMO
RETROSPECTIVE
10. CC Pace Proprietary www.ccpace.com
Implications of Agile
• No traditional phase gates; functions are done in parallel in very
small batches.
• Not everything will get done; this is good! (45% of it is never used
anyway).
• The highest priority work will get done and will be done early.
• Requirements will not be highly defined in advance.
• Requirements will change; this implies that code will change and
test plans will change.
• There will be much better communication, coordination and
alignment.
11. CC Pace Proprietary www.ccpace.com
Agile Myths
Agile Is NOT:
• A silver bullet solution
• New and unproven
• A methodology without any
planning/documentation/architecture requirements
• A license to hack
• Undisciplined; it actually has many controls
• A methodology that creates quality issues
• A final solution to all project resourcing issues
13. CC Pace Proprietary www.ccpace.com
Traditional vs. Agile
• Most traditional methodologies consist of several phases to
develop/enhance applications.
– i.e. requirements phase, design phase, build phase and
implementation phase
• Agile development utilizes iterations which combine to equal
a release (an individual iteration can also be a release on a
very small project).
– Iterations consist of all of the above phases, except at
times implementation.
– Implementation may happen at the release level.
14. CC Pace Proprietary www.ccpace.com
How Is Agile Thinking Different?
Topic Traditional Agile
Driver Plan-Driven Value-Driven
Resources Partial allocation Dedicated
Sponsor Involvement Ad Hoc Daily
Change Is a risk, minimize it Is a competitive advantage,
embrace it
Leadership Command and control; Telling,
Directive
Servant Leadership; Participatory,
Facilitative
Lifecycle Phased Approach; Serial,
Sequential
Short Iterative Development cycles,
Incremental Delivery
15. CC Pace Proprietary www.ccpace.com
Traditional vs. Agile
Traditional Thinking Agile Thinking
Gathering all requirements weeks or months before
development begins
High-level requirements gathered and then supports
evolutionary requirements
Full up-front design and architecting “Just enough” design and architecting
Descriptive approach - plan what you expect to happen Empirical approach – inspect and adapt mechanisms with
early and continuous evaluation
Uses formal processes to control changes Anticipates change to baseline requirements
Command and control leadership style Leadership by influence
Heavily matrixed team members Dedicated, self-organizing, cross-functional teams
Phased approach Short development cycles delivering continuous functional
slices of incremental value
Process focused Value delivery focused
Heavy documentation requirements Consistent level of lightweight documentation maintained as
the project progresses
Information disbursed across many individuals with low
visibility
Highly visible information to business and IT in a collaborative
work environment
16. CC Pace Proprietary www.ccpace.com
* Top 3 reasons from CompTIA survey, Mar 2007
** misc reasons from other sources
A Different Approach to the Same Problems
Some Reasons
Projects Fail
Traditional Solutions Agile Solutions
Poor Communication * Status Meetings; Communications Plan;
Stakeholder Meetings
Daily Meetings; Collaboration; In-
Room/table dialog; Retrospectives
Inadequate Resources * Request and justify additional resources Assign dedicated teams; whatever team
is available only commits to work they
can do
Unrealistic Deadlines * Identify risk; Compute additional
resources needed to make the date;
request; re-work the schedule/budget
Deliver in time-boxes; estimate
completion range based on team
velocity; negotiate scope
Requirements Changes ** Submit Change Requests; re-work
schedule
Add new stories to Backlog; prioritize;
pull into iterations
Lack of user involvement ** Request a project sponsor or SME rep Dedicated Product Owner involved with
the team on a daily basis
People Problems ** PM intervention/Coaching Connectivity; Ownership; Team Norms;
Values; Collaboration; Co-location;
Retrospectives; Team Self-Policing;
Coaching
17. CC Pace Proprietary www.ccpace.com
Waterfall, Spiral, and Agile Development
• The waterfall life-cycle model has been closely associated
with heavyweight documentation.
• The spiral model has been misinterpreted as an incremental
waterfall model, rather than as a risk-based model. Spiral
also responds to change, thus is adaptable.
• Agile focuses on people (individuals, stakeholders), products
(working software, key artifacts), and change (responding to
change, adaptability).
– Notice that common to both the Agile Manifesto and
Spiral is adaptability.
19. CC Pace Proprietary www.ccpace.com
Conflicts Between Methodologies
• Working Software vs. Early Design Documentation
– The conflict between what is perceived the end-customer
wants and what is being asked.
• Single vs. Multiple-Increment Life Cycle
– Agile teams focus on achieving customer satisfaction
through frequent software deliveries based on clear
priorities.
– Agile teams are also usually small and often do not have
adequate resources to work multiple risks in parallel.
– The single iteration through the waterfall model with the
planned single milestone can be a project management
conflict for the agile team.
20. CC Pace Proprietary www.ccpace.com
Conflicts Between Methodologies
• On-Site Customer Collaboration
– Agile requires the customer to become part of the
working team. This role is known as the product owner.
• Business members are not use to dedicating time to
the development of a project throughout the project’s
lifecycle. Previously the business person/product
owner provided input at different stages of the project.
• Formal Deliverable Documentation Weight
– Agile methods tend to promote lightweight
documentation. This is because agile values working
software more than documentation. In most companies
cultures, documents tend to be on the heavyweight side.
22. CC Pace Proprietary www.ccpace.com
1. It requires thinking and acting in new ways
2. Roles/Responsibilities will change
3. Interactions will change
4. Processes will change
5. People resist change
There are ‘just’ two problems left to solve in business
– People and Change.
-- Bob Eichenger, Co-Founder, Lominger International
Why Isn’t Moving to Agile Easy?
23. CC Pace Proprietary www.ccpace.com
Un-responsive
To
Change
Responsive
To
Change
Co-located Teams
Daily Meetings
Regular Reflection,
Inspection, &
Adaption
Adaptive
Planning
Iterative &
Incremental
Delivery
TDD
Automated
Testing
Continuous
Integration
Everyone’s journey will be different, because starting points are
different, environments are different, and obstacles are different.
A Journey
24. CC Pace Proprietary www.ccpace.com
Why even bother Blending?
• The success of Agile is clear and gaining some of those
benefits through small improvements is worthwhile
• Providing Business partners with earlier delivery of results
and early access to a working system
– Time-to-Value
– Time-to-Market
• Flexibility to requirements change
– Evolutionary Requirements
• Improved Business - IT collaboration and trust
• Increased Customer Satisfaction
• Increased Quality
25. CC Pace Proprietary www.ccpace.com
Why even bother Blending?
• It takes time to move to a full Agile capability.
• Companies have real obstacles that do not allow them to
move as quickly.
• Companies must collaborate with internal areas and outside
organizations utilizing traditional development processes.
• Companies have standing processes that can not be
changed with a flip of a switch.
• Taking a blended approach reduces the perception of risk.
• Taking a blended approach gives the organization time to
learn and to adjust which practices are right for their
organization.
27. CC Pace Proprietary www.ccpace.com
General Blended Core Commonalities
• Plan Collaboratively and Use an Incremental Life Cycle
– the initial planning to be done collaboratively between
the team and the customer
– an incremental life-cycle model employed to align the
blended project within the overall project schedule
• Use Iterative development and Risk Check points
– provide working software early to address high-risk areas
– ensure all the risks are being addressed and prioritized
28. CC Pace Proprietary www.ccpace.com
General Blended Core Commonalities
• Plan for Multiple Documentation Drops
– provide multiple drops of documentation before the
delivery date to obtain early feedback
– consider use of a team member each iteration to
capture documentation
• Make Customer Collaboration Work
– encourage and support as much customer collaboration
as you can between the blended team and the end-
customer to help manage your own risk
– provide documented list of agreed-to stories to be
completed in the upcoming iteration/release
– conflicts associated with vague requirements can often
be resolved quickly
29. CC Pace Proprietary www.ccpace.com
Potential Consistent blended practices for the Teams
Metrics
• Hours
• Days
• Points
Planning sessions
• Two levels of planning
– Allows communication of the objectives to the
project team, the executive stakeholders and
customers:
» release level - preparation for deployment to
end users
» iteration level - time-boxed increment of new
functionality
30. CC Pace Proprietary www.ccpace.com
Potential Consistent blended practices for the Teams
• Lessons Learned/Retrospective
• Demo
• Daily Stand up
• Iteration 0
• Kick off
• Customer/team collaboration and communication
• Use an Incremental Life Cycle (2-4 weeks)
• Common vocabulary
31. CC Pace Proprietary www.ccpace.com
Potential Consistent blended practices for the Teams
• Test driven design and development
• Active Stakeholder/Champion Participation
• Core hours
• Established Team Norms
• Fun budget
• On boarding
• Establish Roles
• Change acceptance
32. CC Pace Proprietary www.ccpace.com
Possible Blended Variables Per Team
• Co-location
• On boarding process
• Toolsets
• Time dedicated to the project
• Length of iteration
• Start of iteration
• Order of deliverables at end of iteration
• How status is covered in daily stand up
• How board is set up (User Story Card)
• Configuration of room
• Scope changing
• Presentation of backlog
• Documentation flexibility
– Multiple drops of documentation be provided
– Depth
• Estimation method
• Contingency story card
• Methods of Education
• Methods of Communication
33. CC Pace Proprietary www.ccpace.com
Possible Blended Common Practices Overall
Organization Overall
• Informal user community
• Established success criteria for the teams
• Product backlog required
• Blended vocabulary
• Planning
• Environment foundation
• Core documentation
• Compliance/audit
• Budgets
• Collaboration
• Use of core Agile group
• Use metrics
• Communication Lines Open
• Education
• Test driven design and development
• Active Stakeholder participation
• On boarding
• Roles
34. CC Pace Proprietary www.ccpace.com
Suggested How To Steps for General Blending
• Know the existing processes
– Identify the existing process/ methods being utilized
– Analyze what is working well and what can be improved
• Gain knowledge of best practices
– These are from multiple methodologies
– Review best practices and analyze which ones make
practical sense to begin with
• Obtain management support
• Obtain team buy in
• Select a pilot project
– Begin with just one project
35. CC Pace Proprietary www.ccpace.com
Suggested How To Steps for General Blending
• Collaborate with the team
– Once the team is selected include the team in planning
and making decisions
• Advertise/communicate what you will do
– Kickoff
• Determine the strategy
– Organizationally
– Departmentally
– Team
• Constant retrospectives for lessons learned
– Employ changes based on lessons learned
36. CC Pace Proprietary www.ccpace.com
Blended at your Organization
Document and Communicate Your Blended Process
• The PMO group or Core Agile group can become
involved at this point.
• Assign a team member to frequently document.
• Share documentation with other areas within the
company.
- A shared drive?
• Presentations to other areas in the company .
• Presentations to management.
• Frequent brown bags to share status and knowledge
gained.
• Production of a checklist and or variance document to
help the new Blended Agile PM and Blended Agile Team
adjust to differences.
37. CC Pace Proprietary www.ccpace.com
Blended at your Organization
• Recognize that blended consists of feasible best practices
• Recognize that blended can be different among teams and
departments
– Different teams may employ different forms of blended
while maintaining organizational established core
principles
38. CC Pace Proprietary www.ccpace.com
Conflicts in Setting up a Blended Process
• Many of the conflicts are rooted in the up-front
thinking/planning that comes with the one cycle waterfall
model.
• Several project management conflicts that companies face:
– Full Life Cycle vs. Multiple-Increment Life Cycle
– Documentation Weight
– Role confusion
– Working Software vs. Early Documentation
– Customer Collaboration on site
– Changes in Requirements and Testing higher level descriptions of
business flows, called "User Stories" or "Use Cases”
– Testing consistently
– Time commitment
39. CC Pace Proprietary www.ccpace.com
Strategies to Avoid Conflicts
– Once an iteration is under way, requirements must remain
fixed to avoid chaos
• Add a contingency story card
– Multiple drops of documentation to be provided
• Reduces risk, obtains early feedback
– Use of core Agile group
– Use metrics
– Use iterative cycles
– Communication Lines Open
• Documentation
• Presentation
• Education
• Establish common vocabulary
• Project
– verbal status
– examples of the outcomes
– visual boards
– virtual boards
– retrospectives
41. CC Pace Proprietary www.ccpace.com
Real Life Blended Case
Background/Problem Description
• This Fortune 500 company was looking to become more
effective by improving on the integration points of multiple
systems and improving the functionality of a trading system.
The current process required multiple manual processes which
were time consuming.
• Time to market was imperative and budget was limited. Since
there were so many tentacles and integration points from
other departments and third party companies, this project also
was restricted by several regulations. Management buy in and
support for the project was needed from all of the integration
groups.
• The company was ingrained with older methods of project
management and software development. However, due to
the size and complexity of this project, they knew they would
need to employ a different methodology to be successful.
42. CC Pace Proprietary www.ccpace.com
Real Life Blended Case
Method
– The client chose to employ a Blended Agile methodology
that would improve delivery time, provide working
software that satisfied the need of the customers, and
conserve budget dollars.
Approach
– Held discovery sessions to determine readiness to use a
Blended Agile methodology.
– Formed a Blended Agile team.
– Created the setup/iteration zero for the blended agile
team.
– Analyzed which agile practices would be feasible to
utilize within their blended methodology now and in the
future, while continuing to introduce new practices.
– Determined which existing processes and best practices
to utilize.
43. CC Pace Proprietary www.ccpace.com
Real Life Blended Case
• Agile Competency Development
- Training – overviews, lunch and learns, team meetings
- Agile techniques training – stories, backlog, planning,
vision box, etc.
- Extensive training/coaching of the slated agile coaches
- Mentoring – Coaches, Team, Managers
• Program Development
- Governance approach
• IS Senior Management Updates weekly
• IS Steering Committee Update
44. CC Pace Proprietary www.ccpace.com
Real Life Blended Case
• Co-location was sporadic and only occurred during the
core hours
• Resources were part time, not dedicated
• Instituted Core Hours
- 9 hours a week
• Obtained executive buy in and support for the project
and a blended agile methodology
• Established acceptance criteria for project success
• Physical Environment
- Room which was shared with other projects
• Team
- 2 Developers/analysts, 2 extended team developers, 2
Product Owners/QA, Agile Coach apprentice, Agile
Coach
45. CC Pace Proprietary www.ccpace.com
Real Life Blended Case
Key Results
– The organization began to view blended agile as just a different
technique for project development
– Future team coaches were developed through the process
– Teams became true teams and morale increased
– Earlier releases into production were enabled giving the customer
faster workable software
• Although only 9 hours a week, when the first release was
implemented the management/team calculated the actual
time form start to finish to be about two weeks.
– Delivering in two weeks workable software was phenomenal
for this company.
– Knowledge of Agile and forming blended practices occurred
simultaneously
– Determining which practices to use occurred simultaneously
– Cross functional knowledge was shared and then utilized for future
projects
– 2 Teams Begun
– Slated two more teams
46. CC Pace Proprietary www.ccpace.com
Real Life Blended Case
Lessons Learned
• Establishing the set up of a blended agile project is crucial
to the success of the project; the set up differs per
project.
• No two blended agile projects are exactly alike from a
practice perspective.
• Determine up front the right team members.
• Establish an on boarding process including team
introductions and a project boot camp and implement.
• Consider how to use team members time wisely.
• Research should be done up front.
47. CC Pace Proprietary www.ccpace.com
General Blended Lessons Learned
Lessons Learned
• Each organization is different.
• Any combination of best practices is good.
• Consistently evaluate and adapt.
• Learn your existing process first.
• The amount of time dedicated is ok.
• Co-location is helpful but not necessary.
• Communicate the same message.
• Make sure all organizational levels are on the same page.
• Learn agile principles first, then begin to blend.
• Consider academic but be practical.
49. CC Pace Proprietary www.ccpace.com
How to Recommendations
• Agile Core Group/Agile Steering Committee
• Foundation of Knowledge
• Develop community
• Communication
• Collaboration
• Obtain coaching or help from a practical experienced
person in the beginning
• Re-evaluate consistently (inspect and adapt)
50. CC Pace Proprietary www.ccpace.com
Bottom Line
• Agile methods bring many benefits.
• Plan-driven methods bring benefits as well.
• Most companies can not change their processes overnight.
• Utilize practical best practices over academic best practices.
• Collaboration of the best practices feasible within your
company will increase progress.
51. CC Pace Proprietary www.ccpace.com
Core Thoughts to Remember in Blending
• Keep it simple
• Being Agile is the ability to move quickly and respond to
change
– This is a core principle in blended as well
• Build the internal and external capabilities
• Academic vs. Practical
– Training is not enough you actually need experienced
coaching ongoing journey
– Always refer back to the principles for alignment
– Employ changes based on lessons learned, inspect and
adapt
• Collaborate and communicate
– Advertise/communicate what you will do
– Insure and support core believers
52. CC Pace Proprietary www.ccpace.com
Core Thoughts to Remember in Blending
• Adjust the organization’s mindset to be fully
committed by all “no longer a pilot”
• Will not happen with a flip of a switch
• Realize that this is an evolving process
Value-driven: two levels
values that are explicitly identified in the Manifesto values & principles and those that drive how the team works together
values of the features for the customer
Traditional environments frequently (not always)
discourage people from feeling responsible for anything but their own work/area;
Inhibit true teamwork and encourage white-knightism
Leadership in Agile
More Situational style leadership employed
PM (if there is one) becomes less a master of tasks; keeps a broader view and manages external communications (very Liberating when you realize it’s not all on your shoulders!!)
Leadership is shared or rotated among team, giving them a sense of ownership and empowerment, and also teaching them
Agile works because by its very nature it addresses the reasons that projects fail, and it focuses on building healthy teams and creating environments which support and sustain them
That’s the Secret Sauce of Agile!!
It’s also why you hear proponents say that you have to follow “all” of the practices of a particular agile method….because in that way you will maximize your successes….the more you don’t use, the more impediments will remain hidden and the more risk will remain in the environment.
Connectivity = how connected people are to their work and to each other; connectivity of a team is highly correlated w/ it’s performance (i.e., high performing teams have high connectivity; Meta Learning Model by Marcial Losada;
other factors =
Inquiry/advocacy; how much people ask vs talk
Positivity / negativity; how much people are positive vs. negative
other / self; how much people are focused on others vs. themselves
Why doesn’t Traditional work –
It can…..in the right circumstances, with the right leadership
But generally, the right circumstances don’t exist, and it’s very hard to succeed
The environment, context, structure, and culture limit options, which limits the ability to respond to changing circumstances (e.g., if you’re doing serial development, it’s hard to switch gears)
Sometimes Agile DOESN’T Work – Why not? –
For the same reason Traditional doesn’t – the environment / context is not conducive; but even then, agile isn’t the problem…..but it will highlight the problems more quickly, make them visible sooner
It seems like common sense, so why isn’t it easy…..because people are involved….and people aren’t easy
Roles / Responsibility changes: People often define themselves by their jobs; when they no longer do their job in the same way, they can become lost for awhile until they learn to see that they still have worth and value (e.g., analysis is still valuable even if a particular document is no longer produced)
Interaction Changes: No more “throwing things over the wall” to the next functional phase; People must take ownership, they can’t hide in obscurity or the mediocrity of the process…and that can be scary for some people
Processes that may change: Development (pair programming); Testing (moved forward); sign-offs (bye-bye)
Resistance: people have different tolerance levels for change, but for many people there is some element of fear; that fear is because change always brings destruction along with creation; it destroys part of our old life (one we were comfortable with, even if we weren’t happy with it), and creates something new in its place, something unknown and unfamiliar to us.
George Bernard Shaw said: “Progress is impossible without Change”…..Terry Neil wrote, “Change is a door that can only be opened from the inside.”
For true and lasting change, it has to start from within….and that’s why agile isn’t easy.
It’s a JOURNEY
These are not all the possible steps on the journey (e.g., these represent the practices, but not the values)
Every step you can successfully take and maintain will get you closer to the goal
Remember to THINK….WHY are you doing it
Some believe those who use agile methods do not follow a plan. This is a misunderstanding. Planning is actually a core principle of agile methods [7]; however, agile teams tend to plan in smaller time increments and more frequently than those who use traditional methods. This distinction has been clarified by the characterization of XP as planning driven rather than plan driven [8]. Planning takes place with both methods, but with agile methods the focus is on the act of planning, rather than a document. Using an incremental life-cycle model is critical because many of the conflicts observed are rooted in the all up-front thinking that comes with the single- increment waterfall model. Incremental thinking is fundamental to agile methods and crucial to bridging the two methods.
The frequent feedback from multiple spirals can help your risk mitigation visibility and ultimately your project's success.
One common misperception of agile methods is that the requirements are not controlled since they are allowed to change late in the game. This is a legitimate concern that could also fuel why a prime contractor might want to keep an end-customer away from an agile subcontractor, but it also demonstrates a fundamental misunderstanding of agile methods.
As Craig Larman explains, "Iterative and agile methods embrace change, but not chaos
creep, which often fails to get recognized until late in the project's test phase when the customer starts writing new discrepancies because the product does not meet what they now perceive the requirements to mean.
This presentation would include key terms, roles, and responsibilities. Terms unique to the agile method such as coach, tracker, and metaphor [7] would be mapped to traditional terms such as project manager and architecture.
Key to the presentation is a description of how agile method fits within a traditional project management framework
Changes in Requirements and TestingAgile methods discourage the traditional detailed requirement documents in favor of higher level descriptions of business flows, called "User Stories" or "Use Cases."[v] The idea of producing less than exacting requirement specifications can be a cultural shock to an organization that has lived by rigorous and detailed requirement documents. But Agile philosophy states that since requirements can not be fully known up front, teams should spend time instead developing the requirements as part of the iteration process. Scott Ambler sums up his experience as follows:
"My use cases need to be just good enough. Why does this work? Because in an agile environment you'll ...discover that you don't fully understand what is required, you'll work with your stakeholder to do so, and you'll build something that meets their actual needs. It's software development, not documentation development."