agile architecture.and.programmanager

The Agile Architect and the Project/Program Manager

Johanna RothmanNew: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects

@johannarothmanwww.jrothman.com

[email protected]

© 2011 Johanna Rothman2

“Isn’t that an oxymoron?”

We need agile architects on programs

We often need agile architects on projects

We use them differently than on serial lifecycle projects

Agile Architect

© 2011 Johanna Rothman

A Program

Organization and coordination of several projects’ results

into one deliverable. That deliverable has the value to the

organization

3


Two Architecture Myths

4

“We can just can churning out features and let the

architecture evolve and never look to the future.”

“We must spend months doing BDUF without proving

any framework with a single feature”

Both lead to architecture debt and technical debt

Both lead to unhappy project and program managers


The Wrong Kind of Architects


Program Management of Concurrent Projects

6


What Do you Need on a Feature Team in a Program?

Enough developers and testers to swarm around a feature

Enough “other” people to finish a feature (writers, BA,

DBA, UX, whatever the product needs)

Architect attention

7


Just-in-Time Architect Attention

Wayfinding: just what is waiting for us out there, anyway?

Scouting: explore potential paths

Architecture spike to answer architectural questions

Vertical prototype: bigger than an XP design spike

8


Agile Business Value Triad

9


Programs Are Riskier Than Projects

You all know that projects don’t scale

The larger and the longer the program, the more risky it is

The more pieces the program has, the more risky it is

Hardware and software

Mechanical and hardware and software

Embedded and hardware and software

Regulated industries

10


Making Risks Transparent

Many people say, “Just do Scrum-of-Scrums”

Scrum-of-Scrums has its place, and it’s not for everyone

Remember

Scrum is not the only agile framework

A Scrum Master is not a project manager

A Scrum Master does not manage technical risks

A Scrum Master is not an architect

11


Issues in Program Management

Especially in concurrent projects, how do you manage, what do you

manage when you have 7, 18, 25 teams of people all working on the

same product?

Backlog management

When to make architecture decisions and perform architecture

work

Managing the risks, up, down, sideways

How to understand and explain status

12


Communication in an Agile Team

13

Communication Paths=(N*N-N)/2

4 people, (16-4)/2=6

5 people, (25-5)/2=10

6 people, (36-6)/2=15

7 people, (49-7)/2=21

8 people, (56-8)/2=24

9 people, (81-9)/2=36

10 people (100-10)/2=45


Communication Problems on a Program

14


Need to Organize as a Program

S-o-S works for small programs, of up to, say, 7 teams. What

about more teams?

There are too many people for a daily standup

Possibly too many risks for the program team to manage

Organize as a program

15


Programs Have Been Around Forever

Whenever you need to integrate deliverables across the

organization, you use program management approaches

Cross-functional team who commits to their

deliverables on a timely basis

Difference is that architects (and architecture) are built

into the teams, not up front

16


One Approach to Programs I’ve Used for Decades (Not Agile)

17


What Agile Architects Might Do

Create Landing Zone with

PPO

Prototype

Wayfind

Roadmap exploration

Architecturally meaty

feature

Prototype

Architecture investigation

Design spike related task

Scout (Design by Walking

Around)

Watch out for debt of all

kinds

....

YMMV18


Example: Landing Zone

Specify and update the landing zone as the feature teams

build features

What do we know more about?

What do the tests tell us about technical debt?

How does the landing zone prevent technical debt?

Do our prototypes tell us anything about the features

and the landing zones?

19


How Do We Manage Architectural Work?

Add to the Program Backlog

Keep a separate architecture backlog

Have a separate architecture kanban

20


Backlog and Architecture Kanban: Realize a Task Needs to Start

21


Work on a Task in Architectural Kanban

22


Architectural Kanban: Finish

23


Feature-itis

Do You Have Feature-itis? blog entry

Requires project/program managers stand up to PO

PMs need nerves and backbones to do their jobs

And make sure you have the conversation nicely

24


Decisions, Decisions, Decisions

25

When to make architectural decisions

When is the most responsible moment?

How long can you wait?

How long should you wait?


What do You Think?

26


Last vs. Most Responsible Moment

27


Typical Product Delivery Mechanism

Cost of delivery or update

User involvement with update

When to make architecture decisions

Software as a Service (SaaS) Negligible 0 As late as responsible

Boxed (Shipped) software Minimal Total As late as responsible

Firmware upgradeable in the field Low to manageable

Minimal Last responsible moment, but not later

Hardware or other difficult-to-upgrade product High Significant

As early as responsible because of program risks (development and

delivery)

Product Delivery and Architecture Decisions


Agile Architects

29

Work across the program

With the program manager and the program product owner

In a large enough program, with a team of architects working

with feature teams, throughout the lifetime of the release

Exploring the possibilities just in front of the feature teams

Their work must be visible, whether it’s in a backlog or a

kanban

Make decisions based on risk


References and Reading

Manage It! and Manage Your Project Portfolio have a number of how-to’s on

programs

Tons more on jrothman.com

If you’d like me to stay in touch with you, please sign up for my email

newsletter on http://www.jrothman.com/pragmaticmanager

I appreciate Hayim for organizing this talk on such short notice.

I appreciate Dima and SAP for letting us use this space. Thank you.

I appreciate all of you for being here! I would love to connect with you on

LinkedIn as a token of my appreciation.

30