SDLC Smashup

SDLC Agile Smashup Keynote

Lester Martin, Enterprise Architecture

Sep 24, 2012

Why We’re Here & What We’re Going To Do

(S)mashup our various agile practices, tools and experiences

– Nobody follows an agile methodology (oxymoron?) EXACTLY

– We all do things a bit differently; this includes tools

Benefit from this collaboration

– Find out what is available for all to use

– Share our own best practices

– Encourage each other to try something new & to refactor mercilessly

– Foster new conversations & relationships

Have some fun!

2

The Sky is Falling!!

NASA has determined that Asteroid 2004 NM4 (aka Apophis) will

come “scarily close to Earth on April 13, 2029, but it will not hit”

– ¼ mile wide which would yield in “localized or regional” (take out

something like Texas), but isn’t considered an extinction event

– Come within 18,600 miles of Earth and be visible to the naked eye

3

What Do We Do??

We blow it up of course, but HOW?

Like all good problems, we solve it

with software, but still… HOW?

Stream a movie from Netflix!?!?

Einstein said, “If I had only one hour

to save the world, I would spend fifty-

five minutes defining the problem, and

only five minutes finding the solution”

But… is he right?

4

Software Is Different

5

We Use a Software Development Process

Check out Barry Hawkin’s How We Got Here, And What To Do

About It & Supplement as I’m liberally cherry-picking his work

– We’ve had Waterfall for as long as we’ve had computers, but then came

RUP, then XP and Scrum, and now Lean/Kanban

– Interestingly enough, each enjoying successively shorter seasons of

favor as the de facto choice

As Barry says, “Process is but a framework to facilitate the

collaboration of a group of people to produce a desired outcome.

It is not a substitute for culture, technical excellence, discipline,

and product strategy” – So… how did we get here??

6

Waterfall

Dr Winston Royce published “Managing the Development of

Large Software Systems” in 1970

– Often cited as the source of the “Waterfall Process”

– Like all the classical history of our profession (ex: Codd’s RDBMS

paper), this one deserves our attention

– Paper expressed personal views based on successful projects for

“spacecraft mission planning, commanding and post-flight analysis”

– Royce wanted to share the prejudices that were based on experience

– Introduced a “more grandiose approach to software development” which

we still all cringe at today…

7

Grandiose Approach to Software Development

8

But Wait… There’s (ALWAYS) More!!

Royce immediately follows up with a diagram that illustrates how

these steps relate to one another in an iterative process

People have historically latched on to the last diagram

Royce explicitly says his next diagram “portrays the iterative

relationship between successive development phases”

He implies that any given step of the process is iterating with the

steps immediately before and after, though sometimes even

more that that.

9

Waterfall – Part Deux

10

Waterfall – Change Causes Catastrophe

11

Testing/Validation Drives Change

Royce was right to realize that testing & validation were the

change agents and recommended these steps to prevent issues

1. Program Design Comes First (especially on cross-functional points)

2. Document the Design (a sound/disciplined approach to development)

3. Do It Twice (throw away first impl and rebuild with lessons learned)

4. Plan, Control and Monitor Testing (who can disagree with that)

5. Involve the Customer (Royce sounds like an Agilist to me)

“For some reason what a software design is going to do is subject to wide

interpretation even after previous agreement. It is important to involve the

customer in a formal way so that he has committed himself at earlier points

before final delivery. To give the contractor free rein between requirement

definition and operation is inviting trouble.”

12

Then Came the Rational Unified Process

Rational/IBM gave us RUP with its best practices

1. Develop iteratively, with risk as the primary driver

2. Manage the requirements

3. Employ a component-based architecture

4. Model software visually

5. Continuously verify quality

6. Control changes

Burdensome and was enforced w/costly & cumbersome tools

Focused on mitigating, if not avoiding, change through rigor

Most tried to use all instead of piece-mealing its building blocks

13

Hungrily Followed with Agile Thoughts and Approaches

In 1994, XP began to be practiced and Scrum followed in 1995

– XP put focus on technical practices

– Scrum shoots for repeatable levels of throughput

2001 brought us the Agile Manifesto with its Values

– Individuals and interactions over process and tools

– Working software over comprehensive documentation

– Customer collaboration over contract negotiation

– Responding to change over following a plan

And then Lean & Kanban (from the good folks at Toyota

manufacturing) with their respective core practices

14

Now Everyone Gets It

15

It Is What It Was –or – It’s Still a Good Idea!

There’s value from the past

Processes are more evolutionary than revolutionary

– There are few new ideas, mostly new expressions

From the beginning, we need customer involvement/commitment

Testing & Validation are still critical

Tools are just enablers

16

What To Do About It

Pursue understanding

Don’t make process a religion

Realize the primacy of culture

Commoditization of excellence is a myth

Embrace hard work, dispel myths of ease

– Work is still hard

– Internal adoption levels vary

Use consultants sparingly

“Start; the rest is easy” – George W. Jenkins (founder of Publix)

17

Rigidity Drives Agility?

Yes, it does, but we need a nicer word – how about Versatility?

If we every want to focus on business problems and not just

technical problems we have to accepted that

– there will NEVER be a SINGLE WAY to do EVERYTHING, but

– VERY OFTEN there is a GOOD ENOUGH way to do MOST things

Yes, “tools are just an enabler”, but using the same tools (as

much as possible) is a giant enabler to Versatility

Versatility benefits

– Organizations get things done quicker w/ smaller teams & simpler envs

– Employees as we can more quickly work to other teams & applications

18

What About the (metaphorical) Asteroid??

Well… we’ve spent a lot of time fighting over software

development processes & tools…

Fortunately, Apophis missed up

Unfortunately, it is swinging back in 7 more years for

another Friday the 13th potential impact in 2036

Let’s get to work…

– Let’s be agile

– Let’s be versatile

– This time, let’s get Bruce Willis!

– And the needed eclectic team!!

19

SDLC Tools Backdrop and Go-Forward Approach

Limited SDLC Tools Standards

– High Costs: every team selecting, purchasing, deploying/leveraging and

supporting their own set of tools from a variety of vendors

– Limited Versatility: team members understand well their own SDLC tools

selection, but do not have leverageable skills across the enterprise

Standardize on Tools Across Programming Models

– Cost is not the primary criteria in determining a standard set of tools, but

it is a very important one

Utilize a “pay as you grow” financial approach instead of a giant up-front charge

– Increase versatility amongst PM, BA, QA and architect/developer roles

in all of our business units and across development technology stacks

20

SDLC Reference Model

SDLC Components

SDLC Components – Project Management Domain

SDLC Components – Development & Build Domain

SDLC Components – Testing Domain

Traceability

Cornerstone

The cornerstone of an SDLC process is capturing Work

– Issues, Bugs, Tasks, Stories, etc

Work Items should reference requirements for new work being

done

Multiple ways for defects to be turned into Work Items

– Manually or from the integrated test case management platform

Build systems should be able to record failures as Work Items

Source code commits will be bi-directionally linked to the Work

Items they are implemented for

27

Reference Implementation (Standards) – Visualization

Reference Implementation (Standards) – TabularJava .NET *nix C/C++ Mainframe

Documentation Confluence + Gliffy TBD Confluence + Gliffy Confluence + Gliffy

Requirements Confluence + Gliffy

GreenHopper

TBD Confluence + Gliffy

GreenHopper

Confluence + Gliffy

GreenHopper

Work Items JIRA Team Foundation Server JIRA JIRA

Agile GreenHopper Team Foundation Server GreenHopper GreenHopper

Develop Eclipse Visual Studio Eclipse and other *nix

editors

TSO

SCM SVN Team Foundation Server SVN CA Endeavor

Build Jenkins + Sonar Team Foundation Server Jenkins CA Endeavor

Repository Nexus Nuget Nexus CA Endeavor

Code Viewer/Diff FishEye Visual Studio FishEye CA Endeavor

Code Review Crucible TBD Crucible Internal tools

Test Case Management Zephyr TBD Zephyr Zephyr

Functional Testing Selenium

soapUI

Selenium

soapUI

MSTest

soapUI Internal tools

Performance Testing JMeter JMeter

MSTest

JMeter Internal tools

Automated Testing JUnit MSTest CppUnit Internal tools

Finance PPM (iNav) PPM (iNav) PPM (iNav) PPM (iNav)

PPM/iNav is Still Important

While runtime integration is technically possible, this standards

list does not dictate any specific S2S integration strategy

– Primarily due to no single (or small number of) project execution

strategy & process that would facilitate a straightforward implementation

These tool selections do not improve/degrade user/team

experiences of leveraging PPM/iNav for formal time reporting on

projects that are rollups of details kept in more granular project

execution tools

Adoption Strategy & Next Steps

Fully operationalize tools in Q3

– Production environment; backed up and supported

– No charge for current rollout (trying to keep it that way)

– EA & IT Tools Administration eating their own dog food by using tooling

for projects

Early adopters; International has been the most active and is

driving adoption

Work with Security to identify proper tools and update standards

Encourage additional teams to migrate to new tools

Maintain a heat map identifying adoption status by application

31

Maturity & Acceptance of SDLC Tools by Domain

Project Management (Confluence, JIRA, GreenHopper, etc)

– 50 Confluence sites & 24 JIRA projects (not counting TAS environment)

– Investments in Rally by some teams & many others utilizing basic tools

Develop & Build (SVN, Jenkins, Nexus, FishEye, etc)

– Many teams utilizing these original devcentral components

– Way too many teams not using CI and even some teams not using any

formal source code control system

Testing (Zephyr, *Unit, Selenium, JMeter, etc)

– New standards in this space with limited usage

– EA partnering with the QA COE effort to introduce these tools

32

What’s Next for the Smashup?

An action-packed 1 ½ days of great content and great leaders

33

What Happened to Apophis??

We got the right team, we focused on the right problem, we

learned from past mistakes, we used the right process &

tools and we saved the Earth!!

“If there’s hope for humanity, it’s in software.

And it’s equally true that if there’s Hope

for software, it’s in our humanity”

Max Goff

34