So, I started thinking what if we can take this naturally formed fun process and define a weekly sprint, with a daily standup reporting on the process to achieve the product goal, using a hackathon method.
Day 1 and 2
"How much can you get done in two days for the demo"- This portion is no more than an hour planing. You talk to your team and divide up tasks for the hack you want to demo-in two days. For instance, "Johnny says I'll write the service" and "Amanda says I'll provide the data-it will be in MySQL". Sammy says "I'll write the front end to demo, Johnny let's agree what you'll send me, for now, I will simulate some pho data."
- Then each person builds their part.
- During the process, Johnny is building the interface from an un-authenticated HTTP Get request that has a JSON response to define what his service will return. Amanda finishes the process of testing some queries for functionality she checks in her part of how to get data, massage it and what tables are what, NOT performance.
- Johnny sends a sample interface to Sammy so some dynamic data can be injected into the mockup when Sammy requests data. They agreed that a REST API using GET with a JSON response.
- There are PR requests when sharing the same addition to the same place otherwise frequent merges
- When fixing something that made it into master fix forward so check into master :P
- Each check-in should be filled with a series of TODO, FIXME or "TODO don't do this" statements for speed until that's not needed when you have a refined process.
- Demo
What does the individual developer each get?
Each developer produced something quick to verify the viability of the idea. A vested interest to fix the hacks and beautify the code, reusing reusable parts, etc.
What does the team get?
The team feels that they got something out pretty quick, the team has some talking points of what to fix next and what systems the team envisions that could possibly be used in other parts of the code. Finally, the chance to learn something new in the knowledge transfer or the ability to fix an approach before going too far down the rabbit hole.
Day 3
The next day is mapping out what the developer wants to refactor, has to change and gets to delete. With knowledge transfer of the good, bad, and embarrassing things with an idea of the direction each person took. It is fun.
- This is looking over the queries to make they make sense.
- Are the correct indexes there?
- Are we really answering the correct questions efficiently if not how can we?
- What hacks do we need to undo to provide what we delivered?
- How do I test this thing? I need to make sure before I refactor I have reproducible tests.
Day 4
Document, Test, Refactor agree more as a team and focus on a code structure that enables adding the next round of features while setting standards of the direction going forward or revisiting them if need be.
Day 5
Do more of the same or get a beer with the team.
This process makes me feel that I am building something fast. The reason for the speed was to validate the idea or approach. Time is built into the process for testing, refactoring and documenting. The refactoring takes into account how to add new things faster. 50% building 50% testing, documenting, refactoring, making better. Producing a 4 day work week with daily standups
What about a really big project and delivering constantly
- Whiteboard what is needed to deliver such as what the product is, what does it solve, what are the features.
- Answer what is alpha
- Answer what is beta.
- Divide and conquer the vision for each "hackathon period"
- Adjust projection of delivery based on the previous hackathon progress
- Keep working and visit each hackathon period to verify the correct thing is built correctly.
- Profit from a fun fast paced delivery of code that treats features and delivery of great code the team all validates as equal partners.
No comments:
Post a Comment