This is the fifth value covered in a series of blog posts on what we can learn in implementing values that are the same or similar to GitLab’s CREDIT values. For background and links to the other posts, please check out the overview post.
Iteration
Iteration is closely intertwined with results since the better we iterate, the more results we produce.
Never perfect
One of the hardest parts of iteration is for people to let go of the idea that you don’t release something, or even create a MR until something is perfect, or at least polished. If we don’t have anything online though, others cannot see what we’re doing, what we’re proposing, or how we’re progressing. This not only goes against our value of transparency but can deter collaboration.
Even for non-code changes, having draft work online means people can start referring to it earlier.
When I joined GitLab, our team was still fairly new (the first agent was hired about 3 months before I was), and a lot of processes were still in the works or non-existent. When something was missing, we at least created an issue to make sure we didn’t forget about it. If we could, revisions or new processes would go straight into a MR.
One of the workflows I worked on got a bit stuck in review for quite some time, because we needed reviews from security, development, and infrastructure. The process took much longer than we had hoped to finalize, especially given that we really needed it in place. In the meantime, I wrote up the general process for the parts we could do and got that merged first. Everything else was put into a second MR, because it was something everyone could refer to and team members could start using it once it got approval, even if wording needed to be improved or it wasn’t live on the site yet.
Minimal viable change (MVC)
Whether it’s the product or documentation, we are asked to make small changes. Even with new features, we push a first iteration so that we can move quickly.
Even if it’s a work in progress (WIP), we are encouraged to submit a merge request. Not only does this help transparency, but also early review and feedback. We can catch possible mistakes or things from going down the “wrong” path early. It’s also much easier and faster to review, because there’s a lot less to do in one go.
In many organizations, before work can begin, a full plan has to be written. The plan often has to be presented to individuals or groups to receive feedback. When a stamp of approval is given, then work can begin. But what happens if there are any snags, unforeseen bumps, or complete roadblocks?
In some places, that would require halting any progress until the issues were identified, a plan was created, and the new plan was approved. In other cases, workarounds would be put in place with the idea that the issue might be fixed later (which means never in many places), or a portion is identified as shelved for later, but current implementation might not future proof it to include that shelved portion (or other future portions).
While things don’t always go swimmingly, small changes are much easier to narrow down and revert if necessary.
It’s not uncommon for things to go wrong, but even in Support being outside of the development team, we can sometimes identify the specific MR where a change might have been introduced. Engineering can then easily fix the problem since in most cases, it’s a small enough change that it’s easy to review and write a patch for.
Slowing down when we need to
Despite our iteration and results values, we also recognize that there are times when small, quick iterations can get in the way. Some things need consistency, have a huge impact, or aren’t easily reversible.
Sometimes before building out a new feature, or often to improve an existing feature, we have a UX research team that runs surveys and studies to collect feedback and evidence from users to help inform the next iteration. Going through this process makes an iteration more deliberate and helps to validate a proposal.
Take away
Iteration at a fast pace is not always easy, but it gets easier the more value we see in it and the more we practice it.
