View
4.151
Download
0
Category
Preview:
DESCRIPTION
An introductory presentation by Naresh Jain on the essence of Being Agile vs. Following Agile and why being Agile is important? Naresh also shows an evolution of Agile methods over the last 11 years and the future of Agile. Also take a sneak preview into what challenges an organizations may face when trying to be agile?
Citation preview
Agile WTF!
Naresh Jainnaresh@agilefaqs.com
twitter: @nashjain
http://nareshjain.com
1Friday 15 June 2012
Agile WTF!
Agile Way to Fail!
Naresh Jainnaresh@agilefaqs.com
twitter: @nashjain
http://nareshjain.com
1Friday 15 June 2012
Being ‘agile’OVER
Following ‘Agile’
Naresh Jainnaresh@agilefaqs.com
twitter: @nashjain
http://nareshjain.com
2Friday 15 June 2012
3Friday 15 June 2012
4Friday 15 June 2012
Why is there only ONE Toyota or Apple today?
5Friday 15 June 2012
Processes are like haircutsCopying someone else’s rarely works
6Friday 15 June 2012
Retrospec)ve Coherence
7Friday 15 June 2012
Retrospec)ve Coherence
Hindsight does not lead to foresight!
7Friday 15 June 2012
Albert Einstein8Friday 15 June 2012
Albert Einstein
A perfection of means, and confusion of aims, seems to be
our main problem.
8Friday 15 June 2012
\ 9
Process is a placebo
9Friday 15 June 2012
\
Jared spool’s tricks to Dogma con7nuum arranges terminology from improvisa7on to atrophy
9
Process is a placebo
9Friday 15 June 2012
Process is built on values and principles and tailored to fit its
context
Src: Jeff Patton10Friday 15 June 2012
Src: Jeff Patton11Friday 15 June 2012
ME
12Friday 15 June 2012
13Friday 15 June 2012
Mumbai
14Friday 15 June 2012
Tech Talks!
15Friday 15 June 2012
FitNesse ProTest
PatangLa"u
FitDecoratorDBFit
QWick
ProFIT
Panopticode
16Friday 15 June 2012
17Friday 15 June 2012
18Friday 15 June 2012
19Friday 15 June 2012
20Friday 15 June 2012
21Friday 15 June 2012
22Friday 15 June 2012
Taking ownership of a simple process
Adapted from Jeff Patton
23Friday 15 June 2012
The Ball Point Game
24Friday 15 June 2012
The Ball Point Game
Your goal:
As a team predictably "process" the most number of balls in a round by passing a ball to each member
You have 3 rounds to get the best score you can
24Friday 15 June 2012
The Ball Point Game
Your goal:
As a team predictably "process" the most number of balls in a round by passing a ball to each member
You have 3 rounds to get the best score you can
Simple structure:
Predict the number of balls you can process
Pass balls for 2 minutes (no more, no less)
Take 2 minute to discuss and improve your strategy
24Friday 15 June 2012
The Ball Point Game
Your goal:
As a team predictably "process" the most number of balls in a round by passing a ball to each member
You have 3 rounds to get the best score you can
Simple structure:
Predict the number of balls you can process
Pass balls for 2 minutes (no more, no less)
Take 2 minute to discuss and improve your strategy
Simple rules:
Everyone must touch the ball for it to be “done”
The ball must have “air )me” -‐ it must be tossed or dropped between team members
24Friday 15 June 2012
Core Agile concepts learned?
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Process improvement comes from change
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Process improvement comes from change
Skill improvement come from prac7ce
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Process improvement comes from change
Skill improvement come from prac7ce
Certain kind of es=mates improves with frequent measurement
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Process improvement comes from change
Skill improvement come from prac7ce
Certain kind of es=mates improves with frequent measurement
Velocity is agile’s language for measuring throughput
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Process improvement comes from change
Skill improvement come from prac7ce
Certain kind of es=mates improves with frequent measurement
Velocity is agile’s language for measuring throughput
Visibility of work helps us make improvement decisions
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Process improvement comes from change
Skill improvement come from prac7ce
Certain kind of es=mates improves with frequent measurement
Velocity is agile’s language for measuring throughput
Visibility of work helps us make improvement decisions
Reflec7on: observing, measuring & changing is the means for process improvement
Adapted from Jeff Patton25Friday 15 June 2012
Core Agile concepts learned?
Ideal processes use a simple framework -‐ like a game
Changing your strategies & tac7cs, not the framework, allow you to improve
Process improvement comes from change
Skill improvement come from prac7ce
Certain kind of es=mates improves with frequent measurement
Velocity is agile’s language for measuring throughput
Visibility of work helps us make improvement decisions
Reflec7on: observing, measuring & changing is the means for process improvement
Team work is an individual skill
Adapted from Jeff Patton25Friday 15 June 2012
“Simple, clear purpose and principles give rise to complex
and intelligent behavior.
Complex rules and regulations give rise to simple
and stupid behavior.”
Dee Hock26Friday 15 June 2012
Your SoNware Development Game?
What would be:
Your goal
Simple structure
Simple rules
27Friday 15 June 2012
The Agile Game
Adapted from Jeff Patton28Friday 15 June 2012
The Agile Game
Your goal: As a team, predictably deliver max value to users & stakeholders
Adapted from Jeff Patton28Friday 15 June 2012
The Agile Game
Your goal: As a team, predictably deliver max value to users & stakeholders
Simple structure: As a team, set a goal & plan to accomplish the work
Deliver working solu=on by the end of a fixed cycle
Reflect & improve your Product, Plan, People and Process
Adapted from Jeff Patton28Friday 15 June 2012
The Agile Game
Your goal: As a team, predictably deliver max value to users & stakeholders
Simple structure: As a team, set a goal & plan to accomplish the work
Deliver working solu=on by the end of a fixed cycle
Reflect & improve your Product, Plan, People and Process
Simple rules:Whole team works together & takes responsibility for the outcome
Progress and quality must be kept visible
Finished work (working solu=on) is the only measure of progress
Adapted from Jeff Patton28Friday 15 June 2012
Why Agile?
29Friday 15 June 2012
Traditional cost profile
Lower cost of change curve
30Friday 15 June 2012
Agile system cost profile
Traditional cost profile
Lower cost of change curve
30Friday 15 June 2012
“I’m glad we’re all agreed then.”
Clear communica)on is the founda)on
31Friday 15 June 2012
“Ah...”
Get mental models out on the table
32Friday 15 June 2012
“Ah!”
Convergence through itera)on
33Friday 15 June 2012
“I’m glad we’re all agreed then.”
A genuinely shared understanding
34Friday 15 June 2012
Tradi7onal so>ware development fixes scope then es7mates to figure out 7me and cost
Traditional software
development
Src: Jeff Patton35Friday 15 June 2012
Tradi7onal so>ware development fixes scope then es7mates to figure out 7me and cost
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton35Friday 15 June 2012
Tradi7onal so>ware development fixes scope then es7mates to figure out 7me and cost
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton35Friday 15 June 2012
Tradi7onal so>ware development fixes scope then es7mates to figure out 7me and cost
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton35Friday 15 June 2012
Agile development fixes 7me and cost, then leverages itera7on and incremen7ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton36Friday 15 June 2012
Agile development fixes 7me and cost, then leverages itera7on and incremen7ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Src: Jeff Patton36Friday 15 June 2012
Agile development fixes 7me and cost, then leverages itera7on and incremen7ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Agile software development
Src: Jeff Patton36Friday 15 June 2012
Agile development fixes 7me and cost, then leverages itera7on and incremen7ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
TimeCost
(resources)
Agile software development
Src: Jeff Patton36Friday 15 June 2012
Agile development fixes 7me and cost, then leverages itera7on and incremen7ng to maximize scope
Traditional software
development
Scope
Time Cost(resources)
Scope
TimeCost
(resources)
Agile software development
Src: Jeff Patton36Friday 15 June 2012
Leverage a shared understanding of desired product goals to minimize scope while maximizing value
Traditional software
development
Scope
Time Cost(resources)
Scope
TimeCost
(resources)
Agile software development
Src: Jeff Patton37Friday 15 June 2012
Leverage a shared understanding of desired product goals to minimize scope while maximizing value
Traditional software
development
Scope
Time Cost(resources)
Scope
TimeCost
(resources)
Agile software development
Target business goals & outcomesSrc: Jeff Patton
37Friday 15 June 2012
Building Quality into the Process
Toyoda Loom
38Friday 15 June 2012
Source: Beyond Agile Software Development Becoming Lean, Mary Poppendieck, Poppendieck.llc
Utilization (%)
Focus on Throughput
39Friday 15 June 2012
Tradi)onal Process
40Friday 15 June 2012
Tradi)onal Process
40Friday 15 June 2012
Applying Lean Principles to SoNware Development
41Friday 15 June 2012
End-to-End small slices of work
Applying Lean Principles to SoNware Development
41Friday 15 June 2012
End-to-End small slices of work 20 % done = 100 % usable
Applying Lean Principles to SoNware Development
41Friday 15 June 2012
Fix / Integrate $
Test
Code
DesignSpecifications
Use Cases / Functional Specs
Requirements Gathering
Project Plan/Estimation
$
Inception
$
$
$
Lean Principles applied to SoNware Development
42Friday 15 June 2012
Itera)ve
Adapted from Jeff Patton
43Friday 15 June 2012
Itera)ve
Adapted from Jeff Patton
43Friday 15 June 2012
Itera)ve
Adapted from Jeff Patton
43Friday 15 June 2012
Itera)ve
Adapted from Jeff Patton
43Friday 15 June 2012
Incremental
Adapted from Jeff Patton
44Friday 15 June 2012
Incremental
Adapted from Jeff Patton
44Friday 15 June 2012
Incremental
Adapted from Jeff Patton
44Friday 15 June 2012
Incremental
Adapted from Jeff Patton
44Friday 15 June 2012
Itera)ve AND Incremental
Adapted from Jeff Patton
45Friday 15 June 2012
Itera)ve AND Incremental
• Mix the strategies:–Iterate to find and improve solu6ons
–Increment to add func6onality
Adapted from Jeff Patton
45Friday 15 June 2012
Itera)ve AND Incremental
• Mix the strategies:–Iterate to find and improve solu6ons
–Increment to add func6onality
Adapted from Jeff Patton
45Friday 15 June 2012
Itera)ve AND Incremental
• Mix the strategies:–Iterate to find and improve solu6ons
–Increment to add func6onality
Adapted from Jeff Patton
45Friday 15 June 2012
Itera)ve AND Incremental
• Mix the strategies:–Iterate to find and improve solu6ons
–Increment to add func6onality
Adapted from Jeff Patton
45Friday 15 June 2012
Itera)ve AND Incremental
• Mix the strategies:–Iterate to find and improve solu6ons
–Increment to add func6onality
Adapted from Jeff Patton
45Friday 15 June 2012
AgileBirth of a new Software Movement!
46Friday 15 June 2012
Agile has evolved over many years
Src: Jeff Patton
47Friday 15 June 2012
XP
Pragmatic
DSDM
Crystal Lean
Adaptive
Scrum
FDD
Agile
Agile Umbrella
48Friday 15 June 2012
Agile Manifesto
49Friday 15 June 2012
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:
49Friday 15 June 2012
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.
49Friday 15 June 2012
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.
49Friday 15 June 2012
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.
49Friday 15 June 2012
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.
49Friday 15 June 2012
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.”
© 2001 Agile Alliance. http://www.agilemanifesto.org
49Friday 15 June 2012
Agile Manifesto Principles
50Friday 15 June 2012
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
51Friday 15 June 2012
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
52Friday 15 June 2012
Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the shorter
timescale.
53Friday 15 June 2012
Business people and developers must work together daily
throughout the project.
54Friday 15 June 2012
Build projects around motivated
individuals. Give them the environment
and support they need, and trust them to get the job done.
55Friday 15 June 2012
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
56Friday 15 June 2012
Working software is the primary measure of progress.
57Friday 15 June 2012
Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace
indefinitely.
58Friday 15 June 2012
Simplicitythe art of maximizing the amount of
work not doneis essential.
59Friday 15 June 2012
Continuous attention to technical excellence and good design
enhances agility.
60Friday 15 June 2012
The best architectures, requirements, and designs emerge
from self-organizing teams.
61Friday 15 June 2012
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
62Friday 15 June 2012
It turns out...
63Friday 15 June 2012
It turns out...
Ziv's law -‐ specifica=ons will never be fully understood.
63Friday 15 June 2012
It turns out...
Ziv's law -‐ specifica=ons will never be fully understood.
Humphrey's law -‐ the user will never know what they want un=l aOer the system is in produc=on (maybe not even then)
63Friday 15 June 2012
It turns out...
Ziv's law -‐ specifica=ons will never be fully understood.
Humphrey's law -‐ the user will never know what they want un=l aOer the system is in produc=on (maybe not even then)
Wegner's lemma -‐ an interac=ve system can never be fully specified nor can it ever be fully tested.
63Friday 15 June 2012
It turns out...
Ziv's law -‐ specifica=ons will never be fully understood.
Humphrey's law -‐ the user will never know what they want un=l aOer the system is in produc=on (maybe not even then)
Wegner's lemma -‐ an interac=ve system can never be fully specified nor can it ever be fully tested.
Langdon's lemma -‐ soOware evolves more rapidly as it approaches chao=c regions (taking care not to spill over into chaos)
63Friday 15 June 2012
It turns out...
Ziv's law -‐ specifica=ons will never be fully understood.
Humphrey's law -‐ the user will never know what they want un=l aOer the system is in produc=on (maybe not even then)
Wegner's lemma -‐ an interac=ve system can never be fully specified nor can it ever be fully tested.
Langdon's lemma -‐ soOware evolves more rapidly as it approaches chao=c regions (taking care not to spill over into chaos)
Any association of predictive or defined processes with Agile is an exercise in futility. - Jeff
63Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
6. Easy access to experts
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
6. Easy access to experts
7. Strong technical environment
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
6. Easy access to experts
7. Strong technical environment
8. Sunny day visibility
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
6. Easy access to experts
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
6. Easy access to experts
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
10.High energy
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
6. Easy access to experts
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
10.High energy
11.Empowered teams
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Treat agile principles as “proper)es” you use to assess process health
1. Frequent delivery
2. Reflec6ve improvement
3. Close communica6on
4. Focus
5. Personal safety
6. Easy access to experts
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence
10.High energy
11.Empowered teams
12.Disrup6ve change
Performing a simple process health checkup: hZp://www.s)ckyminds.com/s.asp?F=S15474_COL_2
64Friday 15 June 2012
Our Team Rooms
65Friday 15 June 2012
some more plans…
66Friday 15 June 2012
src: ThoughtWorks India67Friday 15 June 2012
src: ThoughtWorks India
Work or Fun or Both?
68Friday 15 June 2012
src: ThoughtWorks India
Work or Fun or Both?
68Friday 15 June 2012
Agile Evolution
69Friday 15 June 2012
XP
Pragmatic
DSDM
Crystal Lean
Adaptive
Scrum
FDD
Agile
Agile Umbrella
70Friday 15 June 2012
Agile become...
XP
Agile
Scrum
71Friday 15 June 2012
72Friday 15 June 2012
Balance discovery with delivery
Delivery: building product right
Discovery: understanding the right product to
build
Src: Jeff Patton73Friday 15 June 2012
Then came along...
XP
Agile
LeanAgile-UX
ProductDiscovery
Agile Ecosystem
Scrum
74Friday 15 June 2012
High Level View of an Agile Process
Src: Jeff Patton75Friday 15 June 2012
Then came along...
XP
Agile
Agile-UX
ProductDiscovery
Agile Ecosystem
ScrumLean
Kanban
76Friday 15 June 2012
Where did Agile Originate?
Src: Jeff Patton77Friday 15 June 2012
Problem
Solu
tion
Known Unknown
Kno
wn
Unk
now
n
Src: Eric Ries
Where Agile appears to work best?
78Friday 15 June 2012
Problem
Solu
tion
Known Unknown
Kno
wn
Unk
now
n
A g i
l e
Src: Eric Ries
Where Agile appears to work best?
78Friday 15 June 2012
Problem
Solu
tion
Known Unknown
Kno
wn
Unk
now
n
A g i
l e ??
Src: Eric Ries
Where Agile appears to work best?
78Friday 15 June 2012
Kaizen vs. Kaikaku
79Friday 15 June 2012
Currently...
XP
Agile
LeanAgile-UX
ProductDiscovery
Dev-OPs
LeanStartup
AgileEcosystem
KanbanScrum
80Friday 15 June 2012
The Future
XPAgile
Agile-UX
ProductDiscovery
Dev-OPs
Lean Startup
Costumer Development
CDCD
ContinuousDelivery
MVP
Pivot
KanbanScrum Lean
81Friday 15 June 2012
82Friday 15 June 2012
Organizations have habits, and they will stick to their habits even at the risk of their own
survival.Brad Anderson, CEO, Best Buy
83Friday 15 June 2012
Organizational structures have a short life... Nobody likes to reorganize, and you
always run the risk that you distract your employees and lose focus on customers.
But if you don't do it, you lose your competitive edge.
Nancy McKinstry, CEO, Wolters Kluwer
84Friday 15 June 2012
85Friday 15 June 2012
86Friday 15 June 2012
Innovation
87Friday 15 June 2012
Metrics Mess
88Friday 15 June 2012
89Friday 15 June 2012
Metrics MessKnowledge Islands
90Friday 15 June 2012
91Friday 15 June 2012
Be careful not to…
Naresh Jainnaresh@agilefaqs.com
twitter: @nashjain
http://nareshjain.com
92Friday 15 June 2012
Be careful not to…
Naresh Jainnaresh@agilefaqs.com
twitter: @nashjain
http://nareshjain.com
Ques7ons?92Friday 15 June 2012
Be careful not to…
Naresh Jainnaresh@agilefaqs.com
twitter: @nashjain
http://nareshjain.com
Ques7ons?92Friday 15 June 2012
Recommended