The version control system used, peer review process, code review process, design review process, how you do CI, automated testing, and manual testing – all vary greatly depending on where you work.

How a company plans, writes, builds, reviews, deploys, and releases software is optimized for their particular use-case, all with their own strengths and drawbacks in mind.

I started reading about how different big tech companies run their Software Development Lifecycles (SDLC) and heard the term Trunk-Based Development a few times. This is a practice Google follows and I was curious about how it's different than the way most other companies develop software.

Two Different Ways to Do Branching

Release Branching

There are two common approaches to enable multiple developers to work on one codebase.

The first we'll refer to as the release branching** method. I've also seen it called feature branching**. But both of these same approaches follow the same general pattern.

Usually via Git, developers all clone the codebase (so they all have identical copies on their machines). Then they make a new feature/release branch based on main, and merge as the work is completed. The emphasis here is that they only merge once, at the end, when all the work is complete – and they merge the whole branch into main.

Here's an overview for how developers use the Release Branch** method:

Release Branching development workflow visualised.

The white dots represent commits, and the bottom solid black line is main. This is a very simple example, as release branches often end up with far more commits than I've shown in the diagram (sometimes hundreds).

Developers branch off main, make their changes, and then when it's complete/has passed code QA, it gets merged back into main. That's release branching.

Trunk Based Development (TBD)

Trunk-Based Development (TBD) is the second approach. Here, each developer splits the work they will do into small batches and merge into main (which is often referred to as the trunk) multiple times.

In small teams, they normally don't create a branch and merge the branch into the trunk. They commit directly into the trunk without branches.

In a larger team (with checks and approvals necessary for MR's), they use short-lived branches. One release branch with 100 commits in TBD would be 10 merge requests with 10 commits each.

In TBD, their code changes generally don't stay around for more than a few hours. They constantly get merged and integrated with the code everyone else is writing.

Jez Humble is a Site Reliability Engineer at Google, and author of Continuous Delivery, who says "branching is not the problem, merging is the problem" – which is exactly what TBD tries to solve.

It aims to avoid painful merges that so often occur when it is time to merge long-lived branches that have diverged histories from the trunk, or even merge multiple branches together into one from different teams/developers before merging with the trunk.

Does TBD Work at Scale?

In a Google talk, Rachel Potvin, who's an Engineering Manager at Google, described one codebase that has (as of Jan 2015):

• 1 billion files
• 2 billion lines of code
• 86 terabytes of content
• 45,000 commits per workday
• 15 million lines changed in 250,000 files per week

They used TBD in this codebase and it served their use cases very well. As Google is made up of many talented (most importantly, experienced) engineers, they rarely break their builds.

Google also has a very thorough, strict code QA process (read about it here) which, when using TBD, allows for fast, efficient software delivery.

TBD also works well for Agile methodologies where you have to ship software frequently to get feedback from your consumers/customers. You can continually integrate and get a good snapshot of your current state.

Let's briefly discuss some TBD strengths.

Strengths of TBD

• Feedback (whether from code QA, or peer review) comes quickly, as you merge daily. This can stop you from doing the wrong thing for 3 weeks, and then getting feedback that your work isn't correct at the very end, causing you to miss deadlines.
• There's a mental benefit to TBD, where developers feel like the trunk is our code, rather than everyone having their own feature branches and thinking this branch is my code. This can foster a more collaborative culture, increasing communication.
• It results in early integration with all the other in-flight projects/tickets and helps you promote code re-use. It's much harder to "use code" that isn't merged into main and you don't know when will be complete. It also stops merge hell when your 9 month old release branch needs to be merged back into the trunk.
• Large projects with lots of work involved are forced to be broken down into smaller deliverables. This is much better for estimating timelines and also for breaking up your code into modular pieces.
• When lots of developers work in isolation on release branches, it can be harder to spot junior developers struggling in their own branch. But if they're expected to be committing their work daily, you can monitor their daily output and assist them when necessary.
• TBD really cleanly ties in with continuous integration. With lots of small, incremental commits to an eventual finished project, you get an always tested, always integrated codebase with (minimal) horrible merges.

Weaknesses of TBD

• One of the challenges of this approach is that you have an increased chance of breaking the trunk, and stopping lots of people from working. You have to make sure your commits run unit tests along with a good code review process so you don't lose time reverting commits all day.
• Your commit history into main will likely be more verbose and it can be harder to see if something is wrong. If you are called at 3 AM and asked to fix a bug on your prod site with some dodgy commits that went on during business hours, would you prefer a day with 1 commit or 200 commits?
• If you don't have a fast build process, you will spend a long time waiting for things to build while your team constantly commits.
• Often times with TBD you are incrementally adding new code to do something new, but you also need the "old" paths you're replacing to still work. Because of this you need to rely on feature toggles (normally from a database) to turn things on and off. This can add an extra level of complexity with debugging.
• A final challenge can be that, when you have constant commits, you are constantly in a state of churn. You need to make sure your team regularly pulls from the trunk and doesn't end up tripping over one another while merging things.

How to Release Software with Trunk-Based Development

Teams using TBD will typically have a different release process than a team using feature branches.

Generally, if you use release branches, you release main whenever you have something that gets merged in (tickets, completed projects, and so on). Or some teams release main on a schedule, like once every week.

Here's an overview of how TBD teams do their releases:

Overview of TBD process

In TBD, branching is used for releases to allow everyone to keep committing into main.

They provide a "snapshot" of your codebase at a stable state, ready for deployment and release.

The only reason the TBD diagram above may need extra details is when something goes wrong with the release of prj-123. Then we commit the result into the trunk and cherry pick the commits into our release branch to get it in a workable state as soon as possible.

Some places, if they are releasing regularly, don't even branch and can just release the trunk whenever it's required. It depends on your company oftentimes.

Conclusion

There is a whole site based on the theory and practice of TBD. Feel free to read more here.

I hope this has explained what Trunk Based Development is and why it's used. It certainly helps alleviate some of the issues around merging long-lived branches containing major rewrites.

I share my writing on Twitter if you enjoyed this article and want to see more.

Until recently, I'd spent the last 4 years of my career at FinTech start-ups. I'd always worked for smaller companies, and being at a start-up was the next logical step in looking for roles where I could make the biggest difference.

But a common problem with early-stage start-ups is that it's kind of a free-for-all in terms of how they're managed.

These companies tend to be run by people who don't have a ton of experience running companies. And management tends to consist of founders and those who got in early, not necessarily those who excel in leadership roles. (No shade – good person + talented doesn't necessarily mean they're a good boss or leader).

During my time at one such start-up, I was promoted from senior developer to lead developer.

The catalyst for this change was that the development team lacked leadership. The CTO had too many responsibilities, and the job of keeping the dev team engaged and productive was falling through the cracks.

On top of this, we didn't have a project manger, and our product managers were too inexperienced to introduce any kind of structure.

This is the story of the wins and losses, and how to add process to a company that has none.

Events leading to the change

First, a little bit of background. My previous job had been as a developer at a digital agency. This agency was a hard-core scrum shop that had trained all of their employees fairly thoroughly in scrum, and agile in general.

So I came from an environment with a lot of process. That's partially why I left to pursue a start-up.

About a year in, I started to notice some issues. Firstly, the developer turn-over was growing. Developers weren't feeling engaged. They were handed half-baked projects with no context on how it would aid the growth of the company, no input in the design or planning, and with nowhere near enough detail.

Then came a project that crystallized our problem. The product that I worked on had the concept of bills (payables) and invoices (receivables). We were working on a new feature that would allow users to upload an image of an invoice and have it input manually by a service.

The problem was that the product manager kept saying "bills" instead of "invoices". There was no user story, no ticket, this was all in the mind of the product manager. Requirements were communicated verbally or in slack messages. The developer working on the project had only ever been told "bills".

It wasn't until the CTO overheard a conversation a few days before release that we realized that we'd targeted the wrong aspect of the system.

Luckily, bills and invoices were, for the most part, symmetrical in our system, so it wasn't much work to make the change. It just became very clear that we had a problem.

Given my background and the fact that I was one of the most senior and tenured developers at the company, it made sense for me to take the lead.

Since I was leading the initiative, I chose to implement a scrum-type process. In the remainder of this article, I'll outline what we did, how we did it, and why it was done, as well as my learnings.

Getting Buy-in

I'm gonna preface this by saying that I don't like handing commandments down from on high. I feel like a leader-team relationship is a collaborative one. I may occasionally play leader because it's my nature, but it's important that ideas are discussed and that people feel their opinions are heard and valued.

The first step was to gather the developers to have a discussion. In this initial discussion, I outlined what I felt our issues were. This included lack of clarity on requirements, sliding deadlines, and our complete lack of a testing strategy. The discussion validated my thoughts, because the team felt the same way.

The rest of the meeting consisted of me outlining scrum, what elements I felt could benefit us, and what that would look like. I also discussed some things that I learned about test plans and systematic QA that I learned in my agency days. We then went around the table, giving thoughts, asking questions, and tweaking.

I conceded that manual testing wasn't fun or ideal for the dev team, but until we could justify a full-time QA engineer, we had to do the best with what we had.

Learnings:

• If you have a good idea, all you need is a chance to prove its worth.
• Enlist your team to help build this together, make everyone part of the solution and they'll own it with you.

Our Version of Scrum

After describing what a "full" scrum process would look like, I laid out to the team what the purpose of each aspect and ritual was. I wanted to highlight where we could get the most gains. No one wanted 10 hours of meetings per sprint.

Speaking of sprints, we decided to start with a 2 week time-box with an eye on moving it to 3 weeks if we wanted less overhead and could afford less frequent releases.

The process I put in place was as follows.

We'd have a sprint started with a 2-hour grooming/planning meeting on a Monday morning. In this planning meeting we (the dev team and the product manager) did a pass over the backlog. This pass consisted of clarifying the story to clear up misunderstandings; estimating using story points; and prioritizing based on company road-map. The team then picked out the amount of work we felt we could do, based on priority, and brought it into the current sprint.

This work was a collection of user stories. The product manager would leave, and the dev team would break these stories down into tasks, get a general sense of who would work on what, and then we got to work. This gave the product manager transparency on what we could deliver, which was sorely lacking. It also gave the team their full workload for 2 weeks, which allowed us to plan and pace accordingly.

The next week and a half were dev days. This included peer code reviews on feature branches before they were merged. Dev hands-off was the Wednesday of the 2nd week at noon. We would then prepare the QA build, QA spreadsheet (more on this in a bit), and start manual testing.

The idea was to finish the initial QA pass by the end of the Wednesday, and spend Thursday and Friday in a bug fix/test loop until we were satisfied with the build.

At this point, the build would be handed off to the CTO for a final code review, and it would be deployed the following Tuesday. Issues found in the code review would be fixed and tested on the Monday if needed.

Friday afternoon we would have a blameless retrospective/postmortem. Here we laid things bare. It's important to acknowledge what went poorly, and to address the cause(s) so that we could avoid it in the future.

All of the developers (including myself) learned a lot through this process. I feel like we're all better off after having gone through it. I actually overheard the CEO suggest doing blameless postmortems a few weeks after we started doing them on the dev team. It was nice to see that our ideas were catching on.

This was one of the big wins. We learned why a feature was needed, what the intention behind it was, and all of the details and expectations.

Learnings:

• Split and join meetings based on your team's needs. Don't do things "just because"
• Share your progress outside your department. Sometimes your ideas can provide benefits outside of your team.

A Testing Framework That You Can Believe In

This company had never had a formal testing process. This meant no test plan, no peer testing, just a developer verifying that it worked, and it going to production.

In my experience, developers are as good at testing as they are at estimating, so we needed to change that. We had a good suite of automated tests (unit and integration), but no end-to-end tests. I also prefer to have some exploratory testing as well. In the past, I've seen it uncover weird behaviors that automated testing can miss.

We set up a google doc with all of the tickets (including links to the user stories) in the first column, and all of the developer names (and the PM) in the first row. The idea was that every ticket had to have 2 X's, both from people who didn't work on the feature. This divide and conquer strategy allowed us to test very thoroughly in a fairly short amount of time.

Learnings:

• Lean hard on automated testing. It's reliable and finds many classes of bugs with no manual time.
• Test with a plan. You're going to waste a lot of time just wandering. A systematic approach can make manual testing more efficient.

Success

What was the result? I don't have exact numbers, but the defect rate plummeted. There were no longer rushed hot fixes to production. The work promised was delivered. Features were being released on time.

We were moving faster than ever, and the developers were happier. We were working as a team instead of in silos, we all knew each others' features intimately because we all went through the user stories and estimated together. There was no more of this "oh, I can't touch feature X, I didn't work on it" siloing stuff.

One dev who was planning on leaving stopped looking. It was great.

Learnings:

• Keep adjusting your process based on results. It's an ongoing process.
• Sometimes people don't want to leave a company, they want to leave a situation.

An Abrupt End

But nothing gold can stay :) Ok, that's a bit dramatic. While the dev team was gelling, increasing our velocity, and building more camaraderie, management was going in a different direction.

The CEO had done a ton of reading and decided that OKRs were what was gonna get the company to the next level. Unfortunately, it was decided that OKRs would go down to the individual level, meaning that the team would no longer be pooling work, breaking it down and tackling it together. Instead, each developer would work out (or in practice, given) a set of KRs, and they alone would be responsible for delivering on them.

We were back to silos. The development team pushed back, we tried to compromise, to stop OKRs at the team level, but it was no use. The dream was dead. Yes, again with the drama, but it was a little sad.

This change coincided with a slight change in power structure, my title as lead developer became little more than a platitude, "leadership" said some very unkind things to the development team (somewhere along the lines of "get on board or get out"), which led to half the dev team, including myself, leaving within a month.

Learnings:

• Good ideas don't always win out. Even in a situation like this, you can learn a lot.
• Recognize when you can no longer make a difference.

Mistakes Were Made

Given the way that last paragraph ended, you may thing that I was about to enumerate the mistakes that the company made. But I'm not going to do that.

It's been about a year since I left, and in that time I've learned a thing or two. There were some serious gaps in the process that we'd created. These were things that I just didn't really understand or know about at the time. It was due to my shortcomings, but we all get better every day.

In hindsight, here are some major things I'd missed:

We weren't measuring.

How do you know you've done it right if you didn't take measurements before and after? We had no telemetry, very little alerting, and frankly, if a feature had negative impact, we didn't know about it.

Too much manual testing, not embracing automation.

What we were really missing was a nice suite of automated E2E tests. We started working on these near the end, but we didn't prioritize them enough. Many of the errors we found during manual testing could have been caught during some acceptance tests using cucumber, or some E2E selenium tests.

Big bang releases.

I know a common part of scrum for many companies is the idea that all of the sprint work is demoed and released together.

The problem with this is two-fold. Firstly, at a start-up you need to move quicker. You need to beat others to the punch and get value out to customers and feedback from customers as quickly as possible. And the tighter that feedback look is, the better.

Therefore, multiple releases per sprint would have been better. It's more difficult to coordinate testing and QA, but it's still better to release quickly and often.

Secondly, the larger the release, the more risk is involved. Releasing smaller chunks means that fewer changes are released at one time. If there's any issue, it's easier to identify and fix, and a rollback won't affect other, correctly functioning features.

So I've learned that releasing in verticals that are as small as possible is the safest, least coupled way of releasing software.

Conclusion

For all of the missteps and the unfortunate ending, I feel like the experience was a success. I learned what it meant to guide a team of developers through a process, to take feedback and apply it, and to try and discard ideas that, even though they are "supposed to be there", just didn't fit our team.

It's important to cater your process to your team and organization. You have to add enough process to guide, but not so much to hinder. It taught me how to implement process, to push ideas forward, to help others be heard, and how to lead from within a team.

Although it ended poorly, it was a big step forward in my career, and really solidified my ability and desire to lead.

You can find more of my articles on my medium blog.

It’s far more fun to draw the tire swing, front porch, and swimming pool than to worry about how a ten-thousand-gallon bucket of water stays suspended in midair.

With too much attention spent on fun and flashy features, foundations suffer.

A comic I drew about building stable foundations. It's not that funny.

Of course, spending undue hours building a back end like Fort Knox may not be necessary for your application, either. Being an advocate for security doesn’t mean always wearing your tinfoil hat (although you do look dashing in it) but does mean building in an appropriate amount of security.

How much security is appropriate? The answer, frustratingly, is, “it depends.” The right amount of security for your application depends on who’s using it, what it does, and most importantly, what undesirable things it could be made to do.

It takes some analysis to make decisions about the kinds of risks your application faces and how you’ll prepare to handle them. Okay, now’s a good time to don your tinfoil hat. Let’s imagine the worst.

Threat modeling: what’s the worst that could happen?

A threat model is a stuffy term for the result of trying to imagine the worst things that could happen to an application. Using your imagination to assess risks (fittingly called risk assessment) is a conveniently non-destructive method for finding ways an application can be attacked.

You won’t need any tools – just an understanding of how the application might work, and a little imagination. You’ll want to record your results with pen and paper. For the younger folks, that means the notes app on your phone.

A few different methodologies for application risk assessment can be found in the software world, including the in-depth NIST Special Publication 800-30. Each method’s framework has specific steps and output, and will go into various levels of detail when it comes to defining threats.

If following a framework, first choose the one you’re most likely to complete. You can always add more depth and detail from there.

Even informal risk assessments are beneficial. Typically taking the form of a set of questions, they may be oriented around possible threats, the impact to assets, or ways a vulnerability could be exploited.

Here are some examples of questions addressing each orientation:

• What kind of adversary would want to break my app? What would they be after?
• If the control of x fell into the wrong hands, what could an attacker do with it?
• Where could x vulnerability occur in my app?

A basic threat model explains the technical, business, and human considerations for each risk. It will typically detail:

• The vulnerabilities or components that can cause the risk
• The impact that a successful execution of the risk would have on the application
• The consequences for the application’s users or organization

The result of a risk assessment exercise is your threat model. In other words, it's a list of things you would very much like not to occur.

It is usually sorted in a hierarchy of risks, from the worst to the mildest. The worst risks have the most negative impact, and are most important to protect against. The mildest risks are the most acceptable — while still an undesirable outcome, they have the least negative impact on the application and users.

You can use this resulting hierarchy as a guide to determine how much of your cybersecurity efforts to apply to each risk area. An appropriate amount of security for your application will eliminate (where possible) or mitigate the worst risks.

Pushing left

Although it sounds like a dance move meme, pushing left refers instead to building in as much of your planned security as possible in the early stages of software development.

Building software is a lot like building a treehouse, just without the pleasant fresh air. You start with the basic supporting components, such as attaching a platform to a tree. Then comes the framing, walls, and roof, and finally, your rustic-modern Instagram-worthy wall hangings and deer bust.

The further along in the build process you are, the harder and more costly it becomes to make changes to a component that you’ve already installed.

If you discover a problem with the walls only after the roof is put in place, you may need to change or remove the roof in order to fix it. Similar parallels can be drawn for software components, only without similar ease in detangling the attached parts.

In the case of a treehouse, it’s rather impossible to start with decorations or even a roof, since you can’t really suspend them in midair.

In the case of software development, it is, unfortunately, possible to build many top-layer components and abstractions without a sufficient supporting architecture.

A push-left approach views each additional layer as adding cost and complication. Pushing left means attempting to mitigate security risks as much as possible at each development stage before proceeding to the next.

Building bottom-to-top

By considering your threat model in the early stages of developing your application, you reduce the chances of necessitating a costly remodel later on. You can make choices about architecture, components, and code that support the main security goals of your particular application.

While it’s not possible to foresee all the functionality your application may one day need to support, it is possible to prepare a solid foundation that allows additional functionality to be added more securely. Building in appropriate security from the bottom to the top will help make mitigating security risks much easier in the future.

• What is agile?
• What are some concepts you should know?
• Stories
• Epics
• Sprints

What is agile?

Agile is a software development methodology that stems from the idea of breaking up large amounts of work into smaller pieces. This gives product managers, developers, and any stakeholder a better understanding of the work.

Historically, software development was a slow process where major changes to requirements could put large strains on teams.

When following the agile methodology, the smaller chunks of work help teams become more flexible, and dare I say agile. And in the process it helps them deliver features faster and respond to changes quicker.

Example Jira project board from atlassian.com/software/jira

These ideas have been broken up into different frameworks of approaching this methodology. Two of the common ones are Scrum and Kanban.

For this walkthrough, most of these concepts follow along the Scrum framework, but there are certainly concepts that apply to both and others.

What are some concepts you should know?

I'd argue half of being productive as a developer in an agile world is simply understanding the terms. Typically the project manager runs the show, so if you can be on the same page with what they're talking about, it will make the process a lot easier.

There are books, courses, and certifications based around learning the nuances of the agile methodology. I'm not going to go deep into some of the philosophical aspects or some of the deeper parts, but I'm going to cover a good set of key concepts that will help you hit the ground running when you start your new job with an agile team.

Stories

A story is typically the smallest defined piece of work. This usually comes in the form of a new ticket that you create in the project tool you're using whether it's Jira or even Github Issues.

Expressing stories

When working on a project, you'll probably run into a variety of ways people express stories. But a good guideline is to work through the concept of the word "story" itself and explain the work that needs to be done in that way.

For instance, if you would like to provide the ability for the people who use your website to share a blog post on Twitter, you may want to write the story as: As a reader, I want to share the post I just read to Twitter.

Creating a new story in Jira

Using that pattern of "as a [person], I want to [action]" helps provide context as what state somebody may be in when visiting their site and what they're trying to achieve. This can be particularly helpful if you're developing features for people who are logged in that are different from guests.

Details and requirements

While the title of a story is an important representation of the work, you'll also want to provide additional specifics.

At a minimum, that should be done by adding a thorough description and a set of acceptance criteria that can help give the developer context and requirements. Depending on the team, this can also include tools like tags or categorizations that make it easier for the team to visualize groups of work.

Providing a strong set of requirements helps both the developer working on the story and the person reviewing it have a measurement to determine if it's actually complete. Without it, everyone's just guessing.

A good way to phrase these are: verify [requirement]. Back to my example of sharing a post on Twitter, maybe some of the requirements to that story would be:

• Verify when clicking the share button a new tweet is created
• Verify the tweet includes a link to the current blog post

Amount of work or level of difficulty

Each story is represented by a number of points. Those points are a way to express how much effort a team of developers expects one story to be. That effort can mean a variety of things though whether it's simply how difficult the team expects the work to be or the amount of risk or uncertainty a particular story has.

One way teams represent this is with the fibonacci sequence, where the amount of points can be 1, 2, 3, 5, 8, etc. Where a negligible text update might be 1 point, adding a new form to a page could be 3 points.

Typically you'll want to avoid pointing stories too high, as you get above 5 points, there's more than likely a way you can break up the work to make it more manageable. While you could easily create a massive 13 point story to accomplish all aspects of a feature, it usually makes sense to tackle the work in smaller, more focused chunks.

Either way, these points all add up together to give your team a rough estimate of how much work a group of stories would take to complete.

Epics

While stories have a goal of defining a bite-sized piece of work, epics are a way to group those pieces of work together to represent a feature.

Defining stories as a feature

A good way to explain this is with another example. If you're working on an application that requires the integration of authentication, you may want to create a new epic simply called "Authentication".

Inside that epic, you could find stories like:

• As a guest, I want to sign into the application with my email address
• As an authenticated user, I want to change my password
• As the security team, I want to prevent spam and abuse of user authentication

Example of an Authentication epic in Jira

With your epic defined, you're giving your team a path to calling a feature complete while also understanding the entire scope of that work. This is important when it comes to planning out the work to be done.

Defining your stories in your epic gives you a sense of how much work something takes, but it doesn't help you figure out how long it would take, which is where sprints come in.

Sprints

Sprints are a way of planning out how the work will actually get done. While similar to epics in that they are a way to group chunks of work, sprints typically represent a period of time in which a particular chunk of work will be done.

Time per sprint

A common way of defining a sprint is two weeks of work. During those two weeks, your team will have a particular velocity, or average amount of work you can complete, for an individual sprint. This velocity is represented by a number of points that is a sum of the average velocity of each of the developers working on that sprint.

Points per sprint

Though many fiercely argue you shouldn't use time to represent that velocity, points will roughly translates to an average amount of time of work for each developer. While 1 point for an experienced developer could be 1 hour, that same 1 point could mean 3 hours for a less experienced developer.

Example project roadmap from atlassian.com/software/jira

But once you have this number of points that your team averages in a sprint, you'll know how many story points you can expect to plan to be completed. This planning goes sprint to sprint as you spread out a group of stories or an epic so you can predict when a feature will be complete.

How agile fits with your team

Try to remember that the Agile methodology through Scrum, Kanban, or any other framework is just that – a framework. While it's probably a good idea to follow the process when you first start out, listen to your team and try to mold it to your own experiences.

Each team works a little bit differently and forcing a process onto that team can cause more harm than good, but there will always be a learning curve for any process. Fight the eye rolls until everyone gets the hang of it and have frequent retrospectives to see what works and what doesn't.

At the end of the day, the processes your team follows should mostly be invisible, working for you instead of against you. Find what works best for your team and share your experiences for others to learn!

What's your teams process?

Share with me on Twitter!