Retrospection about a killer project

TAG:

In 2013, for two months I was involved on a killer project. An amazing team came together in one day to work on a rescue project. The team delivered timely and exceeding expectations. It was composed by 6 developers, one tester, one PO, one architect, and one  facilitator (overlooking analysis, communication, project, and process). Here are my notes about this short and successful project.

 

No process upfront

The project started with no process. Really, no predefined process! On day one, the team decided to have a recurring meeting. Soon it became more like a daily showcase. Later on, the team would do a quick stand up prior to the daily showcase.

On week two the team decided to do a retrospective. Planning or re-planning meetings happened on a weekly basis after the second week.

 

Tiny stories

Our Stories (or tasks) were small enough to showcase a few of those every day. They were not INVEST by no means. Some were dependent; many were more technical than pure business stories. But all come along together and made sense. And this happened daily! None of these tiny stories/tasks took more than 3 days. One day was the typical time it took.

 

Daily showcases

Although this was not planned, it started happening from day 2 to the last day of the project. A showcase was done every day in the afternoon.

Everyone would watch the latest working code demo; being it a complete business feature, or a piece of working code towards that direction.

 

 Two stand ups

The team did stand up (a quick sync up) twice a day. In the morning at 10 am, and at the afternoon, right before the daily showcase. It started with showcase, then stand up and showcase, then morning stand up, afternoon quick sync up, followed by a showcase.

 

Feature wall

The team used a feature wall.  On a whiteboard, the main features were stated as columns. Related tasks were listed under each feature. Towards the top was the leading ones (priority or dependent upon). Cards would not move on the wall. Dots were used to identify what was being worked on and what was done.

 

Conversations over everything else

The daily showcase was a perfect venue for all conversations related to the product. This simplified the need for detailing requirements, and for going further in any direction which was not desired.

The team did not have a rigid predefined process, nor a detailed story backlog. Conversation was the norm. The daily showcase and fast development cycle created a perfect communication channel, avoiding misunderstandings or pre-emptive communication (anything prior to the real work being demosntrated).

 

Continuous Delivery

The engineers decided to have a CI server working on day 1. Daily showcase was done on a production-like environment. Later, this production-like environment became the production environment. Early on the project lifecycle, the team was doing Continuous Delivery, the software delivery practice that foster faster and frequent deliverable.

 

Testing

Although everyone on the team comes from a culture of highly automated testing and TDD, the project started without it. Remember, there was no predefined process. Interesting enough, these practices were being added as the project evolved. The pain brought these practices into the picture. There was no debate like: should I test this or not. Once there was pain, tests were added. By pain, I mean two or more people working on the same code (therefore being unconformable with changes), or a bug (write the test, then fix it!).

 

MVP

Many, many times the team would decide to have the simplest solution before moving towards something more elaborated. And this was the case for technology and business solutions. The product did build up to have an an awesome great list of complete features. It was very interesting to watch how the team MVPed towards it.

 

Amazing people

Any and each of the things listed here worked for this group of amazing people. To be very honest, I don’t recommend repeating any practice alone. My suggestion is to work with awesome people, open up an effective communication channel, start simple and continuously improve it.

 

Please find below a few photos for this killer project.

 

Continuous Integration from day1

Feature wall

 

project retrospective

 

Paulo Caroli

Paulo Caroli is an author, speaker, and consultant specializing in agile transformations, Lean Inception, and OKRs. With over 30 years of experience—including nearly a decade in Silicon Valley and 18 years at ThoughtWorks—he has helped organizations transition from project to product and from strategy to execution. Creator of the Lean Inception methodology and author of bestselling books like Lean Inception and Team OKR, Paulo is dedicated to empowering teams to align, validate, and deliver real business value.
Triple Track Development: Business Innovation Through Continuous Discovery and Continuous Delivery

Triple Track Development: Business Innovation Through Continuous Discovery and Continuous Delivery

Continuous Triple Track Development, comprising Business Strategy, Discovery, and Delivery, revolutionizes product development. Quarterly goals replace yearly plans, ensuring adaptability. Continuous Discovery delves deep into user needs, while Continuous Delivery swiftly transforms validated ideas into products. This synchronized approach fosters unprecedented collaboration, propelling teams towards collective success. It’s not just a methodology; it’s a strategic advantage, enabling businesses to innovate rapidly in today’s dynamic market.

read more
New Book Alert: How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas

New Book Alert: How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas

Introducing our enhanced book, “How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas.” Evolving from its predecessor, this edition responds to valuable reader feedback, refining both content and title. Delve into the world of effective product development and user story management, discovering the integrated power of the PBB Canvas. Embrace an enriched reading experience and explore insights from thought leader Jeff Gothelf in the preface. Don’t miss a reader’s insightful review, preserved for wider readership. Join us on this journey of empowering user story craftsmanship, and witness the transformation of your product development goals.

read more
Product thinking strategy questionnaire

Product thinking strategy questionnaire

The questionnaire below elaborates on a few important aspects of product thinking, problem understanding, solutioning and strategic delivery planning.   I have used this questionnaire as part of a workshop on Product Leadership and Strategic Alignment. Basically,...

read more

Pin It on Pinterest