Rhok 101 for change makers - with an agile flavour

Agile 101 with Caoilte Dunne

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.

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.

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.

The RHoK cadence

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.

Registration LunchIntro and Pitches

Self organise

into teams

Come up with a plan for how to solve the

problem

Build and

iterate

At the hackathonSaturday

Presentation and prizes

Sunday

Build and

iterate

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.

Easy right

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

Well not quiteYou 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.

1) Your vision - keeping it real2) Software - how it is made3) Agile - how it can help4) Common pitfalls - learn from the past

Agenda

Your Vision

You have something you want to do.

This is the “Change” in change maker.

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.

Activity: Your VisionLook 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?”

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.

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

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

What is your focus for the weekend?

Making an MVP?

Lean startup has coined a phrase.

“Minimal viable product”

This the product that can prove something in the real world.

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.

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.

Producing a Demo?

You could be building a demo.

This is something you can show to get finance from the government or crowdsourcing.

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.

Inception Activities

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

Before Info night

Before the weekend

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

Vision is a go

You have your aims and goals.

Between you and meeting them is making software.

Questions about Vision?

Building Software

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.

Lets look at software - what you see

What is built

How you see it

Release /Deployment

What to build

How software is built

Release /DeploymentRequirements

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

Who does what?Release /DeploymentRequirements

Business AnalystsUx’ers (User experience)Visual designersUser Testing

Developers - frontend, backend, app, webQuality Assurance

DevOps: Continuous Integration, Continuous DeploymentAmazon Web Service (cloud computing)

Iteration Manager / Product Manager / Tech Lead

My team (2) - What skills do I need? Release /DeploymentRequirements

A little here Mostly here A little here

One or two from here

When good is done


Time will be short

I advise an agile approach to making software.

What’s Agile? Glad you asked

Each box could takes months.

The want to have everything planned was very strong.

But there were several problem.

15+ years ago …

15+ years ago …

14 years ago ...

We are uncovering better ways of developingsoftware 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 onthe right, we value the items on the left more.

Agile Manifesto (2001)

What does this mean for you?

Software Development Lifecycle (SDLC)

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.

We have to cherry pick the bits of agile that are relevant.

Also you want to be home at some point tonight.

Stories !

Little bits of cstomer value that are testable.

These build together to become your product

Stories !

It is placeholder for a conversation.

It is Testable.It is Completable.It is Prioritizable.

Stories !

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 !

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.


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

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.

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

1) When opening the app I see 7 images with text beneath them2) These images are laid out in a grid-like fashion3) When going back to the app I see the same images in the same

order


This was the hardest story to do

Because it was the first. This was the hardest bit


But remember: When good is done


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

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

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

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

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

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

Tracking user stories

I use a tool called trello for RHoK.

1) It is very lightweight2) It is easily customizable3) It persists across RHoK weekend and rholls.

See your worksheet for the trello URL

Tracking in Trello 1

Your Backlog

What you want to get done In the order you want them done.

Trello


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

Tracking in trello 2

Trello

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.

Standups (cont.)

In a Standup , your team answers 3 questions:

1) What I did do between this Standup and the last standup2) What I am going to do between Standup and the next standup3) Any blockers

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

An example Standup

Exercise: Let’s to write some user stories

Questions about Agile / Stories ?

Roles

There are several roles in agile.

The one that we are interested in is Product Owner.

Vision Keeper

Ultimately Responsible

Change Focused

Sound like anyone you know?

What do you do at the weekend?

Reacting to change, keeping the vision

What you need to do at the weekend


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



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



You need to be clear to you team about what you are expecting to be released

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.

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.

You must be able to weigh the advice of your team

But still make the best decision for your change.

Prioritisation Exercise

Questions about being a product owner?

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.

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.

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.

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?

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.

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.

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”

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.

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).

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.

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.

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.

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

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

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

preparePresentation

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.

That's it !

Rhok 101 for change makers - with an agile flavour

Software

Transcript of Rhok 101 for change makers - with an agile flavour