Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Scrum/Agile Projects introduce several challenges/forces that are easier to deal with when leveraging agile engineering practicesEngineering practices are key to getting high ROI on Agile adoption, and to continued improvement of the product development organization. Scrum is an agile Project management frameworkIn Scrum, Engineering practices are up to the team to defineSince Scrum is a light-weight framework, it is easy to plug agile engineering practices into it.

Compressed Cycle compared to waterfallSymptom:everything slows down (“we don’t have time to develop anything, we test 50% of the time”)Done is not really Done. PSP==Potentially S#!*ty ProductNeed to minimize cost of stuff repeated per iteration – enable effective small batches

Symptoms:Our features/user stories are too big to fit into one iteration – we need LONGER iterations..We need a long time to nail down the design for this. Our PSP for this iteration is a high-level design…Solution?Effective User Story Analysis to create Minimum Marketable Features (MMF)DesignEither do all design up frontOr have a growing evolutionary designEveryone works on highest priority – EVEN if outside comfort zoneNeed to improve collective code ownershipDevelopers need to feel safe to work everywhere in the team’s codebase

Symptoms:Our features/user stories are too big to fit into one iteration – we need LONGER iterations..We need a long time to nail down the design for this. Our PSP for this iteration is a high-level design…Solution?Effective User Story Analysis to create Minimum Marketable Features (MMF)DesignEither do all design up frontOr have a growing evolutionary designEveryone works on highest priority – EVEN if outside comfort zoneNeed to improve collective code ownershipDevelopers need to feel safe to work everywhere in the team’s codebase

Symptoms:Our features/user stories are too big to fit into one iteration – we need LONGER iterations..We need a long time to nail down the design for this. Our PSP for this iteration is a high-level design…Solution?Effective User Story Analysis to create Minimum Marketable Features (MMF)DesignEither do all design up frontOr have a growing evolutionary designEveryone works on highest priority – EVEN if outside comfort zoneNeed to improve collective code ownershipDevelopers need to feel safe to work everywhere in the team’s codebase

13.
Next Steps
Learn more about the engineering practices. Ask your teams questions
that will engage them in this learning as well.
Evaluate how YOUR engineering practices/level are affecting your agile
environment
Pay attention to Technical Debt, Batch cost, knowledge silos as part of
your Inspect and Adapt cycle –
Leverage your Scrum retrospectives
Encourage teams to establish an engineering level backlog and assign
capacity to work on it.
Setup the right measures, communicate the right message.
Consider carefully whether to pick and choose practices or
adopt a methodology like Extreme Programming

19.
Test-Driven Development/Design
TDD is a method of designing software, not
merely an approach to testing.
Over a period of time, as a side effect, TDD
will lead to suite of automated unit tests.

20.
Refactoring
 Refactoring increases
flexibility and the
product lifetime by
allowing and
encouraging
developers to change
the design of the
system as needed.
 Quality to market and
costs are reduced
because continuous
Refactoring keeps the
design from degrading
over time and thus
making it harder to
modify the product
correctly”

24.
Simple Design
Start Simple
Evolve JUST IN TIME
YAGNI –
You Ain’t Going to Need it

25.
Agile Modeling
 Just enough Modeling/Documentation
 Use the relevant model/artifact for the situation
 Only keep models you REALLY need to maintain.
Its ok to model and throw away later

26.
Coding Standards
 Code must be formatted
to agreed coding
standards.
 Coding standards keep
the code consistent
and easy for the entire
team to read and
refactor.

27.
Collective Ownership
Collective Code Ownership
encourages everyone to
contribute new ideas to all
segments of the project.
Any developer can change
any line of code to add
functionality, fix bugs, or
refactor. No one person
becomes a bottle neck for
changes.

28.
Pair Programming
Two team
members
working on the
same code base
and working
side-by-side
(Also applicable
to tests/etc. – not
just code)

33.
Pair Programming
 Very effective, if a good cultural fit for the team.
 Hard to adopt, mainly due to personal space and lack of
privacy issues, as well as individuality.
 Try and Buy - on writing User Stories, debugging of
difficult defects/code areas, for Code reviews of critical
production code, etc.

34.
Iterate / Inspect & Adapt
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
Deliver working software frequently, from a
couple of weeks to a couple of
months, with a preference to the shorter
timescale.
BUT - iterating is HARD and expensive?