This document discusses key principles of agile development including reduction, focus, and visibility. It emphasizes reducing scope, team sizes, dependencies to increase release frequency and quality. Focus is needed on continuous delivery of valuable software and welcoming changing requirements. Visibility of the backlog, progress, risks and dependencies facilitates collaboration. Challenges include balancing value and risk, gaining consensus on priorities, and keeping visibility tools updated. Estimation, architecture, and addressing non-functional requirements like quality are also important rather than focusing only on delivering features.

1. Distilling Agile
Omar Bashir
https://www.linkedin.com/in/obprofile/
@OmarBashir_40
obashir@yahoo.com

3. We too often get dogmatic about the ceremonies
and artifacts and forget about the fundmentals.
Mike Cottmeyer

4. Agile Manifesto
● Individuals and interactions over processes and
tools
● Working software over comprehensive
documentation
● Customer collaboration over contract negotiation
● Responding to change over following a plan

5. Agile Manifesto Principles
● Early and continuous delivery of valueable software.
● Welcome changing requirements.
● Deliver working software as frequently as possible.
● Daily collaboration between business and tech.
● Focus on people and enablement.
● Face to face communication within teams.
● Maintain a constant pace indefinitely.
● Maximise the art of work not done.
● Self organising teams leading to emergent systems.
● Retune, readjust and realign regularly.

6. Agile Manifesto Principles
● Early and continuous delivery of valueable software.
● Welcome changing requirements.
● Deliver working software as frequently as possible.
● Daily collaboration between business and tech.
● Focus on people and enablement.
● Face to face communication within teams.
● Maintain a constant pace indefinitely.
● Maximise the art of work not done.
● Self organising teams leading to emergent designs.
● Retune, readjust and realign regularly.

7. Distilled Principles
● Reduction
– Reduce scope, sprint lengths, team sizes,
dependences etc. to increase release frequency,
reduce risks and enhance product quality.
● Focus
– Continuously deliver demonstrable value.
● Visibility
– Make backlog, progress, risk, dependencies etc.
visible to facilitate collaboration and communication.

8. Agile Frameworks
● Scrum
– Empirical process control
– Self organisation
– Collaboration
– Value based prioritisation
– Time boxing
– Iterative development
● Kanban
– Principles
● Start with what you do now
● Incremental and evolutionary
change
● Respect current process
● Leadership at all levels
– Properties
● Visualise workflow
● Limit WIP
● Manage flow
● Make process policies explicit
● Improve collaboratively

9. In fact, in an agile project, technical excellence is
measured by both capacity to deliver customer
value today and create an adaptable product for
tomorrow.
Jim Highsmith

11. Reduction - The Obvious
● Iteration/Sprint size
– Frequent releases.
– Frequent feedback.
– Reduced risk of divergence from customer needs.
● Team size
– Better bonding.
– Efficient communication.
– Effective management.
● Features
– Reduced optional complexity.

12. Reduction - The Obvious
● Story size
– Improved estimation.
● Less uncertainty due to reduced scope.
– Reduced accidental complexity.
● Less ambiguity leading to focused implementations.
– Improved testing.
● Smaller and focused tests.
– Higher throughput.
● Focused features leading to less waste.

13. Reduction – The Ignored
● Code
– Dead and commented out code causes confusion.
– Succinct codebase has less accidental complexity.
● Merge request size
– Meaningful and thorough code reviews.
– Reduced risk of merge conflicts.
– Improved code quality.

14. Reduction – The Ignored
● Technical dependencies
– Reduced binary footprint.
– Increased code longevity.
– Improved testability.
● Inter-team and intra-team dependencies
– Reduced handovers improving flow.
– Developers gain domain knowledge.
– Improved organisation.

15. Reduction – Challenges
● Story sizes.
– Splitting stories to reduce scope.
● Vertical splitting.
● Horizontal splitting.
● Iteration/Sprint sizes.
– Planning overhead.
– DevOps toolset maturity.
– Features bigger than sprints.
● Grouping sprints into feature packages.
Independent
Negotiable
Valuable
Estimable
Small
Testable

16. Reduction – Challenges
● Code size.
– Brevity but not obfuscation.
– Preserve SOLIDity using design patterns.
● Team sizes and organisation.
– Conway’s Law.
● Architecture to drive organisation of teams.
● Using functional and non-functional requirements to choose
architectural styles.
– Cross functional teams,
● Feature aligned vs subsystem aligned.

18. Focus – The Obvious
● Business features
– Prioritising product backlog.
– Grouping and prioritising stories in dependency order.
● Building a flow
– Governing self-organisation.
● Cross functional teams executing stories with least possible
handovers.
● Reducing inter-team dependencies.
– Subsystem aligned teams: Static organisation.
– Feature aligned teams: Reorganisation possible every sprint.
– Sprints grouped into feature packages.

19. Focus – The Ignored
● Non-Functional Requirements (NFRs)
– Ignoring them can have consequences, e.g.,
● Security: Reputational, data and business continuity risks.
● Performance: Reputational and revenue risks.
● Usability: Adoption and loyalty risks.
– Relegating NFRs builds technical debt.
– Pair with functional requirements in relevant stories.
● Test suites should contain both functional and non-functional
tests.
– Educate developers on,
● Relevant performance metrics.
● Measurement and profiling tools.

20. Focus – The Ignored
● Technical risks
– Technical debt
● Always paid back in hard ca$h.
● Technical investment,
– Just enough design vs. over-engineering vs. no design.
– Domain Driven Design.
– Commoditised design: Design patterns and architectural styles.
– Defects
● Determination
– Is this really a bug?
● Severity
– Blocker vs. Critical vs. Major.
● Early detection and resolution
– Effective testing strategy.

21. Focus – Challenges
● Balancing value and risk
– Avoiding the long and painful tail/tale of delivery.
● Consensus
– A clear understanding of priorities across stakeholders.
● Monitoring
– Ensuring teams are committed to the plan.

23. Visibility – The Obvious
● Product roadmap and backlog
– Shared visibility of product evolution plan.
● Sprint backlog
– Detailed task level plan for an iteration.
– Also includes defects/bugs prioritised for fixing.
● Sprint/Kanban boards
– Detailed view of iteration execution (Who is doing what
now).
● Burndown/Burnup charts
– Tasks (effort) remaining/tasks (effort) completed.

24. Visibility – Burndown

25. Visibility – Backlog

26. Visibility – The Ignored
● Capacity management
– Team availability vs. iteration backlog.
● Defect trends
– Indicator of focus on quality.
● RAID log
– Prioritised list of Risks, Assumptions, Issues and
Dependencies facing the project.
– Includes owners, current status, links to backlog and ETA.
● Dependency matrix
– How teams depend on each other for iteration execution.

27. Visibility – Defect Trends

28. Visibility – Dependency Matrix

29. Visibility – Challenges
● Tooling
– Keeping it simple.
– Derived from a single source of truth.
● Shared
– Available to all team members for viewing at least.
● Keeping it current.
– These are living organs of a project, if they are not
current, the project is dead.
● Encouragement
– Motivating team members to move off emails and chats to
enquire and share status.

30. Final Word
● No estimation is not an option.
– Estimation may not be accurate but can be realistic.
– Task breakdown affects estimation accuracy/realism.
● No design is not an option.
– Architecture and design affects EVERYTHING.
– Avoiding big up front design does not mean no design.
● Architecture and design are increasingly commoditised.
● Teams should use design patterns and architectural styles.
● Value alone is not an option.
– Technical debt has physical costs.
– Relegating NFRs adds tech debt and risks delivery.

31. There are no such things as best practices in product
development. There are only practices that are
adequate within a certain context.
Practices are situational; blithely claiming they are
“best” disconnects them from motivation and context.
They become rituals. And pushing so-called best
practices kills a culture of learning, questioning,
engagement, and continuous improvement.
Why would people challenge best?
Craig Larman, Bas Vodde