In the world of agile, there is theory and then there is practice. We like to talk about self-organizing teams, asynchronous execution, BDD, TDD, and emergent architecture. We also talk about cross-functional teams: how analysts, testers, architects, technical writers, and UX designers belong on the same team, right next to programmers. It all sounds nice in theory, but how does this work in reality? What do these people actually do? How do they interact? What does it look like? Is there really a pragmatic way to make this work? In this simulation, a cross-functional team will actually build a piece of software. Every specialist will have a hand in the process. Every specialist will also act as a generalist. Everyone will add value. And as a team, we’ll get something DONE. This is your opportunity to see agile development in practice, and to bridge the gap between what agilists say and what teams do. And it’s not as new or as difficult as you think – affinity between testers, BA’s, coders, and other team members has really been at the root of effective development practices all along. Let’s just finally acknowledge that it works, demonstrate its capabilities, and encourage it going forward. This IS agile development.

1. Cross-Functional Teams + Emergent Design =
Holistic Product Development
Gary Pedretti, Erik Weber, Pradeepa Narayanaswamy, Dan Piessens

2. Who are we? Gary Pedretti
• Solutions Manager in Centare’s Agile Practice
• 15 years in the software industry with highly cross-functional
experience – DBA, Developer, BA, Application Architect
• Scrum: Development Team member, Scrum Master, Coach,
Certified Scrum Trainer for Scrum.org
• http://blog.GaryPedretti.com/
• Twitter: @GaryPedretti
• http://www.linkedin.com/in/garypedretti
• MCPD 4.0 Web, MCTS 4.0 WCF/Web/Data Access, MCDBA MSSQL 2000, PSM, PSD .NET, PSD Java, CSM, MCPD 3.5 ASP.NET, MCTS 3.5 WCF/ASP.NET/ADO.NET, MCTS SharePoint 2003
Infrastructure, MCPD 2.0 Enterprise, MCTS 2.0 Distributed/Web/Windows, MCSD 1.1, MCAD 1.1, MOUS

3. Who are we? Erik Weber
• Solutions Manager in Centare’s Agile Practice
• Healthcare, Finance, Green Energy
• Huge Conglomerates, Small Employee Owned, Fortune 500
• Scrum Coach & Trainer for Scrum.org
• Passionate about Agile
• Twitter: @ErikJWeber

4. Who are we? Pradeepa Narayanaswamy
• Senior Consultant in Centare’s Agile Practice
• 12 years in the software industry: Programmer, Analyst, Web
Designer, Tester, QAT Lead, Agile Consultant, etc.
• Extremely passionate about Agile
• Specialized in Agile Testing
• LinkedIn: www.linkedin.com/in/pradeepanarayanaswamy/
• Twitter: @nPradeepa

5. Who are we? Dan Piessens
• Staff Consultant for Centare
• Over 12 years of development experience developing and
designing software in agile teams
• Microsoft Patterns & Practices Champion 2008 through 2013
• Twitter: @dpiessens

6. Working Software ASAP, Cross-Functional Teams, Emergence
THE VISION OF AGILE SOFTWARE
DEVELOPMENT

7. What is Agility?
ag·ile ˈajəl, -ˈ
- jī(-ə)l adjective
• 1: marked by ready ability to move with quick
easy grace <an agile dancer>
• 2: having a quick resourceful and adaptable
character <an agile mind>
Synonyms: graceful, featly, feline, gracile, light, light-footed (also light-
foot), lightsome, lissome (also lissom), lithe, lithesome, nimble, spry
http://www.merriam-webster.com/dictionary/agile

8. What is Agility in Software Development?
A group of software development methods based on
iterative and incremental development, where
requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams. It
promotes adaptive planning, evolutionary development
and delivery, a time-boxed iterative approach, and
encourages rapid and flexible response to change.
http://en.wikipedia.org/wiki/Agile_software_development

9. Welcome to 1999!

10. The Gold Standard – Working Software ASAP
• Allows for faster feedback from real end users,
and the ability to respond to that feedback
• Aligns with businesses’ concerns
– They never cared about “done but not tested”
– Must be able to deliver value, earn revenue, etc.
• Eliminates the “80% done” phenomenon
– You’re never sure you’re done until you are done

11. The Gold Standard – Working Software ASAP
Agile Manifesto
• “Working software over comprehensive
documentation”

12. The Gold Standard – Working Software ASAP
The 12 Principles Behind the Manifesto
• “Working software is the primary measure of
progress”
• “Early and continuous delivery of valuable
software”
• “Deliver working software frequently”

13. The Gold Standard – How? Slices, Not Layers
Layers = delayed value Slices = value every Sprint
© 1993 - 2013 Scrum.org, All Rights Reserved

14. What Follows? Cross-Functional Teams
• Whatever skills necessary to complete a slice
• Coders and testers working together
• But also: BAs, UI Designers, UX, Technical
Writers, Ops/Infrastructure, DevOps, etc. – all
working together

15. Cross-Functional Teams
Agile Manifesto
• Individuals and interactions over processes
and tools

16. Cross-Functional Teams
The 12 Principles Behind the Manifesto
• “Business people and developers must work
together daily throughout the project.”

17. Cross-Functional Teams – How?
• An attitude of optimizing for throughput (working
software), not capacity (keeping everyone busy in
their specialty)
• Culture of learning and sharing – moving towards
“generalizing specialists”
• Attitude: “Whatever it takes to get this done”
• Group ownership of product, work, and “done”

18. What Else Follows? Emergence
• Admitting that you cannot or will not have all
of the requirements up front means that you
will learn things along the way
• Requirements, Architecture, UI Design, Tests,
Documentation – all can emerge

19. Emergence
Agile Manifesto
• “Responding to change over following a plan”

20. Emergence
The 12 Principles Behind the Manifesto
• “Welcome changing requirements, even late
in development”
• “The best architectures, requirements, and
designs emerge from self-organizing teams.”

21. Emergence – How?
• An Iteration != Mini-Waterfall
• Asynchronous execution of all development
tasks – no more sequential, phase-gated steps
• Each activity is encouraged to inform the
others
– Testing informs coding, coding informs
architecture, analysis informs testing, etc.

22. Peter DeGrace/Jim Rising – Sashimi Process
http://www.managedmayhem.com/2009/05/06/agile-software-development-process/

23. Scrum.org PSF Course
Requirements
• Non Sequential execution is key Design
• Everyone pitches in regardless of Code
individual skill specialty Test
• The Development Team is held to account as a
unit
© 1993 - 2013 Scrum.org, All Rights Reserved

24. To Do: Validate Credit Card Numbers
I want customers’ credit card numbers to be validated so
that they don't have any surprises when ordering
products.
• We accept MasterCard, Visa, and American Express
• Should validate length of number as 15 digits
• Should validate prefix of number
• This validation should be reusable from other
applications

25. THE TEAM DEMONSTRATION

26. Observations?

27. Observations?
• The team delivered something “done” and shippable!!!
• Requirements changed – sometimes they are wrong! Gasp!
• New requirements were discovered – but thin-slicing and time
pressure resulted in many of them (including the Luhn algorithm)
going to the “To Do” list
• Time pressure forces people to navigate the grey areas to some
reasonable middle ground
– Negotiating requirements – “reusable from other applications”
requirement was negotiated away from a service, and to something
that could be harvested later
– Amount of testing that is reasonable – thinking of testing as risk
management

28. Observations?
Practices:
• Emergent Design/Architecture
• TDD
• BDD Tools (sorry Liz), ATDD (SpecFlow, Gherkin)
• Swarming/Pairing – pairing across
specialties
• Structuring for Testing Pyramid

29. This Happens Without “Role Playing”
• Two-minute video…

30. Enough with the What and the How
HOW ABOUT SOME “WHY?”

31. The Gold Standard – Working Software ASAP –
Why?
• Fast Feedback
– Opportunity to respond
– Validate assumptions, requirements, value – validate learning
• Aligns with business and fosters trust
– Delivers value
– Earns revenue
• Sets an expectation for a single understanding of “done”

32. Cross-Functional Teams – Why?
• It’s how we get to working software, ASAP
• Systems Thinking and optimizing for
throughput, not capacity

33. Emergence – Why?
• Requirements will never be
– known completely
– expressed well
– up-to-date
• “Requirements = Assumptions” – Jeff Gothelf
• We know that we will always learn things along
the way

34. Emergence – Why?
• If you like predictive project plans, I have a guy
for you…

35. Winston Royce Told Us This Was Crazy in 1970!!
Managing the Development of Large Software Systems – Dr. Winston W. Royce

36. And He Told Us This Is Still “Risky and Invites Failure”!!!
Managing the Development of Large Software Systems – Dr. Winston W. Royce

37. And He Said Reality Looked More Like This
Managing the Development of Large Software Systems – Dr. Winston W. Royce

38. Why Not Just Acknowledge This?
http://www.managedmayhem.com/2009/05/06/agile-software-development-process/

39. Do this today!
CALL TO ACTION

40. Let’s Walk It Backwards This Time
• Expect, allow, and foster Emergence
• Build Cross-Functional Teams
• Get Working Software ASAP

41. Expect, Allow, and Foster Emergence
• Communication with the business, requirements, testing, domain
knowledge – learn about Behavior Driven Development (BDD) – Liz
Keogh http://lizkeogh.com/
• Architecture and modeling - http://www.agilemodeling.com/
• User Experience (UX) – Lean UX by
Jeff Gothelf
• Automated deployment, CD, DevOps,
“Production Hygiene” – The Phoenix Project
by Gene Kim

42. Build Cross-Functional Teams
• You’re not pulling people away from their boss or
department to put them in “your area”
• You’re suggesting the company build teams
horizontally across departments, not vertically within
departments
• Focus on “Competencies, not Roles” – Jeff Gothelf
• Just encourage things we already did anyway (Tester
<-> BA and Architect <-> Coder connections, etc.)

43. Build Cross-Functional Teams
Complete Cross-Functionality Condescending Jerks
All Generalists
Pure Teamwork
…at least don’t be a Jerk

44. Get Working Software ASAP
• Challenge yourselves – it can be done…in
30 Days or Less
• Get cross-functional training for patterns
and practices

45. Get Working Software ASAP
• What will the challenges be in your
organization?
• Questions?

46. Thank You!!!
• http://blog.GaryPedretti.com/
• @GaryPedretti
• http://www.linkedin.com/in/garypedretti
• Gary.Pedretti@Centare.com