Writing

The very first thing it is important to know is that agile is not a religion. A lot of people and consultants treat it as such. In my experience, it’s better to treat it as a set of tools you can use to optimize your development process. 

It’s my opinion that these days, technical risk is no longer the biggest risk in software businesses, it’s the market risk (acquiring and retaining customers) that is the biggest. Using agile is a simple way to diminish technical risk even further and give you a slight edge on managing market risk by baking in the ability to change software as the market changes.

This document will outline a set of tools to help set a foundation for working optimally. It is my opinion that you stick to this process in a rather strict manner for the first 3-4 weeks in order to work out kinks and understand what really doesn’t work vs what you were just getting used to. Feel free to share this with the developers on your team and solicit their feedback.

Take some time to review this list: https://en.wikipedia.org/wiki/Agile_software_development#Agile_software_development_principles

Again, agile is meant as a set of tools. So not all of those principles necessarily apply to your company or process. However they are informative, I’ll go over the ones I believe to be the most important at the outset of creating a greenfield project:

A lot of software developers grow attached to their code, because they created it. Unfortunately, this is not ideal for dealing with market changes or even simple requirement changes. It’s important that developers on the team have a mindset that anything and everything can be thrown away if we do not need it anymore. Beyond this basic truth, you need to have a frictionless way for changing requirements to stream in for consideration and adoption. This is why a visual control system like Jira or Clubhouse is so important, they allow for changes to get queued up. It’s also why backlog grooming is important, it allows for the most important changes to be adopted. Lastly, It’s also why timeboxed cycles are important, they allow for changes to actually get adopted.

This is a straightforward principle, but this doesn’t happen if the expectation is not clear. You should communicate with your developers that you expect to see software that has been improved at the end of every single sprint or if you ever adopt Kanban, every single day. This is also why I recommend a 1 week sprint length to start.

A lot of business people or stakeholders as some people call them often try to shy away from communicating regularly with the development team until the product is “ready”. This is a big mistake in my opinion - there should be a single stakeholder or stakeholder representative always present at daily standups and retro’s. It’s important that when you attend these short 5-10 minute meetings, you do not derail them with vision discussions, customer requests, etc. Simply observe & when necessary, mention that the priorities are not quite reflecting what was agreed upon during backlog grooming.

The sustainable development principle is ridiculously important for new teams, because they’re often running as fast as they can towards a v1 or v2 product. I find that it tends to be best when you take the time to find out what your team’s velocity is and try to improve 5-10% in 3-4 week increments. This helps to ensure team productivity is rising while not putting too much pressure on them.

This is probably my favorite principle from the original twelve, because it gives everyone the opportunity to grow. You can read more on retro’s below.

What follows is a guide for you to get started. After you’ve given this process the old college try, be sure to reflect on what is working and go from there.

1. Timebox / Sprint length - I recommend you start with a tight timebox, specifically 1 week sprints, so you can get an intuition of what your team can accomplish in a week. 2 weeks is fine too, but IMO it’s better to start with shorter sprints.

2. Board setup - Board setup is pretty crucial. I recommend you go with the following column setup, with work-in-progress limits of about 5 tickets per column and a fibonacci story scoring system. You should have a scoring session with or after each backlog grooming session that includes your developers. This step is crucial because it allows you to observe your team velocity after 3-4 weeks. This should REALLY be integrated with GitHub, more on that below.

Backlog - This is just a wishlist, there might be junk here, which is why we have a backlog grooming in the first place. We want to remove expired / irrelevant stories from this column ASAP. It's also where work comes from - Stakeholders bka “business people” should be regularly adding stories here. During grooming sessions, you will also be deciding what gets moved into "Ready for development" and scored as well as what gets removed

Ready for development - This is what will be worked on by developers, these tickets should be well fleshed out with descriptions and points. Developers can take any ticket from here and start work on it. Please note that these are prioritized, but the priority is a suggestion not a guideline

In development - Developers should assign themselves to a ticket when they move it to this status, it means that they're actively working on it. They should also have a branch from master that follows the format YC-[story-id]-[short-description], so for instance, this story: https://yourco.atlassian.net/browse/YC-3432 would have a branch called YC-3432-add-customer-login. If a dev has a question that needs clarification, it should be posted on the ticket. This is why you should set up GitHub integration, it allows for maximum transparency into work being completed.

Furthermore, please include in each commit the ticket number in this format: YC-3432, so if I just added tests in a commit, the message would be: git commit -a "YC-3432 Adding tests for model".

Ready for review - Once a developer has completed the story with its associated tests, they should open a Pull Request on GitHub, that should automatically move the story into this column (if you integrate with GitHub). At this step, some other technically inclined person should be extensively reviewing the PR, looking for tests, pulling it down and running it locally then offering feedback on how to improve it. Every single PR should have a second pair of eyes on it.

Ideally, every single PR will kick off a test build AND a staging build so it’s easy for stakeholders to review the work completed. It’s 10000% worth it to invest in creating a build pipeline that allows you to test work before it’s marked as “completed”.

Ready for deploy - A lead should be in charge of merging the PRs and create releases for deployment. If you integrate with GitHub, once a PR is merged, it will automatically move into this category. Deploys to production should be automated, but I’ll leave that to your team. Developers are technically done with a story once it reaches this stage. If a bug arises, it will be a new story and linked back to this ticket.

Completed - Once I deploy, and we have team sign off from stakeholders, the story moves to completed.

3. Backlog grooming - Backlog grooming is a crucial part of running your own agile process, especially in the beginning. Backlog grooming is essentially board grooming. It’s how you decide what is going to be done this week and how you clear out unnecessary work that is no longer relevant either because it has been completed, or because it’s not needed. Without regular backlog grooming your board gets unwieldy, you hit work-in-progress limits and things start to grind to a halt. I recommend multiple times a week to start, 2 minimum. 

In this meeting, you’ll move through the board from right to left - yes, that’s correct, right to left - and move tickets/stories to their appropriate column. In this process, it’s important that everyone be aware of who should be moving what before the meeting. See the above for responsibilities. 

Once you’re good at the stuff above and doing it daily as reflex, you switch to primarily backlog grooming, which entails prioritizing what are the most important things to be working on this week to accomplish the larger scale goals of the company. You should have a developer available either for the entire thing, or towards the end so you can score each ticket for difficulty. This will usually lead to a small reshuffle points are meant to keep you grounded in reality, you cannot accomplish a 2x improvement in average velocity throughput week over week, so if your developer is scoring things and the data says it won’t be done in a week, then more than likely, it won’t be done in a week.

4. Daily standups - You should bring anyone that is working on the codebase together daily for a standup, either via video or just chat. Every day by 10am, you should get the following information from the devs:

Listen carefully here because this is where you find things that are going to derail your project. Unblock your developers as soon as possible and never derail a standup for random stuff. If there is an urgent fire that needs to be put out, this is the place to do it. This is not your opportunity to talk about investors, customer requests, etc. Your work should have already been outlined in your backlog grooming meeting, this meeting should be largely informational for you as a stakeholder.

5. Retros - Periodically, usually every 2 sprints, you should have a reflective session called a retrospective. Every dev should be present via video chat to discuss the following:

These are the only two rituals we can depend on as developers and they're very important to respect. It’s VERY VERY important that this is a “safe space” for EVERYONE. This is your opportunity to understand what you can do better as a stakeholder and what your team understands what they can do better. There should be no defensiveness here and there is no “boss” in this meeting. This is a pow-wow meant to be a release valve, a way to be heard and a way to hear what your team is saying. Everything should be organized into those 3 categories and you can use a tool like funretro to conduct these or just a google sheet.

If you hear something that makes you feel offended, you should ask clarifying questions in order to get the most information possible and never get defensive. Your team mate is saying this because it needs to be heard and they want to see a change. Do not diminish their opinion, discuss it and understand it.

It’s important that you note what things you will take action on and that you actually follow through with them before the next retro. Same goes for anyone who gets an action item from the retro.

6. Velocity - Velocity is meant to give you data about your teams productivity. It is an anchor for reality. The long term goal is always to improve velocity. I recommend you try to improve velocity in an on/off fashion in 3-4 week increments to give your team breathing room and not burn them out. 

Velocity is calculated on a weekly basis by adding up all of the points that moved into “completed” for the week. Good softwares usually give this to you for free. You want to use your average velocity for the last 2-3 weeks, which is often called the rolling velocity.

I recommend the fibonacci sequence as your velocity scoring system to start but you can change after trying it out. Your developers should be scoring stories/tickets fairly consistently across sprints, if they’re not, bring it up in retro or a separate meeting.

This is just the beginning process, they're processes that I have seen work very well to create products that are high quality and highly available. I believe you should put these processes to work for at least 6 weeks before considering any major changes. After that, feel free to make changes on the fly to suit your team.