A keynote presentation comparing/contrasting old & new SDLC methodologies that was used to kick off an internal agile meetup focused on standardizing on the Atlassian suite of SDLC tools.

1. SDLC Agile Smashup Keynote
Lester Martin, Enterprise Architecture
Sep 24, 2012

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

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

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

5. Software Is Different
5

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

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

8. Grandiose Approach to Software Development
8

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

10. Waterfall – Part Deux
10

11. Waterfall – Change Causes Catastrophe
11

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

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

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

15. Now Everyone Gets It
15

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

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

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

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

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

21. SDLC Reference Model

22. SDLC Components

23. SDLC Components – Project Management Domain

24. SDLC Components – Development & Build Domain

25. SDLC Components – Testing Domain

26. Traceability

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

28. Reference Implementation (Standards) – Visualization

29. Reference Implementation (Standards) – Tabular
Java .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)

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

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

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

33. What’s Next for the Smashup?
An action-packed 1 ½ days of great content and great leaders
33

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