2. Creative Commons License 3.0
This work is licensed under the
Creative Commons AttributionNonCommercial-ShareAlike 3.0 Unported
License.
To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-sa/3.0/
or
send a letter to Creative Commons, 171 Second
Street, Suite 300, San Francisco, California,
94105, USA.
Revision 1.0
Necessary but not sufficient
2
3. You are free:
to Share — to copy, distribute and transmit the work
to Remix — to adapt the work
Under the following conditions:
Attribution — You must attribute the work in the
manner specified by the author or licensor (but not in
any way that suggests that they endorse you or your
use of the work).
Noncommercial — You may not use this work for
commercial purposes.
Share Alike — If you alter, transform, or build upon
this work, you may distribute the resulting work only
under the same or similar license to this one.
Revision 1.0
Necessary but not sufficient
3
4. With the understanding that:
• Waiver — Any of the above conditions can be waived if
you get permission from the copyright holder.
• Public Domain — Where the work or any of its
elements is in the public domain under applicable law,
that status is in no way affected by the license.
• Other Rights — In no way are any of the following rights
affected by the license:
– Your fair dealing or fair use rights, or other applicable copyright
exceptions and limitations;
– The author's moral rights;
– Rights other persons may have either in the work itself or in how
the work is used, such as publicity or privacy rights.
Notice — For any reuse or distribution, you must make
clear to others the license terms of this work. The best
way to do this is with a link to this web page.
Revision 1.0
Necessary but not sufficient
4
5. Topics
•
•
•
•
•
•
About Me
Do What I Peach
That how we do it here
Agility we love it
Mission Impossible
Questions
Revision 1.0
Necessary but not sufficient
5
6. About Me
• Suradet Jitprapaikulsarn, Ph.D.
• Lecturer
• Department of Electrical and Computer
Engineering
• Naresuan University
• Phitsanulok
• Email: suradet.j@gmail.com
• Facebook: Suradet Jitprapaikulsarn
• Url: www.ajarnsuradet.com
Revision 1.0
Necessary but not sufficient
6
7. About Me (Cont.)
•
•
•
•
Apply PSP since 1997
Apply TDD since 1999
1st Thai ScrumMaster since 2009
Was the only authorized PSP instructor in
Southeast Asia
• 1st Thai Certified PSP developer
• 5 times CMMI appraisal team member
• Only Asian instructor to be invited for Software
Architecture workshop at SEI, 8 year in a row
(since 2006)
Revision 1.0
Necessary but not sufficient
7
8. Do What I Peach
• Case 1 An In-house IT department of an
international company
– The organization invested in a lot of agile
training
– Hire outside experts
• Result
– Agile practices disappear within a few years
Revision 1.0
Necessary but not sufficient
8
9. Key Problems
• Management want agile favor but not the
work to be agile
• Training ≠ Practicing
• Too many approaches to agility
• Big bang
• Traditional metrics
Revision 1.0
Necessary but not sufficient
9
10. Do What I Peach
• Case 2 An In-house IT department of an
international company
– Start with one team was interested in Agile
– The whole team took a course in agility
– Hire an outside expert
• Result
– Agility is still here (since 2007)
– Not the entire organization is agile but
growing
Revision 1.0
Necessary but not sufficient
10
11. Key Success Factor
• Freedom given by management
• Osmosis approach
• One approach at a time
Revision 1.0
Necessary but not sufficient
11
12. That How we do it here
• Case 1: An IT company
– Long established (Since 1994)
– Planned to implement agility the whole
organization (2001)
• Result
– Agility is still being talked here (But not
practice)
– The first three agile projects failed
Revision 1.0
Necessary but not sufficient
12
13. Key Problems
• Change before try
• Individual performance is the key for
advancement
• Only profit is matter
• Schedule is the most important
• No management involvement
Revision 1.0
Necessary but not sufficient
13
14. That How we do it here
• Case 2: An IT company
– Long established (Since 2001)
• Result
– Not everyone know that they are actually
practice agility
Revision 1.0
Necessary but not sufficient
14
15. Key Success Factors
• Agile is ingrained in how the company do
things starting from management
• Flexible and willing to change
Revision 1.0
Necessary but not sufficient
15
16. Agility we love it
• Case 1: A medium-sized software
company
– Agile practices from the start (2005)
• Result
– Went bankrupt in 2011
Revision 1.0
Necessary but not sufficient
16
17. Key Failure
•
•
•
•
Poor contract management
Financial management
Poor Marketing
No architect
Revision 1.0
Necessary but not sufficient
17
18. Agility we love it
• Case 2: A medium-sized software
company
– Agile practices from the start (2006)
• Result
– Triple the size of the company
Revision 1.0
Necessary but not sufficient
18
19. Key Success
• Carefully select the customers
• Good strategic planning
• Excellent tactical execution (At least one
architect in every project and every tem)
Revision 1.0
Necessary but not sufficient
19
20. Missing Impossible
• Case 1 Revise a legacy product
– A very long-life product (Since 1998)
• Result
– 9 hours of testing time
– Only a few practices still used
Revision 1.0
Necessary but not sufficient
20
21. Key Problems
• Document is not necessary
• Testing is necessary evil
• Change before try
Revision 1.0
Necessary but not sufficient
21
22. Missing Impossible
• Case 2 Revise a legacy product
– A very long-life product (Since 1995)
– Start agility in version 12 (2009)
• Result
– Reduce test time from 9 hr to 10 minutes
– Continuous testing (2010)
– Continuous integration (2012)
Revision 1.0
Necessary but not sufficient
22
23. Key Success Factor
• One component at a time
• Test-driven change
• Document as code
Revision 1.0
Necessary but not sufficient
23
24. Conclusion
• Agile is necessary but not sufficient
Revision 1.0
Necessary but not sufficient
24