This is a quick how to guide to be changemaker for the rhok weekend

1. Agile 101
with Caoilte Dunne

2. So who are you ?
The changemakers !
You are the people who want to leverage RHoK to
make a difference.
Without you there is no RHoK.

3. You are the conduit
All the good done in RHoK , is done through helping
you.
If you do not get what you need , then RHoK has not
done any good.
So we are focused on you getting what you need done
- done.

4. What is RHoK - from your point of view
It’s a series of meetings where you are put in touch
with people with skills in software.
The whole cycle takes place over 6 months.
There is a winter hack and summer hack.

5. The RHoK cadence

6. Meet with
people to
discuss ideas
to help your
solution.
Get people
interested in
your problem
and solution.
Work with your team to enact your
vision.
Ideation Info Night Hack Weekend
Have a vision.
Has to be strong
enough for people
to get emotional
about.
Ready your
pitch. Be able
to sell your
change.
Complete analysis to the
point where your team
can hit the ground
running.

7. Registration LunchIntro and
Pitches
Self
organise
into teams
Come up with a plan
for how to solve the
problem
Build
and
iterate
At the hackathon
Saturday
Presentation
and prizes
Sunday
Build
and
iterate

8. My team (1) - How and when does my team
form ?
Ad hoc-ly !
You might get some interest at Ideation Night, some at
Info night and some on Saturday morning of the
hackday.
You will get a team but the makeup and numbers will
not be known until the Saturday.

9. Easy right
Just turn up, share your passion and good gets done.
With your team ...

10. Well not quite
You need to guide your team.
In a very real sense you need to lead them. To do this
you have to communicate your vision and react to
change on the weekend and overcome some common
mistakes.
It also requires understanding software and how it’s
built.

11. 1) Your vision - keeping it real
2) Software - how it is made
3) Agile - how it can help
4) Common pitfalls - learn from the past
Agenda

12. Your Vision
You have something you want to do.
This is the “Change” in change maker.

13. People and emotions
You need to able to communicate your change in a
way that connects with people.
People are at RHoK because of their emotions. They
are there to help.
You need to be able to quickly and effectively let them
understand why you are at the weekend.

14. Activity: Your Vision
Look to your worksheets
Answer the 3 questions
1. “Why have you chosen to champion your cause?”
2. “What is the best possible experience of someone
using your vision 2 years from now?”
3. “What needs to have been done when your change
leaves RHoK?”

15. You have little time.
1.5 days and some possible RHoLLs every 6 months.
Software takes a long time to build.
So what are you building?
If you have 3 RHoK cycles together you end up with
between about 6 - 7 days of dev per team member.

16. So if you get 8 people in your team that 72 days of effort.
I am in a project now that has 9 people, it has been in
operation for 5 months and is as agile as it can be. That is
900 days of effort.
This is a fairly typical project timeline.
In a year you get max. of 7 days of dev effort
per dev

17. You need to be focused on what you get at
each weekend

18. What is your focus for the weekend?

19. Making an MVP?
Lean startup has coined a phrase.
“Minimal viable product”
This the product that can prove something in the real
world.

20. Making a MVC?
For RHoK it may be better to think of it as MVC -
Minimal Viable Change.
It does not have to be something that is consumed
publicly. It could be something that is consumed by
your org to let them do good with more ease.
It could be a well worked out marketing campaign -
with knowledge of the tools to support.

21. Learning?
You can use the time in RHoK to learn more, so that
you can know what/how to build next time. This allows
you to better understand your market, your problem.

22. Producing a Demo?
You could be building a demo.
This is something you can show to get finance from the
government or crowdsourcing.

23. MVC Demo
Learning
You need to decide what your
vision is what is delivered at the end
of your first weekend
Are you aiming for something that is
useful?
Something that teaches you
something about your problem
domain?
Something that you can show to
illustrate your vision?
It can be all the above. But
remember you have little time.

24. Inception Activities
There are activities that can help you flesh out some
questions about your solution.

25. Before Info night

27. Before the weekend

29. Information about how to find out more
about these these activities is in your
worksheet

30. Vision is a go
You have your aims and goals.
Between you and meeting them is making software.

31. Questions about Vision?

32. Building Software

33. You don’t know how software is built
I don’t know how to help the homeless, or diagnose
autism or whatever else you guys are going to do.
That’s why we have RHoK.
So let’s try and teach you the minimum you need to
know to guide you team.

34. Lets look at software - what you see

35. What is built

36. How you see it
Release
/Deployment

37. What to build

38. How software is built
Release
/Deployment
Requirements

39. There are lots of roles in software development
■ Configuring infrastructure and environments
■ Writing code
■ Testing
■ Graphic design
■ User experience design
■ Business analysis
■ Product management
■ Project management
■ Maintenance

40. Who does what?
Release
/Deployment
Requirements
Business Analysts
Ux’ers (User experience)
Visual designers
User Testing
Developers - frontend,
backend, app, web
Quality Assurance
DevOps:
Continuous Integration,
Continuous Deployment
Amazon Web Service (cloud
computing)
Iteration Manager / Product Manager / Tech Lead

41. My team (2) - What skills do I need?
Release
/DeploymentRequirements
A little here Mostly here A little here
One or two from here

42. When good is done
Release
/DeploymentRequirements

43. Time will be short
I advise an agile approach to making software.

44. What’s Agile? Glad you asked

45. Each box could takes months.
The want to have everything
planned was very strong.
But there were several problem.
15+ years ago …

47. 14 years ago ...

48. We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Agile Manifesto (2001)

49. What does this mean for you?

50. Software Development Lifecycle (SDLC)

52. You are in unusual circumstance
A changing team.
A new team.
You have 2 days to work.
(With possible RHoLLs to follow)
It’s challenging.

53. We have to cherry pick the bits of agile that
are relevant.
Also you want to be home at some point tonight.

54. Stories !
Little bits of cstomer value that are testable.
These build together to become your product

55. Stories !

56. It is placeholder for a conversation.
It is Testable.
It is Completable.
It is Prioritizable.
Stories !

57. Stories are the currency of a product owner.
Before the weekend you will be determining the set of user
stories that make up your minimal viable change.
You will be prioritising them , talking about them with the team.
Stories !

58. User stories are independent of how you
implement them
“As a customer I want see the books I can buy” - User story
This has customer value if it is an app, web site or a demo.

59. Release
/DeploymentRequirements
Allow you talk about
requirements that are
small and achievable
How you devs know
what to build
You should be able
verify the user story
when it is “done”
They flow through the SDLC

60. Some user stories examples
I worked on a project called Benjam in the last couple of RHoK
weekends.
Let's have a look at how its stories worked.

61. As a client I can see a list of things I want
so that I can see what my options are

62. As a client I can see a list of things I want
so that I can see what my options are

63. 1) When opening the app I see 7 images with text beneath them
2) These images are laid out in a grid-like fashion
3) When going back to the app I see the same images in the same
order
As a client I can see a list of things I want
so that I can see what my options are

64. This was the hardest story to do
Because it was the first. This was the hardest bit
Release
/Deployment
Requirements

65. But remember: When good is done
Release
/Deployment
Requirements

66. As a client I can see a list of things I want
so that I can see what my options are

67. As a user I want to be able choose
something from the list I can see so that I
can communicate my need

68. As a client I want to be able to navigate
back to my home page at any time

69. As a carer I want to mark if my client
chose what they wanted so the app can
know if choices are effective

70. As a client I can see my wants categorised
so I can quickly find what I am looking for

71. As a carer I want to add to my clients list
so that the list can easily contain what my
client needs

72. As a client I want to hear my selection so I
can hear the words as I use the tool

73. Tracking user stories
I use a tool called trello for RHoK.
1) It is very lightweight
2) It is easily customizable
3) It persists across RHoK weekend and rholls.
See your worksheet for the trello URL

74. Tracking in Trello 1

75. Your Backlog
What you want to get done
In the order you want them
done.

76. Trello

77. Release
/Deployment
Requirements
Stories have to have
acceptance criteria
and mockups
The devs are given the story (which
includes mocks up and acceptance
criteria. ) The story is discussed at
point of handover with Dev , Change
maker and Qa
The change maker
logs on to non dev
instance to see/verify
the story
Stories flow through the SDLC

78. Tracking in trello 2

79. Trello

80. Trello

81. Standups
When you are tracking your user stories , you can use them to
understand where you team is at.
A meeting to discuss the state of user stories is called a Standup.

82. Standups (cont.)
In a Standup , your team answers 3 questions:
1) What I did do between this Standup and the last standup
2) What I am going to do between Standup and the next standup
3) Any blockers

83. Standups (cont.)
On the hack weekend I would advise a Standup
■ at 12:00 on saturday
■ at 16:00 on saturday
■ at 10:00 on sunday
■ at 14:00 on sunday

84. An example Standup

85. Exercise: Let’s to write some user stories

86. Questions about Agile / Stories ?

87. Roles
There are several roles in agile.
The one that we are interested in is Product Owner.

89. Vision Keeper
Ultimately
Responsible
Change
Focused

90. Sound like anyone you know?

91. What do you do at the weekend?

92. Reacting to change, keeping the vision

93. What you need to do at the weekend
Release
/Deployment
Requirements
This is where the team needs you most. Understanding
what to build , You will be making priorty descsions , and
leverging the skills of your UX’ers and B.As

94. What you need to do at the weekend
Release
/Deployment
Requirements
This is where the team needs to understand what your goal
is at the end of the weekend. You choice will influence the
level of quality produced and what you do with codebase
afterwards

95. What you need to do at the weekend
Release
/Deployment
Requirements
You need to be clear to you team about what you are
expecting to be released

96. My team (3) - What happens when my team
does not gel ?
This might happen. There might be all kinds of interpersonal
reasons.
Normally the accelerated pace of the weekend means that you
can get away with some this.
However the team will look to you to make decision if it clearly
looks like it won’t work. You may have to make some hard calls
but it’s your vision , your team.

97. Prioritization is the most important thing
you do
Things will change!
A new solution might arise.
Something might take a long time.
Something might take a short time.
You might have multiple stories on the go at once.

98. You must be able to weigh the advice of
your team
But still make the best decision for your change.

99. Prioritisation Exercise

100. Questions about being a product owner?

101. What we now know
That software takes time to make so you will need focus.
That thinking of app in stories allows for ease of communication
and prioritisation.
That on the weekend you will be making quick prioritisation
decisions.

102. However...
The best laid plans of mice and men.
I have, in my time with RHoK , seen some common mistakes that
my teams and others have made.
Here are some of these common mistakes.

103. Excitement for participation, not results
Remedy
Be focused on what you can realistically expect in the weekend.
Don’t be overcome by the excitement on saturday morning when
you have a team. The work has only just begun.
Keep calm and have a plan so they can be happy knowing on
sunday afternoon that you have met your expectation for the
weekend.

104. The dominant expert
Remedy
Be careful of the person who has a hammer and sees your project
as a nail. Have suspicion for anyone who can’t work within the
confines of what you have planned.
Use your team for consensus but you are the decision maker.
Will your team after using the experts tool / technique be able
function if they are not in your team tomorrow?

105. The blizzard of solutions
Remedy
Have a plan.
You can incorporate solutions that keep you on track to deliver
but be very careful about solutions that mean you will have half of
what you need.
Be very wary of exciting new analysis techniques that arrive late
on saturday.
Solutions are exciting , deadlines are not. You have both.

106. The inconsistent team
Remedy
Be aware that anybody in your team may not turn up to to the
next event.
The interested dev on ideation may not turn up on the weekend.
The lead dev on Saturday may not turn up on sunday.
You are the only consistent part of your team.

107. Managing your expectation
Remedy
Have a vision for what can be accomplished in a weekend. Keep
you scope small and go in with a plan. This plan will of course
change but as the old saying goes:
“Plans are useless , planning is vital”

108. Production and Reputation
Remedy
If you do put something into production, that’s your reputation.
If this is your goal talk to your team about quality, scalability.

109. No exit strategy
Remedy
Know how your solution leaves RHoK.
Is it because it can now be self funded, it is in production or your
idea has been proven.
There is a future state where the next RHoK will not involve you.
Understand what this is and have a plan to get there within 3
RHoKs (a year).

110. Not getting the skills
Remedy
Sometimes teams don’t get their skills.
The first thing is to be generous if you have too much.
4 Uxer’s is 2 too many, as is 3 managers.
If possible go in with a list or roles you need, that way you can
advertise in your stuff.

111. Too many as bad a too few
Remedy
Aim for your team to be under 10 people.
The makeup of your team depends on your solution and what
availble at the weekend.
As a rule of thumb aim for mostly devs, some UX , some DevOps
and one manager / tech lead.

112. Letting others take the load
Remedy
It is your vision, it is up to you to maintain it.
You should know what your plan is after the weekend.
You need to lead.

113. With our new knowledge let’s go through
the timeline of RHoK again

114. Meet with
people to
discuss ideas
to help your
solution
Get people
interested in
your problem
and solution.
work with your team to enact your
vision.
Ideation Info Night Hack weekend
Have a vision.
Has to strong
enough for people
to get emotional
about
Ready your
pitch. Be able
to sell your
change.
Have done
some inception
activities on
your own
Have done analysis to
the point where your
team can hit the ground
running. have set of
straw man user stories

115. Registration LunchIntro and
Pitches
Self
organise
into teams
Come up with a
plan for how to
solve the problem
Build
and
iterate
At the hackathon
Saturday
Presentation
and prizes
Sunday
Build
and
iterate
Stand up
Stand up Stand up
Stand up
Build
and
iterate
prepare
Presentation

116. Summary
■ It is your Vision.
■ You do the good - everyone else just enables it.
■ You are responsible and accountable for what is
produced.
■ Be thankful to your team, not beholden to them.
■ You're in it for the long haul - your team may not
be.
■ Aim for something useful at the end of the
weekend.

117. That's it !