What are we afraid of?

Don’t bother with this package if this
doesn’t look like your business:

1
Friday, May 21, 2010

Don’t bother with this package if this
doesn’t look like your business:

You have a couple of very successful Agile teams
who are living the Agile Manifesto and associated
Principles
And now you wonder..
How do I expand this in my global, regulated
large company (500+)?
...and (for a variety of business reasons) saying
“Scaling Agile is hard, so we won’t do it” is not an
option for you.

1

Scaling Agile

2

Is Scary!

3

What are we afraid of?

4

For large, global, diverse companies,
‘going Agile’ means you must
Create/support local optimization
Empower at the team level
Continue to meet Enterprise goals

5

The solution?

Automate your SDLC.

6

Think of this as an opportunity to increase
profit

7

and have fun!

8

What should our automated SDLC do
for our teams and our business?

URL for our processes
Hi Auditor, here’s how we think we develop
products!
URL for compliance to processes
Hi Auditor, here’s what we did!
What we need to do, should do, can/cannot do
is all documented in our regulated environment,
with Virtual Big Visible Charts and supporting
tools so that we can be geographically
distributed supporting a global economy.

9

What else could our automated SDLC
offer?
Be a value added tool for our global (distributed)
teams to support knowledge creation and
knowledge sharing.
Support formality in the situation where it is
needed, to offer tailoring when it is not.
Organically capture decisions and store artifacts.
Support code quality!
Support our Agile Adoption!
Support Issue Management!
Provide intelligence which can be actioned when
necessary.
Share the corporate vision so teams are not making
decisions in vacuums
10

What would a simple SDLC look like?

Your SDLC could be as simple as Wiki pages taking
you from Business Case through to Release.
Example Business Case wiki template: This could be
as simple as “What I am delivering, Why I am
delivering it, how much is it going to cost us”, with
tracking tool approvals (example, Jira) built-in.
Simple example of Wiki Process Compliance:
For any specific team anyone can see where they are
within the SDLC.
When the buttons ‘fade out’ team is in compliance with
the process.

11

Lets talk further about this regulatory
compliance
We’re regulated as a public company
Or as a data provider
Or perhaps safety, security regulations (FAA)
SOX, FFEIC, FAA,
..we are an auditable entity
This means we are expected to have auditable
processes, from product development through to
operations.

This does not mean we can’t Be Agile!
12

Think of this as an OPPORTUNITY!
Move away from heavy-weight processes to
processes where process validation is built-in.
Capture decision-making processes organically,
not through reams of papers - make it natural!
For example, move to a model where a tracking
tool (Jira, for example) tracks approvals so that
the living process becomes an auditable artifact.
Heavy-weigh processes are EXPENSIVE!
When trust is low, extra cost of V&V skyrockets and
slows down delivery
You will need to train your auditors however, who
will be expecting the paper trail!

13

Knowledge creation and sharing when
the information is an emergency:

What are your challenges as a
geographical distributed organization?

14

Where’s the knowledge today?
“On some shared network drive”
“In some word doc somewhere”
“Sharepoint, sccs, ecm..”
...the act of finding the information itself is time
consuming and too hard!
“He knows” (The single person that possesses
the knowledge that the others want, so much so
that he is CONSTANTLY interrupted.)

15

What are our Knowledge Creation and
Knowledge Sharing Goals?
Provide the teams with the ability to build
knowledge, share knowledge, and take action.
Provide the narrative on the business expectations
and expected results.
Build formality in where you need it and provide the
ability to tailor when you do not.
Example: Formal detailed design document can be
tailored out if team is co-located all speaking the same
language, however cannot be tailored out if team is
distributed across continents (and languages.)

16

Look! Another Opportunity!
Build a Knowledge Oasis Portal!
Capture all of the “He Knows” information.
Redirect all of the peer-to-peer information
Redirect “one owner of the document” information
Make the information linkable and searchable!
Create a master index of tacit knowledge.
ALL questions are possible: but document the answer
building the Wiki “as needed.”
Twiki, Wikis, (example Confluence) are your friends...

PEOPLE are the secret sauce to Agility: yet tools that
can share knowledge support the effort!
17

Knowledge Oasis Portal Benefits:

Your Key contributors to this Portal are not going
to be who’d expect them to be:
Your Knowledge Oasis Wiki Portal will give a voice
to everyone in the organization who may not share
their knowledge today!
Hosting “Fun, Contribute-to-the-Wiki”
competitions will accelerate this knowledge
sharing, making a huge difference!

18

Issue Management

19

Is this your starting point?

We start to ‘go agile’ with years of internally
branded waterfall as formally documented processes
flowing in our bloodstream.
We are likely vertically organized with Test (QA),
Development, Product Management in silos.
We have some Client-Server issue management tool,
which is very expensive.
Client-server issue management tools can be huge
impediments when you are geographically dispersed
(“when we are not in the home office, we end up
with a web interface”)

20

Where are your Operational
Expenditures really going?

Are you really solving problems with your issue
management processes...
or perhaps, are you just working around them?

21

Look! Another Opportunity!

22

Why not Optimize Issue Management?
Take a critical look at where you spend your OPEX.
Do you have horrendous renewal rates for issue
management systems?
Do they really solve problems?
Or do they make you work around them?
Is the issue management system a HELPER (to
solve the problems of optimizing product
development?)
Do you have incredibly complex workflows which
you use to legislate product development
behaviors.
...and do you spend time working around these
workflows?
23

Simplicity

Search within the organization for newfound
simplicity: Get back to a simple place.
Ask your initial Agile Pilot teams to help identify
thee complex workflows as impediments.
Save OPEX: there are awesome open source
tools for issue management available.
Spend time and due diligence on potential OPEX
savings as you can leverage these savings for
Agile tools (like a Continuous Integration tool.)

24

CODE QUALITY!

25

Improve Code Quality

Creating Awareness is the first step
Providing some visibility back to developers of
“what are the challenges in my code?”
How do you provide them with more knowledge
about their code?
Nobody can improve in a vacuum!
Wait 3 months for QA to pass on the product, and
nobody will remember.
Knowledge is power.

26

If you take just one thing away from
this presentation
In addition to living and loving the Agile Manifesto and
associated Agile principles
You will need great tools AND great processes if you’re
going to take Agile to scale.

Who would have thought that a cat bathing tool existed?
27

Example Code Quality tools
Continuous Integration (CI): Bamboo, Hudson, Maven
CruiseControl..etc.
Crucible with Fisheye for code reviews & reports to help
with communication across geographical boundaries.
Tools such as FindBugs for code static analysis.
Tools such as Clover to measure code complexity. Can be
used to look for hot spots, used beneath automated
testing infrastructure so that you can see how well your
applications are covered from an automated test
perspective. (#tests = not an effective measurement of code
quality!)
Use of Code Analysis tools (PMD)+ your Wiki Command
Line Interface (CLI) to publish metrics from CI
Not an exhaustive list...so do your due diligence
and leverage the OPEX savings here!
28

Benefits of Code Quality tools

We create the awareness and build the knowledge!
Teams are provided with better decision-making
power!
This helps us across geographical boundaries, giving
us the actionable intelligence so that people are
focused - not dealing with ‘noise’.
Ancillary benefit: Using our Wiki CLI as the unifying
force of “what we are building” and “how we are
building it”, sets us up with the opportunity to bring
all the information about a release to one place!

29

The need to move your organization
to Agility should be clear:
Committed Scope What the Market Really Needed!

We gave you what we
signed up to give you!
Turns out, that wasn’t
what the market
needed!

Project inception We commit to scope

30

Be Agile! Embrace Agility!

Recognize early that we are beginning this
Agile quest with processes built around
resisting change, not managing effective
change.
Take your organization from a HEAVY process
organization to the Agile world.
Yet do this consciously: remembering your
regulated environment with your business
constraints.

31

Optimizing Agile Adoptions

With a geographically distributed organization, you
need distributed visibility of how teams are doing.
Need effective backlog management!
Need a Agile/Scrum tool that takes distributed
teams effectively through planning boards to task
and resulting metrics.
Need a tool that can provide actionable
intelligence to the team
Example tools: Jira + Greenhopper , Serena,
VersionOne, Rally, Scrumworks....

32

Benefits of a great Scrum tool
The team can focus on what is really needed and
avoid the noise.
Planning board works effectively for remote and
geographically distributed teams, as well as for co-
located teams.
Transparency is key: global visibility from the team
level to the product dashboard view.
Opportunity to set up friendly competition between
multiple product lines, where everyone can see
progress to-date, code quality, with global visibility
of each of the products.

33

Ancillary benefits

Processes and tools HELP instead of HURT!
We like to come to work!
We focus on what matters!
We are proud of our product!

34

First steps in creating your SDLC..
Accept that if you focus only on your development phase
your constraint will soon be moving.
Front and back ends will have to be adapted and optimized
as well (portfolio management, services, sales.)
User Stories developed iteratively
Deliveries will be offered and sold iteratively
How will this look?
Define your SDLC scope.
Plan to build your first draft Agile SDLC from success of
your initial Pilot teams.

35

Merci!

Catherine Louis - cll@cll-group.com
catherinelouis - twitter
http://www.linkedin/in/catherinelouis - linkedin
36

What are we afraid of?

Recommended

Recommended

More Related Content

Similar to What are we afraid of?

Similar to What are we afraid of? (20)

More from Global Agile Consulting- CLL-Group, LLC

More from Global Agile Consulting- CLL-Group, LLC (11)

Recently uploaded

Recently uploaded (20)

What are we afraid of?