Open Sourcing Project Piper

Organisational change is hard, particularly when the core change you are trying to drive is one of culture and skills. That’s why we developed project Piper. For those that want to run this initiative themselves, this how-to guide will get you started.

Piper Japan

The goal of Piper is to inspire organisational change. It is not the end point, but a way to get teams on a journey that they then self-pursue. For the history of Piper, how we learned from mistakes and how it has evolved, read here. The change we want to create is to have a team that understands innovation in the digital world and equipped to thrive in it.

So, you want to run your own Piper program and need to know where to start. Here’s everything you need to know to get going.

First, you need a team to lead it. There are some critical roles:

  • Someone has to coordinate the scheduling, pre-work, communication and organisation
  • A leader who understands the why, gets transformation and can teach the soft skills side – agile, lean, DevOps
  • A strong technologist who can 1) explain the architecture around cloud-native and microservices 2) lead the hands-on component of getting code from git hub and building software, IoT and other technology components
  • A Support team – people that can help the participants as they get stuck with tutorials

One person could fill all four roles, but typically 3-4 workshop leaders is a good number.

Next, you need to select the first wave of attendees. Find those that are naturally curious, have an interest in doing more and that will likely want to lead the next wave. We typically run workshops for 12-20 attendees at a time. Handpick the first wave from your brightest and most innovative talent that are adaptable to change.

If this is the first time you are running Piper, make it secretive and exclusive. There are two reasons behind this. The first is a principal of not disrupting your core business. See the blog referenced above for more on this topic. The second reason is that there is something cool and interesting about being part of a covert initiative. You want the team to get excited about being selected to be part of something special.

Over time word will creep out. Don’t worry, it’s all part of the plan.

Next, you need to drive logistics – invite the team and have a kickoff call. Explain some background and get the team started on pre work. This can be found here. Give the team at least a month to do pre work. In one Piper program we gave the team 2 months and broke the pre-work into two phases. The goal is to get as much fundamental learning done so the Piper week can focus on what’s most valuable. The pre-work will include python fundamental, setting up cloud accounts, installing some tools, reading a book and readying equipment like laptops and Raspberry Pis.

Also, during the kick-off call explain to the team that this is an optional talent program. They decide if they are in or out. You want people who are self-committed to be part of the program.

You also should book a venue. One core philosophy – if you are going to drive culture change, don’t do it in your own environment. Take the team away. One of the best Piper programs we ran was in a room that we booked at a pub in the centre of Sydney. It was a fun venue. Grungy, but cool. The location and venue will set an identity for the change you are driving. Ideally, think “start-up culture” as you find somewhere. This venue will make up what is referred to in leadership as a sacred place. Where something unique happens.

Make sure you have wireless access, a projector and a whiteboard. You will need plenty of power supplies as everyone brings a laptop. Check that the projection is good quality – you will want attendees to see code.

The dress code for the week should be jeans, t-shirts and hoodies. Most start-ups and modern development teams don’t wear suits! In addition, you need to order the Pied Piper t-shirts. See here for an example. Symbols are important to organisational change. Also, if you can bring something to play music that will help with the vibe (Alexa is a good option).

One idea we are adding is a soft foam microphone which you can see here. These are used during stand-ups in many agile teams. You pass the mic to whoever is speaking.

You will have other preparation to do when you see the pre-work and agenda.

Piper Pre Work

Attendees should use slack to track the progress of pre-work.

Buy or build something that you can use as a Kanban board. Bring sticky notes and markers.

It’s not a bad idea to have a call the week before the Piper workshop to check-in and ensure everyone is ready to go. You should also consider offering help and support with the pre-work. Some of the team may have never written a line of code before.

When it comes to the class itself, we have had a debate as to whether we do more or less focus on coding, versus spending the time on agile and lean. My view is do both, but keep the coding simple. A number of companies have implemented programs to teach everyone in the business coding fundamentals. Rakuten in Japan is one example of this. Even the CEO can code. My view is this is a critical fundamental capability in the digital world, and building code yourself really helps to understand core concepts. But keep it simple. You are not trying to create developers, you are trying to inspire new thinking and understanding of the digital world.

Here is what the Piper workshop typically looks like.

Agenda

Monday

  • have breakfast together (this is an important part of agile)
  • stand-up. Explain what a stand-up is. Get the team on their feet. Start at 9:06
  • Do a quick intro, but launch into code quickly. Get them hands-on fast. The intro should include the need for change and the culture you want to create.
  • Note one approach is to work as individuals, but we are experimenting with the idea of working in pairs under a pair programming model
  • GitHub tutorial and grab the basis for the code that will be used
  • Explain the premise of open source and have attendees open-source hellos world
  • Explain the Kanban board. Start putting activities on the board and using it to drive the workshop.
  • Build a basic app using flask.
  • Go into CF push workshop. Push code to cloud (pivotal web services is best)
  • Show scaling. Add features to app. Explain CI/CD
  • Do a stand-up after lunch. Review
  • Good time now to think about a use case that you will use / business problem to solve. It could be hypothetical, or a real problem. Social problems are good.
  • Teach principals of lean, gathering requirements, agile methodology and DevOps throughout the day
  • Build out personas and workshop working backwards through a business problem. Pick some attendees to pretend to be users.
  • Estimate work for your target project / business problem. Explain Fibonacci numbers. Build out backlog.
  • The goal is to sprint towards an MVP during the week.
  • Showcase moving apps between clouds if you have access to multiple endpoints (e.g. private and public)
  • Infrastructure as code overview and hands-on

Tuesday

  • breakfast together
  • Stand-up. Review at 9:06
  • connect a database to the app (Redis or mongo DB). Do a DB tutorial as part of this
  • Explain microservices and cloud-native architectures.
  • Work through 12 factor apps. Explain the principals as you build them.
  • Docker tutorial and explain containers
  • Amazon EC2 and S3 tutorial
  • Connecting to ECS tutorial (object storage)
  • Kubernetes tutorial on GCP

Tuesday evening: attend a meetup (or another night that works). Good meetups are Docker, DevOps, Kubernetes or something similar.

Wednesday – pivotal labs, or somewhere running agile development

  • Breakfast together
  • Participate in labs stand-up
  • Overview presentation from labs of the methodology and model
  • Participate in the labs tour
  • View CI/CD in action, pair programming and agile in practice
  • Continue on with workshop – finish off modules not completed from day 2
  • Jenkins tutorial
  • Further innovate on the core app

Thursday – IoT

  • breakfast together
  • Stand-up at 9:06
  • raspberry pi tutorial
  • EdgeX foundry tutorial
  • Connect steaming data to cloud app
  • Continue to work on the core app

Friday – emerging technologies

  • breakfast together
  • Stand-up at 9:06
  • AI overview and neural networks
  • Tensor flow hands-on
  • Cloud analytics workshop
  • HDFS with ISILON
  • Finish off app and review
  • Close and explain the next part of Piper – creating your project
  • Now is a good time to reinforce the cascade model of them running the next wave, and ask for a wave leader

Side note to the above: we are experimenting with the idea of breaking the Piper workshop into two parts. Piper foundations will be the first 3 days, and Piper advanced will feature the final two days and the project referenced below. Our thinking is that everyone should do Piper foundations, but not everyone should complete Piper advanced. The advanced module will be reserved for those really willing to commit and wanting to embrace the deeper topics. This also reduces some of the heavy-lift on the pre-work.

You may ask why each day starts at 9:06. This is becoming something of a legend and I am hearing different views (maybe myths) as to why this particular time is used. One perspective was that starting around 9 was optimal for developers giving them time to have breakfast together and arrive at work. But to ensure everyone started exactly on time, the precise time of 9:06 was more likely to send a message not to be late. If a meeting starts at 9, a few minutes late is often acceptable. But if you know the start time is 9:06, it’s exact. There’s no wiggle room.

The second myth I have heard is that this originated at google and that the furthest two points on the campus take no more than 6 minutes to reach. Therefore, if working hours start at 9 and the stand-up starts at 9:06, there is no reason to be late.

Whatever the truth behind the story, the legend has stuck and this is how many agile teams operate today.

The final phase of Piper is to have the team build out their project. Usually 6 weeks is given to complete this project. In our experience, some team members will not pursue the project, some will put in minimal effort and some will do amazing things. Out of this we usually find 3 top winners to showcase and use a points-based system to help score. One point is used for each different cloud service or technology used, along with bonus points for creativity and innovation. Some examples of the top projects are:

  • mini indoor automated farm
  • Image recognition for security
  • Connected coffee: automating coffee making system

At the 6 week point a review call is had to showcase the projects. The top 3 are presented to senior leaders and awarded a prize.

Finally, ensure the team picks a date for the next program and begins to run it. If they were truly motivated by the program, likely a few key people will step up and own it without needing you to be involved. As a leader, this is a good time to step back. As the waves evolve you may have to drop in from time to time to help steer the program, but the more you can get the team to run it and evolve the program. In our program, over time the team added awesome new modules, but rotated more into software development and away from the culture and process change that was meant to be a core part of the program.

Is Piper the answer to all digital hopes and prayers… yes. But not in isolation. In my experience it is the best way to kick start change. It’s a way to open the door, but up to the team to then walk through it.

Some leaders may take a more top-down “driven” approach to change, but my view is this bottom-up inspire approach is more lasting. Culture is deep-rooted and challenging to change. This is one way we have succeeded in changing it.

What happens after Piper from our observation is that a number of people become change agents. They won’t know everything at that point, there is no way a week-long program can give them everything. But they begin their journey. We see the emergence of “curious minds” from this program, those that then immerse themselves into a world of learning in a field they previously knew nothing about. They then inspire change in others and set about sharing what they have learned with the 60% of the organisation that is sitting on the fence.

The foundations and tools to lead your own Piper program can be found on GitHub here. You will need at least one person who understands the tools, technologies and methodologies to get started. If you do create your own, consider making it your own. You may come up with different themes, symbols and methodologies. If you do, I would love to hear about it.

Find piper on GitHub:

Piper 1

Piper 2

Piper 3

Piper 4

#IWork4Dell