7. Or... what the customer wanted
Photo by Adam Jang on Unsplash
8. Lessons learned: what did we miss?
● Measurability
○ The camel is faster than a person walking - what was the baseline?
● Industry context / assumptions
● Deciding on the architecture too soon
● Stakeholders not involved in enough decisions and meetings
10. An agile story
Small team: project manager, two developers, QA, design
Customer
● Agile
● Regularly joined daily scrum calls
● Attended sprint ceremonies in person
● Heavy emphasis on cost-benefit analysis
We changed direction frequently
Customer and us happy with the product and the result
11. A pseudo-agile story
The same small team
Customer
● Agile
● Mostly joined daily scrum calls
● Rarely attended sprint ceremonies
● Heavy emphasis on function
We changed direction frequently
After 8 months, we thought the product was finished
12. The customer disagreed
We believed it was a time and materials contract (they usually were)
We believed the requirements were agile: agreed in sprint planning meetings
When we declared complete, the customer pointed out
● Contract was fixed price
● Original requirements described in the contract had not been met
The contract had been set up by the business development (sales) team
● Optimistic
● Ambitious
13. Lessons learned - customer requirements
Do not agree to fixed price contracts - if possible
Do not write features or low level requirements into the contract - if possible
If you inherit a contract
● Read it
If you have fixed requirements
● Say “no” a lot
● Have a requirements change process
14. Lessons learned - requirement changes
Changes, discussions, and agreements made in meetings or on calls may be
forgotten
● Write down decisions
● Circulate the decisions (or minutes) for approval
● When you update a requirement (or other) document, make sure the version
history is visible and auditable
● Make sure the customer representative has the authority to approve and sign
off requirement changes
16. What can go wrong
If the requirements are unclear, or the contract is unusual, or the stakeholder(s)
are not engaged, typically:
● The team work together happily but build the wrong thing OR
● The team spend a lot of time arguing about interpretation of requirements
● Impact on team’s morale
Your awareness of what might go wrong can help you explain to a stakeholder
why they need to engage
17. How can you predict problems early?
Early symptoms that a project might not go well
● Sprint ceremonies are missing key people
○ Stakeholders
○ Developers
○ Designers
○ You do not know what you do not know
● Sprint ceremonies or scrums do not produce value
○ Team members do not contribute
○ Or the team talk a lot, but revisit old debates and do not come to conclusions
○ The team are scared to raise important issues and problems
18. How can you predict problems early?
More early symptoms that a project might not go well
● Requirement sizings are large
○ If a story has a large story point or time sizing, this is a symptom that it is not well understood
● Code reviews / signoff are slow
○ Symptom of team lead overload
○ Symptom of lack of respect between team members
● Solution architecture is fixed too early and by one person
○ The solution needs to fit the requirements
○ If solution architected before requirements understood, future requirements will be bent to fit
20. About us
We built fflow to improve resource planning and operational efficiency for projects
and teams
● visualise availability and assign projects in a combined scheduler
● manage HR absences
● track (billable) time
● reporting by time and by task
Find out more at https://fflow.io/