More Related Content Similar to Agile, IT and the Business Community (20) Agile, IT and the Business Community1. Agile, IT, and the Business Community
Presented by:
William F. Nazzaro
Vice President
Process Synergy, LLC
bill@ProcessSynergy.com
(610) 831-1151
Version 1.00
2. Process Synergy Background
A Philadelphia-based consultancy dedicated to the highest-quality
delivery of project mentoring, training and organizational transformation
Full lifecycle consulting, coaching and mentoring
– Requirements – Use Cases, User-Stories, IIBA
– Process – Agile (XP, TDD), Unified Process, CMMi
– Project Management – Scrum, Iterative, PMI
– Architecture – Service-Oriented Architecture
– Organizational Change Management and Improvement
– Delivered On-Site, Globally
Full lifecycle software training curriculum
– Highly differentiated offerings
– Experiential approach and skills building
– Virtual and on-site
Multi-tool vendor expertise
– IBM Rational, Microsoft, Borland, HP Mercury, BluePrint, VersionOne, RallyDev
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 2
3. Presenter’s Background
Twenty years of success in delivering enterprise software solutions for Fortune
100 companies, he has provided unparalleled services in project mentoring, use
case and user story training and modeling, agile SCRUM, XP, TDD, service-
oriented architecture, Unified Process and CMMi adoption, Java, C++, C, and
Smalltalk programming languages, and technical curriculum development and
delivery.
His pragmatic emphasis on project execution and process improvement has
benefited major insurance, health-care, human resources, stock market
organizations and Department of Defense where he has enabled the transformation
of their corporate development processes and development teams of diverse skill-
levels.
He has provided in-depth talks on Agility, Use Case Modeling, Service-Oriented
Architecture, Unified Process, Object Technology and Data Modeling.
He has extensive background in project management, and has successfully led
teams on multi-million dollar projects to provide the highest-quality technical
solutions in the most efficient and effective manner.
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 3
4. Premise
IT projects are failing at a rate of 25%, and 45% of our projects are
challenged for being late, over-budget, or providing less than
required features and functions
Unfortunately this has been a habitual problem for IT and more
importantly it has been a source of conflict and contention
between IT and the business community we serve
Our business community, more than ever, demands speed and
flexibility in taking products to market.
As a result, approximately 35% of IT organizations have adopted
or are in some form of adoption of agile practices and agile
software development
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 4
5. Agenda
Common Agile Misconceptions
Why Should the CIO or CTO Care About Agile?
What Does the Business Community Need to Know About Agile?
Barriers to Successful Enterprise Agile Adoption
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 5
6. Agenda
Common Agile Misconceptions
1. Agile Teams Don’t Plan or Estimate
2. Agile Only Works for Co-Located Teams
Why Should the CIO or CTO Care About Agile?
What Does the Business Community Need to Know About Agile?
Barriers to Successful Enterprise Agile Adoption
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 6
7. 1. Agile Teams Don’t Plan or Estimate – 1
Why do we plan? My one client told me she wanted to
– Reduce risk and uncertainty get away from the way they ran their
– Support decision making traditional projects
– Establish trust – We spend time planning and estimating at
the beginning of the project
– Convey information
– We commit to this project plan and
estimate at the beginning of the project
A good plan is one that support – We know, and our customer knows, the
reliable decision making plan and estimate are incorrect
– Historical data verifies we are typically
incorrect on our plan and estimate
Steve McConnell, Software Estimation, 2006
– We move forward with the expectation that
the information is correct
– We are disappointed and our customer is
upset when we fail to deliver based on our
initial plan and estimate
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 7
8. 1. Agile Teams Don’t Plan or Estimate – 2
Somewhere along the line a belief
cropped up that Agile projects don’t
do planning or estimating
Agile teams
This is a MYTH, in fact I’ve found I’ve typical focus Release
done more planning and estimating
it’s just that I plan to certain horizons Iteration
There are different levels of planning Day
– Release planning determines the scope,
schedule, and resources needed for a
product
– Iteration planning determines which
features will be built in an iteration, and
what tasks need to be done to build them
– Day planning monitors progress and deal Planning Onion – Mike Cohn,
with obstacles Agile Estimating and Planning, 2006
We plan and estimate to our horizon,
then we inspect and adapt
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 8
9. 2. Agile Only Works for Co-Located Teams – 1
To be truthful, agility can be more
difficult for teams that aren’t co-
located because of the expectation to
communicate more
So how can we over come this?
We have to be more creative
– Shifting of hours or work schedules to
create an opportunity for overlap
– Leveraging a variety of communication
tools (e.g., GoogleTalk, IM, Wikis, virtual
team rooms, digital cameras, etc.)
Strive for purpose and value-driven
communication
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 9
10. 2. Agile Only Works for Co-Located Teams – 2
When hiring team members stress their
ability to be able to communicate
Communication is more than just
talking, it can also be
– How to express an idea (i.e., Textual, UML,
Architecturally, code)
– Do they seek to be understood or to
understand
– How do they listen?
Ironically, teams that don’t
communicate very well that are co-
located are the first to mention that
agile won’t work for teams that aren’t
co-located
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 10
11. Agenda
Common Agile Misconceptions
Why Should the CIO or CTO Care About Agile?
1. Traditional vs. Agile Processes
2. Traditional vs. Agile Budgeting
3. Some Numbers to Consider
1. What Does the Business Community Need to Know About Agile?
2. Barriers to Successful Enterprise Agile Adoption
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 11
12. Traditional vs. Agile Processes * – 1
Traditional Processes
– Lockup capital for a long time by
having significant work in process
before seeing any realization of
business value
Agile Processes
– By releasing incrementally we open
up the opportunity to obtain business
value much earlier than would
otherwise be possible and prior to the
completion of the overall project
– This can be done by breaking the
project into "feature chunks" that are
delivered every few weeks
* Rudd, J. The Business Case for Agility, 2009
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 12
13. Traditional vs. Agile Processes – 2
Project
halted
% Working
Software
Agile IT Process
1 2 3 4 5 6 7 8 9 10 11 12 Month
% Working
Software
Traditional IT
Process
1 2 3 4 5 6 7 8 9 10 11 12 Month
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 13
14. Traditional vs. Agile Budgeting *
Traditional Processes
– With a fixed capital budget, larger projects
mean fewer projects
– When no return is available until the
waterfall process is complete, longer
projects increase the likelihood that no
return will be obtained during the annual
budget cycle
– This leads to fewer investments and
limited opportunity to offset losing projects
with winning projects
Agile Processes
– With an Agile portfolio approach, the
business can break down long-term
projects into short-term projects
– This provides more frequent opportunities
to both evaluate and adjust investments so
that you can:
» Adjust portfolio on the basis of market
changes and customer feedback
» Actively reprioritize the project portfolio.
» Reallocate funds to stronger performers.
* Rudd, J. The Business Case for Agility, 2009
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 14
15. Some Numbers To Consider *
93% increased productivity 1
88% increased quality 1
83% improved stakeholder
satisfaction 1
49% reduced costs 1
66% three-year, risk-adjusted return
on investment 2
Reasons for Agile adoption include:
– 47% to better manage project scope 3
– 45% to create clear business
requirements 3 1 “Agile Methodologies: Survey Results”, Shine Technologies, 2003
2 Forrester Research, 2004
– 40% to speed or better predict time to 3 “Agile 2006 Survey Results and Analysis”, Digital Focus, 2005
market 3
* Source: http://www.rallydev.com
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 15
16. “I’ve change our funding model by having our teams prove they are
worthy of additional investment by demonstrating success early”
“Some of my most successful projects have been the ones that I
stopped early before a large investment was made”
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 16
17. Agenda
Common Agile Misconceptions
Why Should the CIO or CTO Care About Agile?
What Does the Business Community Need to Know About Agile?
1. Agile Expects Customer Involvement
2. Fixed Bid vs. Time and Materials
3. You Prioritize Our Work
Barriers to Successful Enterprise Agile Adoption
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 17
18. 1. Agile Expects Customer Involvement
Expect the customer or Product
Owner to be involved with the team
Ideally the product owner should be
thought of as part of the team
Scenario: Customer may say,
– “Perfect, I really want to get this done”
» On this project, we physically co-located
the product owner with the team
– “I want to be engaged but I don’t have
enough time”
» On this project, the product owner
established “office hours” and the team
knew they could call on him during those
times
– “Working with you isn’t my day job”
» On this project, the product owner was
unavailable with the exception of
possibly 30 minutes at the beginning or
end of day
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 18
19. 1. Agile Expects Customer Involvement (cont.)
Regardless of the scenario we need
to be prepared to let our customer
know our expectations for their time
and the amount of involvement we
will require of them
We can let them know we will
require them for
– Product Backlog
– Release & Sprint Planning
– Review and Retrospective
We can be creative with their
involvement and work with them
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 19
20. 2. Fixed Bid vs. Time and Materials (T&M) *
T&M is most likely the biggest deterrent and concern that a
customer will have when you are trying to move towards Agile
Source: http://www.rallydev.com
On an agile project the customer can set the budget they want to
spend, they can set the timeline, and then they can prioritize the
features
* Sliger and Broderick, The Software Project Manager’s Bridge to Agility, 2008
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 20
21. 2. Fixed Bid vs. Time and Materials (T&M) * (cont.)
Based on the Standish Group, we should remind
our customers that 64% of software features are
rarely or ever used
– The Standish Group’s CHAOS Report 2006
Fixed scope / fixed price results in
– Customer required to specify everything upfront
– Any change to the original specifications goes to
through a change control process
– Customer realizes a change is need
– IT doesn’t want to change it because it will impact the
project plan and budget
– Customer doesn’t want to pay for the change because
it should have been there all along
Sligler and Broderick stated in their book
Source: www.softhouse.se
– Changing contracts from fixed scope / fixed price to a
pay-as-you-go time and material (T&M) means that
customers are now more responsible for the success
of the product
– The customer directly control the cost of the contract
because they authorize its existence on a recurring
basis
* Sliger and Broderick, The Software Project Manager’s Bridge to Agility, 2008
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 21
22. 3. You Prioritize The Work
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 22
23. You Prioritize The Work (cont.)
Product Backlog Sprint Backlog
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 23
24. Agenda
Common Agile Misconceptions
Why Should the CIO or CTO Care About Agile?
What Does the Business Community Need to Know About Agile?
Barriers to Successful Enterprise Agile Adoption
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 24
25. Barriers to Agile Adoption – 1
Organizational
Change
Management
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 25
26. Barriers to Agile Adoption – 2
Common phrases I’ve heard
– “We’re agile but…”
– “We’re doing SCRUM but…”
It’s usually the “but” that makes them not agile
Unfortunately for many, they are just practicing timeboxed
waterfall development and calling it agile,
We call it “waterative” approach to development
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 26
27. Agenda
Common Agile Misconceptions
Why Should the CIO or CTO Care About Agile?
What Does the Business Community Need to Know About Agile?
Barriers to Successful Enterprise Agile Adoption
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 27
28. For More Information
If you have questions, or would like more information about our
consulting, coaching, and agile training curriculum:
– Please call 1.610.831.1151
– Email: bill@ProcessSynergy.com
– http://www.ProcessSynergy.com
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 28
29. In Closing…
“Whether you think that you can, or that you can't,
you are usually right” – Henry Ford
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 29
30. Agile, IT, and the Business Community
Presented by:
William F. Nazzaro
Vice President
Process Synergy, LLC
bill@ProcessSynergy.com
(610) 831-1151
Version 1.00
32. 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 items
on the left more."
* www.agilemanifesto.org
The Agile Manifesto, created in 2001 by a group of software methodologists,
produced the agile revolution that has significantly impacted the software
development industry in a very short period of time
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 32
33. Implementing and Adopting Agility
Depends on:
– Agile process/method you choose
– Successfully focusing your pilot agile project (not projects)
– Organization’s culture and willingness
» To adopt change
» To accept limited failure and learn from it
» To work in integrated, cross-functional teams, not business “silos”
– Individuals’ willingness to be part of a TEAM, where no one has “rank”
– Project Managers’ / Architects’ / Developers’ ability to “let go” of being the
» Hero
» Dictator
» Star of the project
» Like everyone else, is just another member of the Team
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 33
34. Traditional Management – Command and Control *
Management
Subordinates
Receives Makes decisions
reports Gives orders
Manager
Subordinates Complies and
Reports
executes
* Roman Pichler, Managers in Scrum 2008
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 34
35. Agile Management – Agile Leadership Principles *
Team
Servant-
Servant-
Leadership
Leadership
Management Empirical
Empirical Empowerment
Empowerment
Management
Management
Quality-
Quality- Continuous
Continuous
First
First Improvement
Improvement
Standardisation
Standardisation
* Roman Pichler, Managers in Scrum 2008
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 35
36. Agile Doesn’t Work For Matrixed Teams Or Organizations – 1
Matrixed teams are created by pulling a variety of
different resources from resource managers and
these resources are allocated to a project manager
while working on that project
I’m actually fine with this concept of matrixed if
that’s all we did and Agile does work if that’s all we
did
However, we usually go way beyond this
We’ve mutated the concept of matrix into time-
slicing to gain maximum efficiency of resources
– Bill and Patty are each allocated 50% to project A and
50% to production support
– OR –
– Rick is allocated to four projects and each project is
expecting that he is available to work 35% on their project
(OK, who’s checking the math here?)
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 36
37. Agile Doesn’t Work For Matrixed Teams Or Organizations – 2
What’s an interruption?
1. To break the continuity,
2. To hinder or stop the action of (someone) by breaking in on,
3. To break in on an action
Why am I not a fan of time-slicing?
– If you're being interrupted while working on a task you’re losing time
– For a simple IM or telephone call Microsoft 1 found it took their workers 15
minutes to get back into the task whenever they were interrupted
– The impact of changing projects is even greater, every time you're have a
context switch, it takes even longer to remember not just the task but why
you were working on the task
– Studies have shown that productivity can be hindered by as much as 40% 2
1 Microsoft – “The Grand Seduction of Multitasking”
2 Mike Cohn – “The Dark Side of Multi-Tasking
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 37
38. Agile Doesn’t Work For Non Co-located Teams – 1
To be truthful, agility can be more
difficult for teams that aren’t co-
located because of the expectation to
communicate more
So how can we over come this?
We have to be more creative
– Shifting of hours or work schedules to
create an opportunity for overlap
– Leveraging a variety of communication
tools (e.g., GoogleTalk, IM, Wikis, virtual
team rooms, digital cameras, etc.)
Strive for purpose and value-driven
communication
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 38
39. Agile Doesn’t Work For Non Co-located Teams – 2
When hiring team members stress their
ability to be able to communicate
Communication is more than just
talking, it can also be
– How to express an idea (i.e., Textual, UML,
Architecturally, code)
– Do they seek to be understood or to
understand
– How do they listen?
Ironically, teams that don’t
communicate very well that are co-
located are the first to mention that
agile won’t work for teams that aren’t
co-located
| Copyright © 2010 Process Synergy, LLC . All Rights Reserved. | Page - 39