February’s meeting was based on the theme “Getting the Business Involved” and followed a different format to usual, (closely aligned to Open Space) where the attendees were invited to write the topics of conversation they’d like to have during the meeting. A number of topics were identified with the group then we prioritised the topics of conversations through a simple voting process. The topics that came to the top of the list were: 1. What are they getting involved in with Scrum? Value For Money? Successful Delivery? 2. What happens when stakeholders don’t get involved? 3. What do we (software teams) do when we know more about the business than the business?

1. Agile:MK December 2012
Journal
February 2013
ISSUE 03
A special interest group for
professionals from the Milton
Keynes area who are interested in
learning, sharing and encouraging
the use of agile methodologies such
as Scrum, Extreme Programming &
Lean Thinking.
Agile:
“Writing Good
Requirements”
Open Space Session
Monday 26th March 2013
6pm – 8pm
Sponsored by

2. Agile:MK Journal
February 2013 Agile:MK User Group
Welcome to the February edition of the
Agile:MK Journal. The Agile User Group in
Milton Keynes meets once a month to share
and learn about agile methods through
real-world experiences. Each month we’ll
Steve Garnett publish a brief overview of the discussions
Founder Agile:MK
and insights of the group in this journal.
To register your interest, If you’d like to join the group so you can
please join the attend, the sessions, and be involved in the
LinkedIn Group at
http://tinyurl.com/ discussions face to face, to learn or share
agile-mk-liug your experiences, please join us on LinkedIn.
Agile:
“Writing Good Requirements”
Open space discussion workshop
Monday 26th March 2013
Jurys Inn Hotel, Midsummer
Boulevard, Milton Keynes, MK9 2HP
Agile:MK Journal,
design & produced by endjin
www.endjin.com

3. December 2012
Getting The you have implemented is the
‘actual’ Scrum is an insignificant
At the other end of the spectrum,
an equally suitable approach might
Business Involved question when considered next not be to mention agile at all, and
to the question “Is your software rather, fix the problems the business
February’s meeting was based on development team delivering is experiencing using agile methods
the theme “Getting the Business everything your business needs and patterns but not necessarily
Involved” and followed a different to succeed?” explicitly talking about Agile –
format to usual, (closely aligned to rather talk about solving problems.
Open Space) where the attendees I.e. Its more important to measure
were invited to write the topics of business delivery and success, Regardless, of the approach or
conversation they’d like to have than to measure how well you are tactics in use, we identified some
during the meeting. implementing your methodology. key points when looking to change
the way things are being done:
A number of topics were identified
with the group then we prioritised
Topic 1: What are • The importance of involving
the topics of conversations the business getting the customer and getting
through a simple voting process. iterative feedback is immense
The topics that came to the top of
involved in with Scrum?
the list were: • Adopting more disciplined
engineering practices is
1. What are they getting involved essential if adopting Scrum
in with Scrum? Value For Money?
Successful Delivery? • It is all about people, so think
about the individual
2. What happens when stakeholders stakeholders, the organisational
don’t get involved? culture and thecompany’s
attitude to change – when has
3. What do we (software teams) do the company been successful
when we know more about the in adopting change in the past,
business than the business? what made it successful? What
can you learn from this?
Before we started discussing these
prioritised topics, the food arrived • Learn to think about the concerns
and an informal discussion kicked- and language of others and
Change… If the business you work
off about the nature of Scrum use the things that they are
in is adopting Agile or Scrum, then
concerned about to effect
it is embarking on a continuous
change. Are the board concerned
Scrum improvement initiative with frequent
with speed to market? Quality?
Scrum is a simple method, there feedback loops and measurement.
Transparency? Risk? Understand
is not much to it. Scrum is not the
these drivers, and then implement
goal of teams adopting the Scrum For the CIO or key sponsor there
changes that improve the state of
method, business agility is the goal. is a level of risk in terms of both
these drivers.
Adopting Scrum is a journey and business risk and political position
should therefore not be seen as due to the need for budget
All companies are unique, all
a quick fix, it is about continuous expenditure and the normal impact
companies have unique people,
change and its likely the easy stuff of change – uncertainty & fear.
and so understanding their context,
will change quickly and the harder There are a number of tactics for
their needs, their drivers and their
stuff will take much longer. effecting agile change which we
propensity for change will help
discussed at length. At one end
you to shape a successful change
There is a risk that some people will of the spectrum is to go for the
project that helps the company
get ‘hung-up’ on the labels when full-on formal and strategic
to improve at a sustainable pace.
the thing to remember is that if communication of Agile adoption.
things are being built well, and I.e. The programme is likely to be
delivered on-time for the needs formed as in individual project in
of the business, then the software its own right and called an Agile
team is doing its job effectively. Change Programme.
Worrying about whether the Scrum

4. Agile:MK Journal
Topic 2: What Happens it turned out this was not far away topic around what happens when
from the truth. The discussion you don’t involve stakeholders
when Stakeholders was based around a Utilities and cross-checked to see how
don’t get Involved? company. The company has a many of the negative outcomes
‘New Customer’ on-boarding were relevant for this real-world
process that involves at least 20 example…
• Rework
different information flows.
• Deliver the All the items with a tick against
Wrong Thing* Because these information flows them have been experienced by
• Get Sacked were automated, a vast amount of this project because it did not
• Legal Action knowledge of how this business fully get the business involved,
process worked was held within and this was a stark reminder
• Brand Devaluation
the IT department and the business of the importance of business
or Damage assumed that IT understood the collaboration on software projects.
• Increased Cost* process completely.
• Increased Risk User Group Backlog
• Time Over-run* When it came to upgrading the
process, the IT Architect was
• Demoralised Team
positioned to define the
• Loss of requirements on behalf of the
Stakeholder Value business. The result was that
some of the business needs
The conversation started by creating were missed and this has led
a list of the possible impact of not to a very long stabilisation period
getting stakeholders involved in of c10 months.
the software development process.
What was more interesting for this
What was quite revealing for scenario was that sprint reviews
most people in the room was were taking place and as we delved
the severity of the list, highlighting At the end of the session we
deeper into the conversation, the
just how important it is to ensure discussed the format of using open
question came back to getting the
stakeholders are engaged space for discussions and agreed it’s
business involved i.e. were the
in the process. a good format to ensure everyone
correct people involved, did they
gets something from the session.
have the right level of interest.
The group went on to highlight 3 We then voted on the topics for
particular areas (red asterisk) which future sessions, and as you’ll see,
are very common problems. These ü Rework next month’s theme will be Writing
Good Requirements.
problems are overcome by using
key elements of Scrum i.e. fixing
ü Deliver the
Wrong Thing* Next Meeting
cost or time but keeping scope
variable, creating short feedback ü Sacked
Get Tuesday 26th March 6pm-8pm
cycles, building cooperation, varying
features based on feedback and Legal Action Jurys Inn Hotel, Midsummer
ultimately getting the stakeholders ü Brand Devaluation Boulevard, central Milton Keynes.
actively engaged and involved. or Damage
Theme
Topic 3: What do we
ü Increased Cost* “Writing Good Requirements”.
(software teams) do
ü Increased Risk
when we know more
ü Over-run*
Time
about the business
ü Demoralised Team
Loss of
than the business? Stakeholder Value
Screw-up! Was my first thought We then did an exercise where we
in answering this question, and as took the output from the previous

5. Agile: MK Bookshop December 2012
The Great Game of Business
by Jack Stack
An old boss of mine introduced this book to me. He is a serial
entrepreneur and millionaire within the Direct Response TV
industry. When I worked for him as a CIO I had a direct correlation
of bottom line figures to IT performance, I understood the line
items I affected and could see the direct results of my actions
and decisions and those of my team. This book tells a great story
of a manufacturing company in dire straits that ‘opened it books’
to the workforce and got everyone to understand the impact of
their actions and decisions on the success of the company and
ultimately on the future of their own employment. Adopting
the Open book management approach would strengthen many
companies in the UK
Organizational Patterns of Lean Start-up Machine that Changed the World
Agile Software Development by Eric Ries by Womack Jones & Roos
by Coplien & Harrison
Extreme Programming Explained Lean Software Development Specification by Example
by Kent Beck with Cynthia Andres by Mary Poppendieck & Tom Poppendieck by Gojko Adzic

6. ripplerock offers a set of services and tools that enable our customers
to dramatically improve their software development capability
RippleRock formed in 2009 with the mission to assist customers drive dramatic improvements in their software development
capability. We apply our expertise across the full lifecycle; facilitating organisational transformation to enable Agile practices,
all the way down to improving engineering practices within the teams.
The team at RippleRock have a strong track record in the Agile space, some of this through experience gained while at the
centre of Conchango’s Agile Practice and Scrum for Team System tools group. As a specialist in this area we are able to offer
access to the most experienced Agile coaches, trainers and consultants with the particular mix of skills required to work with
people, process, organisations and tools.
Ripple Rock Ltd is registered in England and Wales No. 0708916
Ripple Rock LLC is registered in the United States of America. No. 27-1180168 www.ripple-rock.com