Pied Piper 2017 - Sprints

We are entering the final stages of the Pied Piper program, the team project. At the end of last years program we run an anonymous survey looking for feedback. A common observation was the lack of team work. Participants got to work on their own personal projects in a competitive fashion but no chance to collaborate and work together. One of the responses in the survey even described this lack as the desire to "experience what working in a start-up feels like"

So for this year we devised a plan. We would spend the last 2 months working together to improve upon the app I developed last year for the presales conference. We generated lots of good ideas about how to improve it during the Hackathon. Modern Agile development use the term "backlog" to refer to this list of features waiting to be implemented.

During the Cloud Native workshop we covered Agile development. There are two main Agile methodologies, Scrum and Kanban:

• Scrum goes through a series of short development periods, typically between 2 and 4 weeks long, starting with a "sprint planning" session and finishing with a "sprint retrospect". During the planning session the team decides what backlog items are going to be tackled during the next sprint. Then during the sprint retrospect the team does a demo and reflects over what worked and what didn't
• Kanban on the other hand has no planning or retrospect. Team members grab backlog items based on how critical they are. This methodology is very prevalent with support teams working on bug fixes.

Both methodologies are widely used but we decided to adopt Scrum, and to adapt it to suit our needs. At the end of the day we all have full-time jobs to attend. In fact the mantra was that we were working on a "part-time start-up". The original plan was to have two and a half months for this phase, however work commitments and other delays left us with just 6 weeks. We decided to do 3 sprints of 2 weeks.

A common routine in Agile methodologies is the daily stand-up. This is a short meeting at the beginning of the day where:

• everybody "stands up"
• each team member briefly describes what they are working on and if they are having any difficulties

Stand-ups are incredibly powerful to hold the team together.

We tried to keep a cadence of a meeting per week:

• a meeting that would serve as the retrospect for one sprint and the planning for the next sprint
• a shorter stand-up where we could review everyone's progress

Even if you haven't heard about Agile, you might have heard the word "MVP", or Minimum Viable Product. This is a development technique that focuses on producing a working product at the end of each sprint. The MVP is shown during the demo at the end of the sprint. This helps to provide feedback and enough capability to retain early adopters. With each sprint more features are added but always end up with a functional product. This is a very powerful concept. In today's fast pace market, focusing on developing working a functional product allows you to start getting value much earlier, to fail fast or to change directions if a better opportunity is identified. The image below illustrates this point.

In terms of tools we decided to use a simple Trello board. Initially we considered using a more sophisticated tools that would allow us to do better planning, but we thought it was an overkill considering how much time we could commit to the project. The following image shows the board half way through one of the sprints:

• The left column contains the overall project backlog. These are the features that are not being worked on as part of this sprint
• The 3 central columns are the current sprint, items that haven't been started yet, items in progress and items completed. Some of these items have a checklist and the person working on it updates the checklist as it completes it. Ideally at the end of the sprint all the items have moved from the left to the completed column on the right
• We used a fifth column on the right as a repository of things that were important to the team like the latest architecture diagram, the latest database schema with comments explaining what each field is for and a place holder for bugs that are identified

Another important tool we needed was a repository for our code that would allow us to collaborate and have version control. We found Bitbucket to be the most affordable private team repository.

Although we had to sacrifice lots of personal time and lots of sleep, it has been a great learning experience. At the beginning we often found ourselves talking like the presales engineers we are, but one thing is to sell the benefit of a solution and a different one is to have to put it together. This has given me a better appreciation for what my customers do and how to better help them in the future.

This is part 4 of a 5 post series about the 2017 Pied Piper program:
1 - Program intro - Must start somewhere
2 - Personal projects
3 - Hackathon
4 - Agile sprints
5 - Tech Summit