Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Pragmatic Agile

No description
by

Rob Saddler

on 27 September 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Pragmatic Agile

what is
agile?

Agile
it represents a constant state
of transformation...
SCRUM
Is a
very
powerful yet deceptively
simple
agile framework
B
usiness
S
oftware
D
evelopment
When I became lead of the BSD team in Swansea University 7 years ago it looked like this:
Preparing for Scrum
It sounds simple!
Why can't you just
do
this?
Pragmatic Agile
Agile is
not
something you
DO

And it's
not
something you
ARE
either

You cannot
tell
a team to
do
agile and expect MAGIC
You can't
spray
Agile on a team and expect results!
So
what
is it then?
A
product owner
creates a prioritised wish list of ideas called a
product backlog
Rob Saddler, Head of Solutions Development & Architecture, Swansea University
"Send them on the training...
... they'll be fine."
"Follow this process...
... you'll be fine."
During
sprint planning
, the team pulls a small section from the top of the wish list, called a
sprint backlog
, and decides how to do that work
The team has a short period of time, called a
sprint
, to complete its work. Everyday, a short meeting, called a
scrum
, is held to assess progress
Along the way, the
scrum master
keeps the team focused on its goal
At the end of the sprint, the work should be ready to hand to a customer or show to a stakeholder
The sprint ends with a
sprint review
to show the work to the customer, followed by a
sprint retrospective
to decide what could be changed to make the next sprint more productive
sprint backlog
As the next sprint begins, the team chooses another section from the top of the product backlog and the cycle repeats
Despite its simplicity, introducing scrum can be deceptively
challenging
Organisational dysfunctions
are the primary inhibitors to successfully introducing scrum
e.g.
1 person
1 project
They scheduled the work
They managed stakeholders
They gathered requirements
They created the solution
They documented it
They tested it
They deployed it
They reviewed it
They trained people to use it
They fixed it
They monitored its usage
They reported on it
And provided indefinite after-care
until it died
They were
NOT
a
but rather, a
collection of co-located individuals
Scrum
COULD NOT
work for them when structured like this as it focuses on
ONE
product per sprint and a
common goal
In a nutshell (groan!)
So what did we do?
The team were suffering from a cultural problem of
work allocation
dysfunction.
Each developer was
siloed
against their own portfolio of products so
couldn't share
any of their work with others.
Every new product they created
increased
their maintenance
burden
and
decreased
their
capacity
to do new work. They had a very low
innovation ratio
.
Developers were contacted directly for changes via email and telephone in
large numbers
.
There was
NO
official
support
function so most days were spent
fire-fighting
.
THEY NEEDED TO BE
UNSILOED
Organisational Patterns to the rescue!
A pattern is a "
recognised solution to a problem in a given context
".
Originated from the work in the 70s of architect and design theorist David Alexander in his book
A Pattern Language
which presented 253 hypotheses of quality about the built world.
Inspired

the
Design Patterns
movement in the 80s led by Kent Beck and Ward Cunnigham for talking about and writing robust software and the subsequent publication of the
Gang of Four
book.
Organisational Patterns
came shortly after and are the same technique but applied to the
relationships
between people and the
way
they work.
These patterns have names to make them easy to identify, rationalise and talk about.
I used some of these patterns to
UNSILO
the team.
Sacrifice One Person
What does it mean?
First, it's not as scary as it sounds! When a team is disrupted by many small distractions, assign
one person
to resolve them all.
How did we do it?
We created a
daily support rota
and assigned a different person to it every day to service all telephone and email requests.
Any issues?
For the first few months, the support developer still had to pull on the relevant technical lead as they learned the new products.
Was this enough?
Improvement
New Challenges
After a few months, team members could
focus exclusively on project work
for 90% of their time without being side swiped
Work requests > 1day were not getting done. Extending the rota period to a week was partially successful but work requests > 1 week were then
backlogging
.
We overcame these challenges with another pattern!
Team Per Task
What does it mean?
This pattern does what it says on the tin. When a team is disrupted by large distractions, appoint a
sub-team
to resolve them.
How did we do it?
Based on the volume of requests, we created a
2 person
sub-team to handle all support requests on a longer term rota of a few
weeks.
Any issues?
Team members didn't want to spend more than a few weeks doing what was perceived as unglamorous work.
Was this enough?
Improvement
New Challenges
The support sub-team
handled all support requests
regardless of size and protected the project team from any
sideswiping
. The team's
innovation ratio
was optimised.
Project developers
still directly received requests
via email and telephone and sometimes found it difficult
not
to action the request themselves, particularly when the requester was
very senior
.
Guess what? There's a pattern for that too! It's called...
Firewalls
What does it mean?
Also known as '
keep the pests away
', this pattern aims to
shield the project team
from unnecessary interaction with external roles.
How did we do it?
We created a shared team mailbox and support telephone number and re-directed any misplaced requests to those areas, re-educating the requester in the process. The team lead fronted all requests for new projects and ensured that all key stakeholders adopted the new communication channels. Project team members could then focus 100% on their project work
uninterrupted
.
Any issues?
Initial resistance from certain requesters but
this subsided over a few months.
Was
this
enough?
The team were then
scrum ready
of becoming
...

it's about
continuous improvement
and
reflective adaptation
...
it's about
EMBRACING CHANGE
The phased delivery of these patterns over a 12-18 month period completely unsiloed everyone
Scrum Down
So, does the introduction of scrum then make everything
perfect
?
Understand the WHY before following the HOW
Adopting the framework blindly without understanding
why
can also lead to failure. When the team understands the philosophy of scrum, identifying
process smells
becomes fairly trivial.
Staying
Agile
Fortunately, avoiding these pitfalls can be quite straightforward using our old friends,
organisational patterns
!
Without this understanding, it would be quite easy to contradict some of the founding principles of scrum and slowly introduce
dysfunction
back into the team.
Pattern
Master
Scrum Master Incognito
What does it mean?
This pattern is required when a team treats the scrum master as their manager by reporting directly to them during the daily scrum.
Why is it required?
Treating the scrum master as the boss
contradicts
some of the critical features of scrum such as
self-organisation
,
co-ownership
and
flat hierarchy
. If left unchecked, this can erode team autonomy and in extreme cases leads to the scrum master influencing estimates and allocating work.
How did we do it?
During stand up everyone reported their progress
against the task board and the scrum master also
ensured that they
broke eye contact
whenever
team members reported directly to them.
Happiness Metric
What does it mean?
During the
scrum retrospective
, find out what
single improvement
would increase the team's happiness the most and agree to implement it in the next sprint.
Why is it required?
The scrum retrospective can generate a large list of ideas for improvement (
OneStepAtATime
!) and it can be difficult to decide what to focus on that will have the most significant benefit.
Other times, team members can be unwilling to 'go first' in making suggestions.
How did we do it?
During the retrospective, each team member rates their happiness of the previous sprint using one of 3 metrics, unhappy, indifferent or happy. A discussion then follows about what
single change
could bring about the
largest increase
in their collective passion
and this is then added to the next sprint backlog as
actual work
.
Patterns all the Way Down
As you can see, patterns feature heavily in the drive to
become
Agile. In fact, scrum itself is just a collection of core patterns that are the
typical
best fit for an
iterative
and
incremental
approach to developing a
complex
product or service which is subject to
requirements volatility
.

Each pattern is a
building block
that helps solves a particular type of problem and fits together easily like lego with other complimentary patterns to form a
framework
.
We used several additional patterns to enhance our use of scrum
Learning More
Organisational Patterns first made
an appearance in
an extraordinarily insightful book written by
James Coplien
and
Neil Harrison
published in 2004.
Don't let the software development title mislead you. This book is
an absolute must
for any serious project manager or team lead looking to understand how to make people as effective as possible in their organisation at delivering
value
.

It has had a
PROFOUND
effect on my professional philosophy.
Scrum PLoP
In 2010, the father of Scrum,
Jeff Sutherland
, established the Scrum PLoP community. Today, the community hosts a repository of all these patterns and
many more
online at:
http://www.scrumplop.org
A pattern language for hyper-productivity
How about Custom Patterns?
Every organisation has it's own unique set of challenges and should augment these patterns with it's own custom patterns.
e.g. Embedding Continuous Learning
It is very easy to get continually caught up in your work and to neglect your own learning. To combat this, the IT department in the University allows everyone free reign to use one morning of the week to learn.

However, this is rarely taken advantage of, especially in project focused teams driven by deadlines.

Therefore, in BSD we created a pattern called:
CPD As Work
Every sprint, each team member
picks a topic
to enhance their professional learning
This should take them no more than
a day
They then treat the learning as
actual work.
It is put on the
sprint backlog
and
must
be delivered by the end of the sprint
They must
demo
what they have learned to the rest of the team during the sprint retrospective
CPD is now an
embedded
part of team culture
One of the most powerful frameworks for working in an agile way however is
Scrum
This could so easily be a talk about how to do scrum...
...but there's
already an abundance
of free material on YouTube
for that
Instead, I will focus on why so
many teams
struggle
to introduce the framework and why their current working
practices and organisational structures
are
impediments
to practising scrum.

But first, an
overview
...
Final Thoughts
Learn to think of
agile
as an
ongoing
approach to address the
specific set of challenges
faced by your organisation in producing value.
Having a
pattern language
makes conversations about these challenges easier.
Whenever you are faced with a classification of problem
predominantly about people
, you not only have a
point of reference
but also a
vocabulary
to explore the options for addressing that challenge in a structured way.
Don't just do
scrum
blindly. Understand it's philosophies first -
understand the
why
.
And that is
PRAGMATIC AGILE
NOT QUITE!
Any Questions?
Rob Saddler
Head of Solutions Development & Architecture
Swansea University
r.m.saddler@swansea.ac.uk
is NOT a
process
, it is a
cultural

mindset...
So many people misunderstand this.

Yes, there are
Agile Frameworks
supported by processes but Agile itself is just a
manifesto
describing a set of
core values
and
12 underpinning principles.
IT Industry > 20 years
Business Risk Consultant for Ernst & Young
Contract Developer for De La Rue - 3 years in Angola
Scrum Alliance Certified Scrum
Product Owner
Open Group Certified TOGAF
Enterprise Architect
APMG Certified
Change Management Practitioner
WRU qualified
rugby coach
UK Athletics qualified
sprint coach
A bit about me...
OR...

...how I used organisational patterns to overcome cultural dysfunctions and enable agility
Applying Patterns
Identify
What is the most dysfunctional part of your organisation?
Find
Which pattern is likely to improve it?
Apply
Implement the chosen pattern.
Measure
Has there been improvement or degradation?
Embed
If there has been improvement, keep the pattern otherwise, undo and try an alternative.
The Meta amongst you will notice that pattern application is itself a pattern... the
Retrospective
!
Full transcript