The Lean Startup – joining up the pieces

What a relief to find this book. It’s already beginning to tie up a few concepts I’ve heard over the years and make them form a better picture of what’s been going on in the Tech / Startup industry.

The Lean Startup

It was Jamie King who mentioned it at Games for Health Conference UK 2016 in Coventry, and since purchasing it, the book has been a welcome companion on my daily travels.

It talks of reducing waste and validating assumptions. It talks of validated learning and not just saying, “we’ve all learnt a lesson” and moving on to make the same mistakes again. It talks about making experiments part of the fabric of your work and making things which fail but validate assumptions on your vision and helps you move along.

By doing experiments, like split tests on your site or bootstrapping business ideas, you learn about your visions cheaply, and reduce waste.

It’s so like Agile development, but for your business ideas.

We’re ignoring our stakeholders and they couldn’t be happier!

The following is a set of techniques that at WMG, Warwick University I have led and implemented on various digital projects to great success. Stakeholders are happy with it, and they’re not inadvertently altering the success chance of the projects.

You’ll recognise this. Every project you run, has a plethora of stakeholders involved. In some large organisations too, you’ll find they enjoy a rather flat structure where everyone’s opinion is valid and should be considered.

So when you invite lots of people to a meeting, you come out with a mess of features and a confusing array of project actions which possibly didn’t need chasing up. Because of this we need a framework that will allow for ideas from all people, but only qualify the ones which are “goers”.

Here’s 4 tips that I use with my teams at WMG to both keep the stakeholders happy. It makes but the project the most important success factor, not egos. It makes everyone nearly equal.

1. Have a shared Product Backlog or the “the duff idea buffer”

Headline.
This is a place where all ideas are held and are accessible to every stakeholder. This isn’t an obtuse Word Document you keep emailing round with “Track changes on” and forgetting to CC (Carbon Copy) people in, but more like a shared pinboard on Trello.com which you can export every so often to Excel.

Reasoning.
The reason for having a shared Product Backlog is more to do with human behaviour than anything else. Often in a working group of many, you’ll find most of the angst is whether or not someone’s personal idea was set down and recorded. Some / most of the suggestions will be pants, off-topic and not worth the keystrokes you took to record it, that’s natural, we all do it.

However, if it’s fairly recorded somewhere you can move on, rather than discussing its use-fullness there and then.

Often you’ll find that the person who raised it, after a couple of days, gets some perspective and realises they don’t think the idea’s any good anymore.

1. Have a Product Owner (the gatekeeper)

Headline.
This is 1 person. Not two, three or 12. Just 1. It is 1 person who was voted by the stakeholders as the “best decision maker for the project” and who always decides what’s the most important action for the project next.

Reasoning.
So sure, the stakeholders have now had their thoughts recorded into the backlog, but let’s be honest, quite a lot of that might not be immediately urgent or produce the highest business value. So a Product Owner is voted in by the stakeholders as the person best placed for making decisions on the product.

They have authority. They were voted in by their peers, and so can yay or ney actions confidently. Also, if you’re worried about someone being voted in that’s a bit power hungry, it’s good to know that this role has a lot of responsibility, so their decisions have to be good, they’re picking how the project progresses.

3. Be strict.

Yup. They’ll hate this bit, but you need to vote in someone who can stick to these rules and keep to the rhetoric of, “Great idea, put it in the Backlog”, “You don’t get to pick, it’s the Product Owner’s choice”.

This way, no stakeholders can adjust how the project goes as they agree to the rules of the Product Owner says what’s next. By staying strict it helps fight the “culture eats process for breakfast” saying and starts adjusting how you work together.

4. Keep everyone updated, frequently

Every 2 weeks, re-present to the stakeholders what’s done so far. Then chat about what they think is important next. Invite them all every time, and after a while you’ll see they more just want to leave you to your work and don’t turn up. Allowing the process to move on.

The Product Owner can then make the decisions based on feedback about what’s next.

I hope that helps!

Note…. In the title, I mean, “happier” with our process, I imagine their first child or standing on a surfboard might also be a happy event.

 

Agile Release Management Training.

Just a note of my training this afternoon.

We looked at Epics and Adventures and how they sit in the overall weekly Scrum planning, Backlog Grooming and Release planning.

We looked at Roles and Responsibilities within a FULL company setup, past and further than just the Scrum team.

I was told about a new role in an Agile software team which is solely to do with Documentation!

We looked at the challenges of change management and “Culture eats process for Breakfast” so people management is very important with change.

From this I have created our own Agile Project Initiation Document (to only approve high value projects), a Roles table for every project (who is what) and a Responsibility table (who does what)

State of the union (since starting at Warwick Uni)

A small state of the union post so I don’t forget my journey so far…

The largest change is introducing my Agile experience into many aspects of workflow and to many members of staff.

Agile Training
* I have delivered three separate sets of Agile training
* Once for the Project Management Networking Group
* Once for the WMG IT team
* Once for an individual member of staff

I have introduced some better online tools to support the University’s work
* Trello – The whole IT team use it now to track and collaborate on their work
* Quickcast – The use of screen casting to show staff how to use certain material
* Continuous Integration – GitLab’s CI runner Is now provided by the University following me pushing for access
* Google analytics – To prove that students are using more of their own devices which are Apple based, than the university owned Windows machines
* Twitter Bootstrap must be used across all our custom apps. Our custom built apps from externals had custom CSS wrappers, but now use Twitter bootstrap 3.

Methods of working
* A lot of the Moodle work is “Handle turning”, I have floated the idea of an apprentice, which has led to a summer intern coming in (got ahead of myself, summer interns are always here!)
* IT partners – Following the Agile training, the following ideas of roles and responsibilities of a Product Owner leading and ordering tasks in priorities was taken on for our WMG IT partners
* We use an Agile approach to define what work should be done next. “If it went live tomorrow, what would we need?”

Development Bootstrap
* Deployment
* Folder organistion
* Server registration
* Repository Model
* Interfaces
* Behaviour Driven Development testing
* Unit testing

University Wide
* One of my three University wide ideas has gone onto review stage, using rechargeable mics for presenting will save on batteries and reduce support calls

Projects
* Biddr – an online reverse auction. I coached Agile to the staff and also built this learning tool in Laravel 4.
* Gradr – an online app to consolidate marks from multiple modules into one simple dashboard. It provides students a single overview and tutors an overall table of their students marks. I coached the staff in Agile and also built this in Laravel 5.
NEXT!

  • More Project management
  • More Laravel 5 and Elastic Search
  • Improving the University’s IT network (of people, not wires)
  • More training, hopefully in leadership (it’s different here to a small self-owned company!)

Should you allow clients into your bug tracking software?

I believe yes, you should. With the proper caveats and training, your client should be able to see what’s going on.

The client has fewer surprises, is in on the problems and #FTW’s. They feel more connected to the product and weirdly will start to feel more “onside”.

Sure it might seem scary at first, but after the initial storming, the process does begin forming!

It’s all about improving process through transparency.

Present development work without a live server

So on the Agile Development project I’m running we don’t have a feature to sort out a live or testing server yet. In fact that might still be a couple of weeks off.

So how do you show your work off earlier for quality assurance before you have a server?

We’ve found at the University of Warwick you can present your work with quick screencasts, something offered by Quickcast (http://quickcast.io)

 

Quickcast video

Then link it up in the Trello ticket and get the client to QA based on what they see. That means we can delay the need for a server feature until we really really have to.

Also, a video means with a remote client they get to see your face on occasion!

 

 

Mixing the Backlog and Sprint board together… gulp!

I’m trialling a new version of an Agile board for longer running projects. Ones that don’t have masses of tickets and set defined sprints, but are more on-going support work.

Because, normally I keep a separate backlog board with any number of columns, (whatever the Product Owner feels is easier). And then we create a board per. Sprint with these headings.

Sprint:

  • Iteration Contenders
  • Backlog
  • Blocked
  • In Progress
  • QA Failed
  • QA
  • Done

But trialling the new type, it will be,

Support Board:

  • Wishlist
  • Scheduled
  • Blocked
  • Doing
  • Done

This will be easier for the staff to interpret as their exposure to Agile so far has been understandably minimal. Also, we will require fewer boards as there’s less work.