What are we afraid of?

37
Don’t bother with this package if this doesn’t look like your business: 1 Friday, May 21, 2010

description

Large, regulated industries (like aerospace and telecom, for example) have unique challenges for scaling Agile for distributed, global teams of 500+ people, and associated code bases of several million lines of code. This package focuses on the unique challenges for this type of business environment. Given the premise of a few pilot teams up and running with success, living, loving the Agile Manifesto and associated principles, how do we expand local Agile team success in this environment?

Transcript of What are we afraid of?

Page 1: What are we afraid of?

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

1Friday, May 21, 2010

Page 2: What are we afraid of?

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

1

You have a couple of very successful Agile teams who are living the Agile Manifesto and associated PrinciplesAnd 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.

Friday, May 21, 2010

Page 3: What are we afraid of?

Scaling Agile

2Friday, May 21, 2010

Page 4: What are we afraid of?

Is Scary!

3Friday, May 21, 2010

Page 5: What are we afraid of?

What are we afraid of?

4Friday, May 21, 2010

Page 6: What are we afraid of?

For large, global, diverse companies, ‘going Agile’ means you must

5

Create/support local optimizationEmpower at the team levelContinue to meet Enterprise goals

Friday, May 21, 2010

Page 7: What are we afraid of?

The solution?

6

Automate your SDLC.

Friday, May 21, 2010

Page 8: What are we afraid of?

Think of this as an opportunity to increase profit

7Friday, May 21, 2010

Page 9: What are we afraid of?

and have fun!

8Friday, May 21, 2010

Page 10: What are we afraid of?

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

9

URL for our processesHi Auditor, here’s how we think we develop products!

URL for compliance to processesHi 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.

Friday, May 21, 2010

Page 11: What are we afraid of?

What else could our automated SDLC offer?

10

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

Friday, May 21, 2010

Page 12: What are we afraid of?

What would a simple SDLC look like?

11

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.

Friday, May 21, 2010

Page 13: What are we afraid of?

12

Lets talk further about this regulatory complianceWe’re regulated as a public companyOr as a data providerOr perhaps safety, security regulations (FAA)SOX, FFEIC, FAA, ..we are an auditable entityThis means we are expected to have auditable processes, from product development through to operations.

This does not mean we can’t Be Agile!

Friday, May 21, 2010

Page 14: What are we afraid of?

13

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!

Friday, May 21, 2010

Page 15: What are we afraid of?

Knowledge creation and sharing when the information is an emergency:

What are your challenges as a geographical distributed organization?

14Friday, May 21, 2010

Page 16: What are we afraid of?

15

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.)

Friday, May 21, 2010

Page 17: What are we afraid of?

What are our Knowledge Creation and Knowledge Sharing Goals?

16

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.)

Friday, May 21, 2010

Page 18: What are we afraid of?

17

Look! Another Opportunity!Build a Knowledge Oasis Portal!Capture all of the “He Knows” information.Redirect all of the peer-to-peer informationRedirect “one owner of the document” informationMake 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!

Friday, May 21, 2010

Page 19: What are we afraid of?

18

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!

Friday, May 21, 2010

Page 20: What are we afraid of?

Issue Management

19Friday, May 21, 2010

Page 21: What are we afraid of?

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”)

20Friday, May 21, 2010

Page 22: What are we afraid of?

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?

21Friday, May 21, 2010

Page 23: What are we afraid of?

22

Look! Another Opportunity!

Friday, May 21, 2010

Page 24: What are we afraid of?

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?

23Friday, May 21, 2010

Page 25: What are we afraid of?

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.)

24Friday, May 21, 2010

Page 26: What are we afraid of?

CODE QUALITY!

25Friday, May 21, 2010

Page 27: What are we afraid of?

Improve Code Quality

Creating Awareness is the first stepProviding 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.

26Friday, May 21, 2010

Page 28: What are we afraid of?

If you take just one thing away from this presentation

In addition to living and loving the Agile Manifesto and associated Agile principlesYou will need great tools AND great processes if you’re going to take Agile to scale.

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

Friday, May 21, 2010

Page 29: What are we afraid of?

Example Code Quality toolsContinuous 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 CINot an exhaustive list...so do your due diligence and leverage the OPEX savings here!

28Friday, May 21, 2010

Page 30: What are we afraid of?

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!

29Friday, May 21, 2010

Page 31: What are we afraid of?

30

Project inception We commit to scope

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!

The need to move your organization to Agility should be clear:

Friday, May 21, 2010

Page 32: What are we afraid of?

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.

31Friday, May 21, 2010

Page 33: What are we afraid of?

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 teamExample tools: Jira + Greenhopper , Serena, VersionOne, Rally, Scrumworks....

32Friday, May 21, 2010

Page 34: What are we afraid of?

Benefits of a great Scrum toolThe 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.

33Friday, May 21, 2010

Page 35: What are we afraid of?

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!

34Friday, May 21, 2010

Page 36: What are we afraid of?

35

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 iterativelyDeliveries will be offered and sold iterativelyHow will this look?

Define your SDLC scope.Plan to build your first draft Agile SDLC from success of your initial Pilot teams.

Friday, May 21, 2010

Page 37: What are we afraid of?

Merci!

36

Catherine Louis - [email protected] - twitterhttp://www.linkedin/in/catherinelouis - linkedin

Friday, May 21, 2010