3. Ikenna Consulting ikenna@ikenna.net
Introduction to the Lagos Agile &
Craftsmanship Meetup (LACM)
http://www.meetup.com/lagosac
Mission:
To spread the knowledge of Agile principles and
practices and Software Craftsmanship among
software development teams in Nigeria.
3
4. Ikenna Consulting ikenna@ikenna.net
Introduction to the Lagos Agile &
Craftsmanship Meetup (LACM)
Vision:
Hold talks and conferences in which Agile
practitioners can share there experiences and
knowledge of Agile processes.
4
5. Ikenna Consulting ikenna@ikenna.net
At the end of this talk, you should:
Understand the values of the Agile Manifesto
Understand the principles of the Agile Manifesto
Become familiar with Extreme Programming practices
5
8. Ikenna Consulting ikenna@ikenna.net
The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
agilemanifesto.org
8
9. Ikenna Consulting ikenna@ikenna.net
Not a silver bullet
‘While this was a group of experienced and
recognized software development "gurus," the
word uncovering was selected to assure (or
frighten) the audience that the Alliance members
don't have all the answers and don't subscribe to
the silver-bullet theory.’
- Martin Fowler and Jim Highsmith
9
11. Ikenna Consulting ikenna@ikenna.net
Individuals and interactionsover processes
and tools
Highly skilled team players that
interact well together are the most
important factor of success.
11
12. Ikenna Consulting ikenna@ikenna.net
Individuals and interactionsover processes
and tools
A great process will not save an
unskilled, inexperienced team.
A poor process can hinder a higly skilled
team.
12
13. Ikenna Consulting ikenna@ikenna.net
Individuals and interactionsover processes
and tools
Great programmers are important, but
working and communicating well with
other team members is just as
important.
Average programmers that work well
together will do better than super star
developers that don’t.
13
14. Ikenna Consulting ikenna@ikenna.net
Individuals and interactionsover processes
and tools
Tools: Version Control Systems, Project tracking software, compilers, IDEs,
Database systems etc
Using good tools is important. However bigger,
more powerful tools can add unneeded
complexity.
14
15. Ikenna Consulting ikenna@ikenna.net
Individuals and interactionsover processes
and tools
Can you think of a time when bigger tools or more
elaborate processes made you less productive?
Start simple. Use simple (and free) tools until you
are sure your needs have outgrown them. Use
simpler processes until you need a more
advanced process.
15
16. Ikenna Consulting ikenna@ikenna.net
Working software over comprehensive
documentation
Good human-readable documentation that
describes the system being built, and design
decesions is important.
Because code cannot always communicate the
rationale and intent of a system.
16
18. Ikenna Consulting ikenna@ikenna.net
Working software over comprehensive
documentation
Too much documentation:
´Time consuming to produce
´Time consuming to keep in sync
´Can be misleading when out-of-sync with the
code
18
19. Ikenna Consulting ikenna@ikenna.net
Working software over comprehensive
documentation
“Customers don't care about documents, UML
diagrams or legacy integration. Customers care
about whether or not you're delivering working
software to them every development cycle—
some piece of business functionality that proves to
them that the evolving software application
serves their business needs.”
– Jim Highsmith
19
20. Ikenna Consulting ikenna@ikenna.net
Working software over comprehensive
documentation
How do you maintain a balance?
Document the overall design rationale, very high
level system structures. Keep documentation short.
The best documentation for the code is the code.
Code should communicate its intent clearly. The
team can onboard new team members by pairing
with them.
20
21. Ikenna Consulting ikenna@ikenna.net
Working software over comprehensive
documentation
Writing documentation can be an in-efficient
and difficult means of communication
compared to face-to-face communication.
As a developer, one of my favourite phrases –
“Let me show you”
(the code or a demo of the system)
They say "A picture is worth a thousand words" .
21
22. Ikenna Consulting ikenna@ikenna.net
Customer collaboration over contract
negotiation
It is extremely difficult to deliver a
sizeable software system to fixed
requirements/scope, on a fixed
schedule at a fixed price.
Why is this ?
22
23. Ikenna Consulting ikenna@ikenna.net
Customer collaboration over contract
negotiation
Rather than fixed statement of work,
customer should work closely with
team and provide frequent feedback.
Requirements will change.
23
24. Ikenna Consulting ikenna@ikenna.net
Responding to change over
following a plan
Buisness environment can change during the
course of the software project.
Customers may change their requirements
during the course of the software project.
Humans are fundamentally bad at estimating
how long a software development effort will
take.
24
25. Ikenna Consulting ikenna@ikenna.net
Responding to change over
following a plan
Therefore, it is difficult to plan out a
long software project in detail!
Instead have
´ detailed short iteration/sprint (1 – 2 week) plans
´ Rough monthly plans (2 – 3 months)
´ Very rough long term plans ( 1 year +)
25
26. Ikenna Consulting ikenna@ikenna.net
Responding to change over
following a plan
Since we should have a very good
idea of the immediate tasks we
should work on in the 1 or 2 weeks, it
makes sense to invest detailed
planning effort there
26
28. Ikenna Consulting ikenna@ikenna.net
Principles of the Agile Manifesto
1. Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers work together
daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
7. Working software is the primary measure of
progress.
8. Agile processes promote sustainable
development. The sponsors, developers and
users should be able to maintain a constant
pace indefinitely.
9. Continuous attention to technical excellence
and good design enhances agility.
10. Simplicity—the art of maximizing the amount of
work not done—is essential.
11. The best architectures, requirements and
designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts its behavior accordingly.
28
29. Ikenna Consulting ikenna@ikenna.net
Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
´ Deliver a very basic system within the first few weeks. Steadily add
functionality to it every week or two.
´ The business may chose to put it in production, or review it and feedback
on changes to be made.
´ Leads to better quality due to rapid iteration
´ Gains customer confidence
‘Customers care about whether or not you're delivering working software to
them every development cycle—some piece of business functionality that
proves to them that the evolving software application serves their business
needs.’
– Jim Highsmith
29
30. Ikenna Consulting ikenna@ikenna.net
Welcome changing requirements, even late
in development. Agile processes harness
change for the customer's competitive
advantage.
´ Have the attitude of embracing change. We are agile.
´ Change to requirements is good – we are learning based on feedback.
´ The architecture of the software should be flexible to adapt to change.
30
31. Ikenna Consulting ikenna@ikenna.net
Welcome changing requirements, even late
in development. Agile processes harness
change for the customer's competitive
advantage.
“Options Thinking”
“One of the hot debates in software development concerns the tradeoff between predictive processes and adaptive
processes.The prevailing paradigm has been a predictive process:Software development should be specified in detail
prior to implementation, because if you don’t get the requirements nailed down and the design right, it will surely cost a lot
to make changes later. This paradigm may work in a highly predictable world.
However, if there is uncertainty about what customers really need, whether their situation will change, or where technology
is moving, then an adaptive approach is a better. Options limit downside risk by limiting the cost and time allocated to
resolving uncertainty. They maximize upside rewardby delaying decisions until more knowledge is available.Economists
and manufacturing managers alike understand that the adaptive paradigm of delaying decisions until uncertainty is
reduced usually produces better results than a predictive approach.”
- Lean Software Development: An Agile Toolkit. Mary Poppendieck; Tom Poppendieck. Addison-Wesley Professional, 2003
31
32. Ikenna Consulting ikenna@ikenna.net
Deliver working software frequently, from a
couple of weeks to a couple of months,
with a preference to the shorter timescale.
Focus on delivering working software, not
documentation
Deliver it early and often
32
33. Ikenna Consulting ikenna@ikenna.net
Deliver working software frequently, from a
couple of weeks to a couple of months,
with a preference to the shorter timescale.
“Use Tracer Bullets to find the target. ‘Ready, Fire,
Aim’.”
- Andrew Hunt and David Thomas,
The Pragmatic Programmer
How do you hit a target in the dark?
Calculate and aim precisely or just fire tracers?
https://www.youtube.com/watch?v=PkK1ayxBMCo
https://www.youtube.com/watch?v=PzlvF--6bPI
33
34. Ikenna Consulting ikenna@ikenna.net
Deliver working software frequently, from a
couple of weeks to a couple of months,
with a preference to the shorter timescale.
On a real life project:
´ Requirements can be vague
´ New algorithms
´ New techniques
´ New tools
´ New languages
´ New libraries
´ New team
´ Business environment may change
´ Customer may change
Like trying to hit a target in the
dark:
Uncertainty
34
35. Ikenna Consulting ikenna@ikenna.net
Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference
to the shorter timescale.
Calculate & Aim
´ Specify the system requirements
to the finest detail
´ Design the architecture to the
finest detail.
´ Pin down every unknown
´ Lockdown the enviroment
´ Estimate to the finest precesion
´ Get the customer to sign it all off
´ Then fire! (Implement)
Fire a Tracer
´ Develop something that
implements a small part of the
requirement quickly and deploy it.
´ Not a disposable prototype! Real
end-to-end production code, but
keep it small. (Walking skeleton -
http://alistair.cockburn.us/Walking
+skeleton )
35
36. Ikenna Consulting ikenna@ikenna.net
Deliver working software frequently, from a
couple of weeks to a couple of months,
with a preference to the shorter timescale.
´ Advantages of a Tracer
´ Users see early, visible progresss. Set the users expectations, that this is a very
early version of the system. You get early feedback on how close to the target
you are.
´ Developers have an end-to-end integration backbone / platform to develop
code around. Consistency of architecture
´ You can demonstrate visible real progress.
´ You may discover things about your deployment, system architecture, third party
tools and frameworks that you did not know.
36
37. Ikenna Consulting ikenna@ikenna.net
Business people and developers work
together daily throughout the project.
Agility requires significant and frequent daily
interaction between customers, developers,
analysts, and testers.
On site-customer: an on-site customer, or product
manager, is responsible for choosing and
prioritizing features. In my experience, the product
manager can be the busiest role in the team,
especially as the team scales.
37
38. Ikenna Consulting ikenna@ikenna.net
Business people and developers work
together daily throughout the project.
Executive sponsors may be different from real
end-users.
You can appoint the executive sponsor (or
someone she chooses) as product manager, and
a user with deep knowledge of the use case as a
domain experts.
38
39. Ikenna Consulting ikenna@ikenna.net
Build projects around motivated individuals.
Give them the environment and support
they need, and trust them to get the job
done.
People first.
Get the very best people you can.
Then do your best to give them all they need to
succeed.
39
40. Ikenna Consulting ikenna@ikenna.net
Build projects around motivated individuals.
Give them the environment and support
they need, and trust them to get the job
done.
´If the process hampers the team, change the
process
´If the office enviroment hampers the team, change
the office
´If the tools hamper the team, change the tools
40
41. Ikenna Consulting ikenna@ikenna.net
Build projects around motivated individuals.
Give them the environment and support
they need, and trust them to get the job
done.
“Decisions must be made by people who know
the most about the situation. Managers must trust
their staff to make the decisions about the things
they're paid to know about.”
– Martin Fowler and Jim Highsmith ,
http://www.drdobbs.com/open-source/the-agile-manifesto/184414755
41
42. Ikenna Consulting ikenna@ikenna.net
The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
Face to face converstation is the primary
mode of communication
42
43. Ikenna Consulting ikenna@ikenna.net
The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
Email, instant messaging, wiki’s/confluence,
Jira/project tracking tools, phone calls, Powerpoint,
Word documents, Slack, Trello etc are all great
when used well.
But regular face to face is the most powerful form.
Co-location of teams very important.
43
44. Ikenna Consulting ikenna@ikenna.net
The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
“Tacit knowledge cannot be transferred by getting it out of
people's heads and onto paper… Tacit knowledge can be
transferred by moving the people who have the knowledge
around. The reason is that tacit knowledge is not only the facts
but the relationships among the facts—that is, how people
might combine certain facts to deal with a specific situation."
- Nancy Dixon
- Nancy M. Dixon. 2000. ”Common Knowledge: How Companies Thrive by Sharing
what They Know”. Harvard Business School Press,, Boston, MA, USA.
44
45. Ikenna Consulting ikenna@ikenna.net
Working software is the primary measure of
progress.
´Schedule frequent demos, (every week, or 2
weeks), preferably deployed on an environment
as near to production as reasonable, to show
product managers, users and team members
what work has been done.
´How much of the project is complete? The
percentage that is deployed, tested and
working.
45
46. Ikenna Consulting ikenna@ikenna.net
Agile processes promote sustainable
development. The sponsors, developers and
users should be able to maintain a constant
pace indefinitely.
´ Sustainable pace, indefinitely. Work at a constant rate.
´ Avoid burnouts
46
47. Ikenna Consulting ikenna@ikenna.net
Agile processes promote sustainable
development. The sponsors, developers and
users should be able to maintain a constant
pace indefinitely.
“Overtime is like sprinting: It makes some sense for the
last hundred yards of the marathon for those with any
energy left, but if you start sprinting in the first mile, you’re
just wasting time.”
– Tom De Marco,
“Peopleware: Productive Projects and Teams”, Third Edition
Addison-Wesley Professional, 2013
47
48. Ikenna Consulting ikenna@ikenna.net
Agile processes promote sustainable
development. The sponsors, developers and
users should be able to maintain a constant
pace indefinitely.
“Most organizations don’t even keep statistics on turnover. Virtually none can
tell you what replacement of an experienced worker costs. And whenever
productivity is considered, it is done as though turnover were nonexistent or
cost-free. The Eagle project at Data General was a case in point. The project
was a Spanish Theory triumph: Workaholic project members put in endless
unpaid overtime hours to push productivity to unheard of levels. At the end of
the project, virtually the entire development staff quit. What was the cost of
that? No one even figured it into the equation.”
– Tom De Marco,
“Peopleware: Productive Projects and Teams”, Third Edition
Addison-Wesley Professional, 2013
48
49. Ikenna Consulting ikenna@ikenna.net
Continuous attention to technical
excellence and good design enhances
agility.
´ High quality clean code
´ Good design, software architecture
´ Automated tests
´ Refactoring
´ However, rememebr – ‘Perfect is the enemy of the good’. Even if it isn’t
perfect, good enough is fine. Make quality a requirements issue – involve
users in the trade-off between quality and effort by releasing early to them
to get their feedback.
“Great sotware today is often preferable to perfect software tomorrow” –
Andy Hunt, Dave Thomas - The Pragmatic Programmer
49
50. Ikenna Consulting ikenna@ikenna.net
Continuous attention to technical
excellence and good design enhances
agility.
´ No broken windows
´ “One broken window, left unrepaired for any substantial length of time, instils in
the inhabitants of the building a sense of abandonment – a sense that the
powers that be don’t care about the building. So another window gets broken.
People start littering. Graffiti appears. Serious structural damage beings. In a
relatively short space of time, the building becomes damaged beyond the
owner’s desire to fix it, and the sense of abandonment becomes reality”
- Andrew Hunt and Dave Thomas ‘The Pragmatic Programmer”
50
51. Ikenna Consulting ikenna@ikenna.net
Simplicity—the art of maximizing the
amount of work not done—is essential.
´ Prefer simple solutions were possible. Simple solutions are usually easier to
change than complex ones.
´ Minimalisim.
´ Don’t try and anticipate all of tomorrow’s problems and defend against
them today
´ The software should be easy to change tomorrow anyway
51
52. Ikenna Consulting ikenna@ikenna.net
Simplicity—the art of maximizing the
amount of work not done—is essential.
´ Kent Beck explains Simplicity
´ Appropriate for the intended audience – No matter how brilliant it is, if the
people who should work with it don’t understand it, it isn’t simple for them.
´ Communicative – Every idea that needs to be communicated is present.
´ Factored – Duplication of logic or structure is avoided
´ Minimal – Should have the fewest elements possible (to test, document and
communicate).
52
54. Ikenna Consulting ikenna@ikenna.net
The best architectures, requirements and
designs emerge from self-organizing team
Managers should assign responsibilities assigned at team
level. Team determines how to carry out the responsibility.
54
55. Ikenna Consulting ikenna@ikenna.net
The best architectures, requirements and
designs emerge from self-organizing team
Collective ownership – all team members own all
aspects of the project and can contribute to any
aspect.
55
56. Ikenna Consulting ikenna@ikenna.net
At regular intervals, the team reflects on
how to become more effective, then tunes
and adjusts its behavior accordingly.
Retrospectives & continous
improvement
56
60. Ikenna Consulting ikenna@ikenna.net
Feature Driven Development (FDD)
´ Model driven, short iteration process
´ Start with overall model shape
´ 2 week “design by feature, build by feature iterations”
´ Domain object modelling
´ Design Inspection
´ Feature teams
´ Regular builds
60
61. Ikenna Consulting ikenna@ikenna.net
Lean and Kanban Software
Development
´ Lean
´ Mary and Tom Poppendieck
´ Based on Lean principles and practices from Toyota
´ Value stream
´ Eliminate waste
´ Decide as late as possible (Least responsible moment). Options thinking.
´ Delivering as fast as possible
´ Kanban
´ Continual delivery – enhanced flow (pull)
´ Workflow visualization
´ Limiting work-in-progress (WIP)
61
64. Ikenna Consulting ikenna@ikenna.net
Dynamic Systems Development Method
´ MoSCoW prioritisation - (Must have, Should have, Could
have, and Wouldn’t get but like)
´ Timeboxing – fixed budget & delivery date (scope varied
by MoSCoW)
´ Prototyping
´ Testing during the iteration
´ Stakeholder requirement worksop
´ Modelling
64
65. Ikenna Consulting ikenna@ikenna.net
References + Further Reading
´ “Agile Software Development: Principles, Patterns &
Practices”
– Robert C. Martin
Pearson, 2002
´ “The Art of Agile Software Development”
- James Shore
O’Reilly Media, 2007
´ “The Pragmatic Programmer”
– Andrew Hunt and David Thomas
Addison Wesley, 1999
65