Services-Oriented Architecture (SOA) provides principles for designing software applications as suites of independently deployable services with a bare minimum of centralized management of these services. Benefits of SOA include the ability to learn/combine/grow/deliver these services to please customers, anticipating failures and handling change. If your organization struggles to deliver fast across multiple teams, fails to anticipate failure or handle rapid change, the 14 principles behind Services Oriented Architecture (SOA) applied to organizations offer a solution. We call this Service Oriented Teams (SOT). In this session we will learn the benefits of modeling your organization in Services Oriented Teams (SOT). This includes improved information flow, ability to expose internal functionality, organizational flexibility, service re-use, lower development and management costs, configuration flexibility. We will do this by applying SOA principles and methods to Agile teams in an all-hands-on-deck workshop, using LEGO®’s as team modeling tools, and SOA methods as teams’ interfaces. Learning Outcomes: In this hands-on workshop, you’ll learn: - an introduction to Services Oriented Architecture and how applying this to organizational design helps to promote high performing, learning and highly effective teams - how SOTs operate as self-orchestrated ecosystems of teams that are, in fact, Complex Adaptive Systems (CAS) the benefits of modeling organizational structure to influence the architectural direction of your product (Conway’s law) - why SOA principles are as relevant for teams as they are for software architecture - how to design organizations to maximize flow of product - with fewer handoffs and better communication - why change management is no longer needed with teams’ ability to adapt “baked in” to the organization - how to define smart team interfaces to accelerate independent delivery - how SOT teams can configure/reconfigure so that other teams are not impacted - how to build teams to promote knowledge, knowledge reuse, and growth - how to focus on the bare minimum of centralized management of SOT. - how investing, nurturing, developing high performing teams is mandatory - when standard patterns for org design should be broken to remove bottlenecks - the benefit of avoiding Conway law silos by organizing teams in service oriented teams responsible for development and delivery

1. Design your agile organization using
(SOA) Service-Oriented Architecture
Principles
Catherine Louis & Raj Mudhar
Agile2016, Atlanta, GA
wtdom.org @rmudhar @catherinelouis

2. Today’s Agenda
1. Introduction - 5 mins
2. WHY SOA for teams - 10 mins
3. How to model video example
and instructions -10 mins
4. Prepare to model (Lego) - 5 mins
5. Model & test round 1 - 15 mins
6. Model & test round 2 (with team
operations) -15 mins
7. Debrief / Discuss -10 mins
8. Close - 5 mins

3. What are your org design challenges?
Introduce yourself to your neighbor
Ask about their challenges building an agile org

4. Common Org Design Challenges
Scarce, rare skills
that have a long
learning curve
Org designed
around
budget vs
customer
need
Product too
big and broad
for full-stack
Scrum teams

5. The DSP Team Story:
https://www.youtube.com/watch?v=iB7JOsSUXO8

6. Are you familiar with SOA?

7. What is SOA?
Services-Oriented Architecture is an architectural style supporting services
using a design approach of scheduled and on-demand requests and responses
for users of the service. A service:
•is self-contained
•is a "black box" to consumers of the service
•might be composed of other services
•has a business need driving it
Service
Consumers
Service
Bus
Config
& Rules
Mgt &
Reporting
Service
I/Fs
Service
Implementation

8. Psst! … (SOT Design Principles are in the
trifold on your table!)

9. Modeling Basics
Identify skills
Compose teams
Annotate your model

10. Common Org Modeling Patterns
FSST
FSST FSST
FSST
Pool
ServiceService
ServiceService
Problem: Not able to demo or deliver
What gets modeled: The Full Stack Scrum Team
Interfaces Primarily with: End users
Problem: Limited, rare experts. Not enough to go around
What gets modeled: A Service team - DSP example
Interfaces primarily with: Other full stack teams, other
service teams
Problem: Not enough work for any single resource on a team
What gets modeled: A specialty pool
Interfaces Full Stack Scrum Teams
Pool Pool
FSST
FSST
CROSS-FUNCTIONAL FULL STACK SCRUM TEAMS
SERVICE-ORIENTED TEAMS
SHARED POOLS
When modeling, consider impacts to flow, trade-offs, costs, and alignment to SOT principles

11. First round of modeling

12. Testing your model
GET PUT
POSTDELETE
GET: How do we get
information
• velocity
• WIP status
PUT: How do we
introduce changes
• backlog order
• story elaboration
DELETE: How do we
something from the
team
• removal of backlog
items
POST: How do we
add something new
• backlog item

13. Second round of modeling

14. Debrief

15. Catherine Louis
cll@cll-group.com
@catherinelouis
Raj Mudhar
rmudhar@deloitte.ca
@rmudhar
wtdom.org