Then I joined a real team.

Suddenly, I was introduced to this thing called Kanban – and I realized I’d been treating software like a solo art project, not a process.

If that sounds familiar, you’re in the right place.

This guide will walk you through how Kanban actually works, how developers use it to track and prioritize work, and how it can help you stay sane when juggling bugs, features, and real-world deadlines.

Without further delay, lets get into it.

Here’s what we’ll cover:

• So… What Is Kanban?

• The Classic Kanban Board: Three Simple Columns

• How Developers Use Kanban in Real Life

• Kanban vs Scrum: What’s the Difference?

• So which one should you use Scrum or Kanban?

• What Tools Do Teams Use for Kanban?

• How to Use Kanban to Manage Your Own Coding Projects

• Final Thoughts: Why Kanban Isn’t Just a Board

So… What Is Kanban?

At its core, Kanban is a visual way to manage work. It helps teams (or team members) see:

• What needs to get done

• What’s in progress

• What’s finished

• Where things are getting stuck

The concept comes from lean manufacturing, but in tech, it’s often used in Agile teams that need flexibility without the structure of Scrum sprints.

Think of Kanban like a whiteboard that tells a story. Not just what’s done, but how work flows.

The Classic Kanban Board: Three Simple Columns

So what exactly is a Kanban board? At its core, it’s a visual representation of your workflow – a board that shows all the work your team (or you, solo warrior) are juggling, and where each task stands.

It can be physical, like an actual whiteboard with sticky notes that move from one column to the next. Or digital, using tools like Trello, Jira, GitHub Projects, or Notion. The key is that it’s visual and up-to-date. You can walk into a room or open a tab and instantly understand: What’s being worked on? What’s ready to go? Where are things stuck?

It’s like having your brain on a wall, but organized. And slightly less chaotic.

The beauty of Kanban is how dead simple it is to get started. At minimum, your board has three columns:

Each task – or card – moves from left to right as it gets worked on.

Let’s say your team is building a blog platform. Your Kanban board might have cards like:

• “Create signup form”

• “Fix image upload bug”

• “Deploy staging build”

Now, while Kanban is flexible, it can absolutely be taken too far.

I’ve seen boards with more columns than a Greek temple: “Needs Review,” “Pending Client Feedback,” “QA Rework Round 2,” “Blocked but Still Hopeful,” “In Existential Limbo,” and so on. Every card had six tags, three owners, two checklists, and one migraine.

The lesson? Don’t turn your board into a bureaucratic jungle.

You don’t need to account for every edge case. Start simple: “To Do,” “In Progress,” “Review,” “Done.” These basic stages cover most workflows. If you discover a real need for something more – like a dedicated “QA” column or “Blocked” column – add it intentionally, not because you feel like your board needs to look fancy.

Remember: A Kanban board should be helpful, not overwhelming. If you spend more time managing the board than doing the work on it… it’s doing the opposite of what it’s meant to do.

How Developers Use Kanban in Real Life

Here’s how you might interact with a Kanban board on a dev team:

1. You pick up a card from “To Do” – let’s say, “Add dark mode toggle.”

2. You move it to “In Progress.”

3. When it’s ready for review, you might move it to a temporary “Review” or “Testing” column.

4. Once it’s merged, tested, and deployed, you move it to “Done.”

5. You smile, drink some coffee, and grab the next card.

That’s it. But over time, this process helps the whole team:

• Spot bottlenecks

• Prevent duplicate work

• Reduce context switching

• Keep everyone aligned

What’s a WIP Limit — And Why Should You Care?

WIP = Work In Progress. This is the most important concept to keep us in check.

One of Kanban’s key principles is limiting how many things you’re working on at once. Because guess what? Multitasking kills momentum.

A typical WIP limit might look like:

• No more than 2–3 cards per person in “In Progress” Again this is best practice, but folks do pick up a lot and then they end up being the bottleneck.

• No more than 5 tasks waiting on QA.

Why? Because when everything’s urgent, nothing gets done. WIP limits force you to finish one thing before you start more – and that’s how real velocity happens.

If there are more than 5 tasks in the “To Do” column, the team doesn’t take up new ones. Instead, everyone chips in to see how they can help unclog the bottleneck. A bottleneck is your worst enemy in Kanban, and you want to resolve it so items move smoothly on time and on target.

Here’s a video recapping key concepts.

Kanban vs Scrum: What’s the Difference?

You’ve probably heard Scrum and Kanban mentioned in the same breath – and both are popular Agile frameworks. But they’re not interchangeable.

Scrum is structured, with roles like Product Owner and Scrum Master, and work gets organized into time-boxed sprints. It’s perfect for teams that benefit from rhythm and rituals – like sprint planning, daily standups, and retrospectives.

Kanban, on the other hand, is a little looser. No official roles, no set sprint timelines. Work flows continuously, and change can happen anytime. It’s perfect for teams who need more flexibility and fewer ceremonies.

So how do they compare in practice? Let’s break it down:

Bottom line:

• Scrum is a scheduled loop. Kanban is a living flow.

• One’s a playbook. The other’s a status window.

Here’s a video on the main differences between Scrum and Kanban you can watch if you want more detail.

So which one should you use Scrum or Kanban?

So… which one should you use?

It really depends on your team, your product, and your pain points.

✔️ If you’re working on a brand-new product where requirements shift a lot, and your team thrives with structure and routines – Scrum is likely the better fit. Sprints give you a sense of pacing, and ceremonies help ensure alignment.

✔️ If you’re managing ongoing work like bug triage, tech debt, infrastructure tasks, or anything that’s more “whenever it comes in” than “we need to ship this in two weeks” – Kanban gives you flexibility and visibility without the overhead.

And yes, there’s such a thing as Scrumban – a hybrid approach where teams use visual boards and WIP limits from Kanban, but keep some of Scrum’s structure like standups and retros. It’s like Agile tapas: you get the flavors that work best for your appetite.

Here is a detailed video that’'ll teach you more about how Scrumban works in practice.

Watch the Scrumban video only when you are familiar and comfortable with both Scrum and Kanban – otherwise, you might get confused from the cross-pollination of ideas and frameworks.

I personally have never seen a Scrumban implementation thats scaled well – too many folks trying too many things and none of them work. But thats just based on my experience – it may work for you and your team. I’ll let you be the judge.

What Tools Do Teams Use for Kanban?

You’ve probably seen (or used) one already:

• Trello – Simple and great for solo or small teams

• Jira – Enterprise-level, customizable workflows

• GitHub Projects – Lightweight but powerful for devs

• ClickUp / Asana / Notion – Integrated with docs/tasks

Kanban isn’t tied to any one tool – you can use an app, a browser tab, or a whiteboard and a pack of sticky notes from the office supply closet. What matters is how you use it. But let’s walk through some of the most common tools and what they offer in a Kanban context:

🟩 Trello

Trello is probably the easiest way to start with Kanban. It gives you a simple digital board with columns and cards you can drag and drop. It’s great for devs or small teams who don’t need tons of automation – just a clean place to track work visually.

🟨 Jira

Jira is a heavyweight – and while it’s built for Scrum, it also supports robust Kanban boards. You can define custom workflows, use built-in reports like cumulative flow diagrams, enforce WIP limits, and manage team velocity. Ideal for large teams that need traceability, integrations, and permissions.

🟦 GitHub Projects

If your code lives in GitHub, GitHub Projects is a clean way to stay close to your codebase. It lets you create Kanban-style boards with issues and pull requests as cards, so you’re never toggling between tools just to track what’s in progress.

🟧 ClickUp / Asana / Notion

These are all-in-one productivity platforms. They combine Kanban boards with documentation, team chat, calendars, and reporting. If your team needs more than just “move card left to right,” these tools let you manage projects, meetings, notes, and workflows in one place.

🟪 Whiteboard + Sticky Notes

Don’t underestimate the analog approach. It’s fast. It’s visible. It’s tactile. Physically moving a task from “Doing” to “Done” gives you a sense of progress no digital tool can match. And when something’s blocked? Slap a red sticky on it and call it a day.

Bottom line: The best tool is the one your team will actually use. Fancy doesn’t beat consistent. And the actual tool doesn’t matter as much as the discipline your team has to actually use it.

How to Use Kanban to Manage Your Own Coding Projects

Even if you're not on a team yet, Kanban is great for your own workflow. Here’s how you can use it to help yourself out:

1. Create a basic 3-column board (To Do, In Progress, Done)

2. Write out every task, big or small

3. Set a WIP limit (for example, no more than 2 tasks at once)

4. Update it daily. Make it a ritual.

5. Review your flow weekly – What got stuck? What moved fast?

Example:

You’ll be shocked how much clearer your thinking gets when you can see your work. It’s simple but super powerful to visualize your work it in this way.

Final Thoughts: Why Kanban Isn’t Just a Board

Kanban isn’t just a tool – it’s a mindset.

It helps you focus. It helps your team collaborate. And it gives everyone – even non-technical folks – visibility into what’s going on.

If you’re learning to code and want to feel more confident working with others, learning Kanban is low-effort, high-impact.

So don’t wait until your first job. Start using it now – and show up to that standup with confidence.

I hope this small 101 Guide to Kanban was helpful to you all. My sole purpose to write this was to help beginner developers understand Kanban as a practical workflow system – especially for those transitioning from solo coding to collaborative, real-world development environments. It aims to demystify the methodology in a casual, beginner-friendly tone while still offering actionable guidance.

I hope you enjoyed my beginners guide to Kanban.

Until next time, keep Learning, Unlearning and Relearning, folks….

You’ve been grinding through tutorials. You've built a portfolio site, maybe deployed a few projects on GitHub. And now you're trying to land a job or join a team.

Then the interviews start.

Suddenly, people ask:

• "Are you familiar with Agile?"

• "Have you worked in a Scrum environment?"

• "What’s your experience with sprints?"

Cue the imposter syndrome. Because no one teaches this stuff in JavaScript 101.

This guide is for you.

I’ll help make the Scrum process – a very common way developers work together – make actual sense. I’ll walk you through the basics, but also tell you what developers actually do, how standups feel when you're new, and what’s expected of you when you’re no longer coding in a vacuum.

Let’s break it down.

Here’s what we’ll cover:

• What Even Is Scrum?

• The Three Roles in Scrum (and Who Does What)

• The Scrum Rhythm: What a Sprint Actually Looks Like

• Who attends the Ceremonies:

• Standups: Where You Talk Like a Human, Not a Robot

• Sprint Planning

• What’s a User Story and Why Does It Sound Like a Children’s Book?

• What Counts as “Done”? Definition of Done and Why It’s Important

• Demos, Retros, and Saying the Hard Things

• Tools You Might Encounter

• If You’re Preparing for a Job, Here’s What You Can Do

• Final Thoughts

What Even Is Scrum?

Scrum is not a tool. It’s not a software. It’s not some elite thing only PMs care about.

It’s a lightweight framework that helps software teams build things incrementally, together, in short focused cycles called sprints.

Scrum is used by everyone from FAANG teams to indie dev shops because it helps:

• Keep teams aligned

• Deliver working software fast

• Course-correct often

• Spot problems early (before they go nuclear)

It’s the opposite of the old-school “build for a year and pray it works” model.

The Three Roles in Scrum (and Who Does What)

Scrum officially defines three roles. Here's what that means in practice:

1. Product Owner (PO)

Think: Vision-holder. They decide what the team builds and why. A product owner:

• Writes user stories (think of these as feature requests written from a user’s point of view)

• Prioritizes the work

• Clarifies what success looks like

• Says “yes” or “not yet” to features

2. Scrum Master (SM)

Think: Air-traffic controller meets therapist. They make sure the process works. The are master Facilitators, like between Dev and PO’s. A Scrum Master:

• Facilitates meetings

• Removes blockers (“Your AWS access is stuck? I’ll escalate it.”)

• Coaches the team on Scrum practices

• Doesn’t manage people – manages flow

3. Developers (YOU!)

Think: Builders. You write code, test it, ship it, fix it, and improve it. You also:

• Break down stories into tasks

• Pick up work from the team board (like Jira or Trello)

• Communicate progress

• Demo what you’ve built at the end of the sprint

You might also work with designers, testers, or DevOps folks – but within Scrum, you’re all “developers” building a product together.

The Scrum Rhythm: What a Sprint Actually Looks Like

Image Source: https://www.invensislearning.com/blog/what-are-scrum-ceremonies/

Understanding the Scrum Cycle

So, what does it actually look like when a team uses Scrum to build software?

Let’s walk through a full sprint – not just the buzzwords, but what really happens when a group of humans tries to plan, build, review, and improve together. Think of this as your backstage pass to the rhythm of modern teamwork.

📦 Step 1: Build and Refine the Product Backlog

Before any coding starts, the team needs to agree on what they might build – not just this week, but in the near future too.

That’s where the Product Backlog comes in. This is a big, running list of everything the product might need – features, bug fixes, improvements, ideas, and maybe a few wild dreams. It’s like the wishlist for the product, but more organized (ideally).

The Product Owner is responsible for maintaining and prioritizing this list. They decide what’s most important to work on based on customer needs, business goals, and feedback.

But the PO doesn’t do this in isolation. Enter the Backlog Refinement meeting.

In these sessions, the Scrum Team – that’s the PO, the Scrum Master (SM), and the Developers – come together to:

• Review the most important upcoming items

• Clarify any vague or confusing parts of each task

• Break big items down into smaller, buildable pieces called user stories

• Estimate effort (how much time or complexity is involved for each story)

This meeting makes sure the team isn’t caught off guard in the sprint – that they understand the work ahead and can actually start sprinting when the time comes.

🧭 Step 2: Sprint Planning – What Are We Building This Time?

Now that we’ve got a solid backlog, it’s time to pick what to build right now.

At the start of each sprint (which typically lasts 1 to 4 weeks), the team holds a Sprint Planning meeting. This meeting sets the stage for the entire sprint – it’s like the huddle before the big game.

In Sprint Planning, the team:

• Reviews the top items from the backlog

• Discusses what can realistically be completed based on their availability and capacity

• Chooses a handful of these stories to commit to

• Defines a Sprint Goal – a simple statement that captures the purpose of this sprint

For example, the Sprint Goal might be:
🎯 “Allow users to reset their passwords.”

Every user story chosen should contribute to that goal. The collection of these stories becomes the Sprint Backlog – basically, the to-do list for the sprint.

So when we say:

“The team selects an ordered list of user stories to comprise the Sprint Backlog for the next sprint, which will be achievable to satisfy the Sprint Goal...”

We’re really just saying:
👉 “Pick a realistic number of important tasks that, if completed, will help us hit our target for the sprint.”

Not too vague. Not too ambitious. Just achievable and focused.

☀️ Step 3: Daily Standups – Stay in Sync

Now the sprint is underway! But how does everyone stay aligned and avoid working in silos?

That’s where the Daily Standup comes in. Every day – usually in the morning – the team has a quick check-in (about 15 minutes) where each person answers three questions:

1. What did I do yesterday?

2. What am I working on today?

3. Is anything blocking me? (that is, am I stuck?)

Example:

“Yesterday I set up the login API integration. Today I’ll work on the UI validation. I’m blocked on getting access to the staging database — may need help.”

These standups keep the team in sync and surface blockers early so they can be addressed quickly. They’re not about micromanaging or showing off. They’re about visibility and support.

📉 What’s a Sprint Burndown Chart?

You might hear your team mention a “burndown chart.” No, this isn’t about things going down in flames (hopefully).

A Sprint Burndown Chart is a graph that shows how much work is left in the sprint – day by day.

• The y-axis is the amount of work remaining (often measured in story points or tasks)

• The x-axis is the number of days left in the sprint

The line should ideally trend downward as work gets completed – hence “burning down.” If it flattens out or slopes up, that’s a red flag that the team might be stuck, behind schedule, or not updating the board.

Think of it as a visual heartbeat of the sprint. You can learn more via a practical example in this video.

🖥️ Step 4: Sprint Review – Show What You’ve Built

At the end of the sprint, the team holds a Sprint Review (also called a “demo”). This is where you show what was actually built during the sprint.

• The Developers demo working features – live, not just screenshots

• The Product Owner reviews whether the Sprint Goal was achieved

• Stakeholders may ask questions, give feedback, or suggest tweaks

This meeting isn’t just for show – it’s a feedback loop. It helps the team validate that what they built is useful, usable, and meets expectations. If changes are needed, those get added to the backlog for future sprints.

🔍 Step 5: Sprint Retrospective – Look Back to Move Forward

Once the review is done, the team shifts focus from what they built to how they worked together.

Enter the Sprint Retrospective – a meeting to reflect on the process, not the product.

The team discusses:

• ✅ What went well

• ❌ What didn’t go so well

• 🔁 What could be improved next time

This isn’t about pointing fingers. It’s about learning, adapting, and continuously improving how the team collaborates.

The Scrum Master often facilitates this meeting and helps turn feedback into action items for the next sprint. For example:

“We underestimated testing time. Next sprint, let’s budget for QA earlier.”

The best teams take retros seriously. Why? Because even if your code is perfect, your process needs tuning too – and small process changes often lead to big gains.

♻️ Scrum Is a Loop

Here’s the rhythm:

1. Plan the sprint

2. Check in daily

3. Build and demo the product

4. Reflect and improve

Then do it all over again – with slightly better coordination and slightly more trust each time.

It’s not about being fast. It’s about being intentional, consistent, and collaborative.

Example Sprint

Let’s say, for example, that your team does 4-week sprints. (Keep in mind that Sprints can differ by team, nature of product, release cycles, and so on.)

Here’s the rough beat:

Scrum works in loops. Every 2-4 weeks (depending on your cadence and sprint cycle), your team should have working, demo-able software to show for it – even if it’s small.

And no, it’s not about “speed.” It’s about consistency, communication, and collaboration.

Who attends the Ceremonies:

Now lets dive deeper and understand practically how each of these ceremonies work:

Standups: Where You Talk Like a Human, Not a Robot

So how does the team actually stay connected day to day? That’s where standups come in.

Every morning, your team meets briefly – usually on Zoom or in a circle – and you answer 3 questions:

1. What did I work on yesterday?

2. What will I work on today?

3. What’s blocking me? Any impediments?

Example:

"Yesterday I cleaned up the signup validation logic. Today I’m working on the email verification flow. I’m stuck on SendGrid config – might need help setting up credentials."

It’s not about impressing anyone. It’s about keeping everyone in sync. Some days you’ll say, “I spent the whole day debugging a CSS bug that turned out to be a semicolon.” That’s okay.

How does it work?

The Scrum Master gathers everyone in a huddle room, the PO and Dev Team included, and opens the the Standup. They are the facilitator of the ceremony. Everyone gets a chance to answer the 3 questions above (usually about 2-5 minutes each). It’s not a full report – it’s quick. When one person is done, they pass it on to someone else.

This ensures there is team cohesion and transparency.

Here is a video example of a standup.

Sprint Planning

The goal of the planning meeting is to answer the questions “What are we going to work on, and how are we going to do it?” It is critical for the team to have a shared goal and a shared commitment to this goal before beginning this ceremony.

Participants should:

• Measure growth

• Sync with the Scrum Master

• Sync with the Product Owner

Sprint planning happens just before the sprint starts, and usually lasts for an hour or two. In this meeting, the team goes over a collection of user stories and discuss, plan, measure, and prioritize. This is where they decide what is going to be in scope for their upcoming sprint cycle.

The Product Owner will have a prioritized view of things in the backlog. They work with the team on each object or customer experience. Together, as a group they go through and make calculations, deciding to what they can commit.

What’s a User Story and Why Does It Sound Like a Children’s Book?

So you might be wondering: how do you know what to work on? What to build? So much work, so little time? Thats where user stories come in.

In Scrum, teams don’t just write vague tasks like “code the login.” Instead, they write user stories – short, human-centered feature descriptions that describe what the user needs, why they need it, and what success looks like.

Here’s an example:

As a user, I want to be able to reset my password, so I can access my account if I forget it.

User stories are the scaffolding of teamwork. They’re written with empathy, not just efficiency. And each one comes with acceptance criteria – a checklist that clarifies what “done” actually means:

• A “Forgot Password” link is visible

• Clicking it shows a form

• An email gets sent with a reset link

Once a story is agreed upon, developers break it down into tasks, like “build form,” “hook into backend,” or “handle email validation.” It’s collaborative, not prescriptive. And user stories have priority so you know what’s the most important and what’s the least.

A helpful rule of thumb many teams use is the Gherkin-style "Given–When–Then" format:

• Given some initial context

• When an event occurs

• Then a specific outcome should happen

This ensures that everyone – devs, testers, and product owners – shares the same understanding of behavior and expectations.

Here is a great video example thats outlines how to draft effective and powerful user stories.

What Counts as “Done”? Definition of Done and Why It’s Important

Now you might be wondering – how do I know when a task is done and can be closed out?

The Definition of Done is a type of documentation in the form of a team agreement. The Definition of Done identifies the conditions that need to be achieved in order for the product to be considered done (as in potentially shippable).

This is how we know that we "did the thing right". Meaning, we built the correct level of quality into the product. The Definition of Done is not the same as the acceptance criteria, which are written by the product owner to help us know we did the "right thing".

Every team has a Definition of Done – it’s not just “I pushed code.” It could mean:

• Code is written

• Reviewed by a peer

• Merged into main

• Tested on staging

• Possibly deployed

This clarity keeps teams honest and accountable. No “it works on my machine” energy here. The DoD sets a quality bar. It prevents ambiguity, rework, and “it works on my machine” moments. When every card on the board passes the same finish line, teams move faster – and trust each other more.

Everyone should know what done is in a team. Either its Done as per DoD standards or its not.

Here is a beautiful video highlighting the impotence of DoD.

Demos, Retros, and Saying the Hard Things

Once you’ve built the product, then comes demos (showcasing your work) and retros (analysis as a team on what when well and what areas to improve on).

In the retro, everyone’s encouraged to speak up:

• What went well?

• What didn’t?

• What should we try next time?

Example:

“We missed a lot of stories because we didn’t account for testing time. Maybe we buffer next sprint with fewer tasks.”

The goal is not to blame – it’s to improve. Over time, this feedback loop becomes gold. The Scrum Master usually facilitates, collects feedback (via tools like Parabol, Miro, or sticky notes), and helps turn insights into actionable experiments for the next sprint.

Over time, retros become the heartbeat of team evolution.

Here is a video highlighting the importance of a Retro and Sprint Review.

🧠 Why Retrospection Matters More Than You Think

The Sprint Retrospective is more than just another meeting. It’s a mirror for your team – a safe, structured space to pause, reflect, and improve together.

You discuss:

✅ what went well

❌ what did not go well

🔁 what could we do better next time

Great teams don't just deliver great software, they continually deliver better ways of working.

This is why many experienced Scrum practitioners consider the retro to be the most important event in Scrum. Code is deployed once, but process improvements grow exponentially, sprint after sprint.

Tools You Might Encounter

Scrum doesn’t require software, but real-world teams use a variety of tools:

• Jira – Tracks sprints, issues, velocity

• Trello – Simple board, good for small teams

• Slack – Where standups often happen if async

• Notion / Confluence – Docs, retros, notes

• GitHub Projects – Lightweight planning for devs

Don’t worry if you’re not fluent in these yet. They’re tools – you’ll learn them on the job.

If You’re Preparing for a Job, Here’s What You Can Do

• ✍️ Practice writing user stories from your side projects

• 🧪 Run a mini-sprint: Plan your weekend project, set goals, and “review” it at the end

• 🤝 Contribute to an open-source project that uses Scrum or Agile workflows

• 🧾 Write about what you learned – maybe as a tutorial (hint hint)

Final Thoughts

So to recap, Scrum is a simple yet powerful way for teams to work together, stay organized, and deliver results quickly. It runs in short cycles called sprints, where the team plans what to do, checks in daily, shows their progress at the end, and reflects on how to improve.

The four key ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective – help keep everyone aligned and focused. With clear roles and regular feedback, Scrum makes it easier to handle changes, solve problems early, and continuously get better as a team.

But scrum isn’t a magic spell. It’s just a way for humans to build complex things – together – without falling apart.

You don’t need to be a Scrum Master. You don’t need a certification. But if you understand how sprints work, what’s expected of you, and how to show up to meetings with clarity and candor, you’re 10 steps ahead of most.

Scrum helps teams talk, plan, build, and learn. And now? You can too.

If you liked this, please do share. You never know who it might help out.

Until then…keep learning, unlearning, and relearning!!!

If you've ever managed a software development pipeline—or have plans to do so—there's one thing you'll need to prioritize above almost all else: speed.

No matter the type of software you're working on, you'll always be under pressure to speed up your team's deliverables.

Some of that pressure might come from project stakeholders who lack an understanding of how software development works. Sometimes it's because your management team or client fears a competitor will beat them to the punch.

No matter the reason, though, you'll need to know some strategies to speed up your team's cadence without compromising code quality or security.

Doing so isn't as difficult as you might think. All you need to do is to put the right procedures in place and back them with the right technology. To help, here are five tips designed to help software development teams work as quickly and efficiently as possible.

By implementing all of them, it's possible to maintain a quick deliverables pace without sacrificing a thing. Let's get started.

1. Create a Detailed Roadmap and Stick to It

Perhaps the most important thing a development manager can do to keep work flowing smoothly through their team's work pipeline is to take the time to create a detailed development roadmap for every project before work begins.

An effective roadmap delineates all of the major steps required to complete the project and assigns major parts of the work to specific team members at the outset.

This is a step that many software development managers hurry through—believing that every minute spent planning and not coding is a minute wasted.

Nothing, however, could be further from the truth. By making major decisions about the development process in advance, the team won't have to break stride later on. Plus, the process of building the roadmap will often uncover hurdles that would have brought work to a screeching halt mid-stream.

It's always better to clear the road ahead before getting to work if you want to keep a software project moving forward at a high rate of speed.

2. Set Work-in-Progress Limits

Image source: NicoElNino / Adobe Stock

These days, most software development pipelines conform to the Kanban or Scrum project management methodologies. And even those that don't still tend to include some form of a Kanban-style board to track project tasks at various stages of completion.

Those work-in-progress (WIP) items help managers maintain visibility into their team's progress and capacity to handle more work.

The trouble is, “scope creep” often sets in, and it's quite easy for a development team's WIP list to get out of hand in a hurry. When that happens, team members will try to multitask, hopping between various WIP items to try and clear the backlog. When they do, it's common for the team's pace to slow to a crawl and for errors to begin creeping into the code.

The problem is that despite many programmers' beliefs to the contrary, humans don't multitask well. The solution, in this case, is to prevent them from trying.

Setting hard limits on the number of WIP items allowed in each stage of the workflow is an excellent way to do that. Doing so guarantees that team members won't bite off more than they can chew and will get more tasks done in less time than they otherwise would have.

3. Centralize and Automate Secrets Management

A software team working quickly can churn out great apps, but it's often at the expense of security. This is especially true for teams working with an array of servers, services, and containers spread over multiple disparate systems.

In those situations, most development teams will designate a single person to manage access to all of the necessary systems and data. However, that creates a bottleneck, since all access requests must flow through that person, and developers can't always move forward until they receive the necessary credentials.

The solution to the problem is to centralize and automate access provisioning and access revocation, and to automate it to the greatest extent possible.

There are a variety of open-source tools that can help facilitate that, and a variety of cloud-based secrets management solutions as well.

One of the most well-known examples is the open-source solution HashiCorp Vault. However, it's not the easiest solution to get up and running with. For some development teams, installation and configuration of the system itself are difficult enough to dissuade them from using it.

It is also worth noting that developers using Google or AWS as a development platform can make use of their respective secrets management tools. They're purpose-built to integrate with project development taking place on those platforms. That means they're typically easy to integrate into workflows without much hassle.

Or, for development teams working in multi-cloud environments, a solution like Akeyless is often a good fit. Since it's API-based, it integrates with most types of secured systems developers depend on. And, since it operates under the zero-trust paradigm, it doesn't require developers to entrust their project's security to any third parties.

Once a project's up and running with Akeyless, the platform handles the rest. That leaves developers to focus on their work, with all secrets left outside the code, because Akeyless automates the generation and injection of secrets. This lets developers can worry less about security and more about getting their work done.

4. Don't Cut Corners to Bypass Code Problems

Any developer who's worked on a complex software project can tell you that there are always code problems that crop up throughout the development process without any obvious solutions.

In many cases, development teams resort to quick and dirty fixes to solve such issues so they can move on quickly. This is how your project can amass a mountain of technical debt in a hurry, and it will come back to haunt the project in the long run.

If overall development speed is your goal, it's better to take the time to find real solutions to problems as they come up. Even if you need to halt development periodically to do so, you'll save more time in the long run by doing things this way. This is because the true consequences of a cut corner may not become evident until later in the development process, when it may be all but impossible to fix.

It's better to build time for code refactoring and other housekeeping steps into the development roadmap in advance to avoid ending up in that situation in the first place.

5. Set Aside Inviolable Deep Work Time

According to a recent survey, the average software engineer only manages to squeeze about 10 hours of so-called deep work time into the average workweek.

The key reason is, most developers have to deal with an avalanche of interruptions that break their coding rhythm and eat up their time and attention. From sudden code review requests to unsolicited client feedback, there's no end to the things that can force a developer to drop what they're doing and divert their attention elsewhere.

A savvy development manager can help the situation somewhat by letting team members set specific time blocks aside as inviolable deep work time. It means letting the team member lock in and running whatever interference is necessary to prevent their interruption.

For remote teams, this is as simple as allowing the team to disconnect from chat apps and email for the duration of their work block.

In-office teams have to work a bit harder to do this. In an office setting, it will be up to the development manager to intercept any and all incoming requests that would otherwise reach the team and disrupt them. It may require putting their foot down to higher-level managers or even clients.

The key is to clearly state why interruptions aren't allowed and tie it to meaningful productivity metrics. Anything to get the message across that leaving the team to their work is essential.

Or, if those things won't work, it could be worthwhile to authorize a rotating work-from-home policy to let team members escape the office to get meaningful work done.

The Takeaways

The five tips detailed here work wonders to remove common software development stumbling blocks and other procedural time-wasters that can slow down task completion. Together, they should enable a development team to make quick and steady progress on a software project with a minimum of unexpected slowdowns.

Of course, reality dictates that no roadmap is perfect and that expecting the unexpected is always par for the course. But by addressing the bottlenecks and slowdowns that tend to affect every software development project, you and your team will make the most of their time and maintain a pace that other developers would envy.

Feature image licensed via snowing 12 / Adobe Stock

This article will explain:

1. Who should use a ROM
2. When to use a ROM
3. How to calculate a ROM
4. Simple example of a ROM

Who Should Use a ROM

Project Managers use rough orders of magnitude to determine initial cost ranges for upcoming projects. Many organizations and most software organizations use project managers to lead projects.

Their role involves leading their project team, defining the goals of the project, reporting on the progress to the company stakeholders, and seeing the project through to completion.

man with blank stare listening to man trying to explain something

Who else can use a ROM? You! 👊 As you'll see, the concept of a ROM is very simple to grasp and can be useful in myriad circumstances.

When to Use a ROM

ROMs are extremely important for project managers in the early stages of a project's planning. They're used to decide whether or not a project is going to be feasible or not.

Rough Orders of Magnitude can be used to prepare a project business case (an analysis of the potential benefits of the project) before a project is committed to.

How to Calculate a ROM

Calculating a ROM is pretty straightforward. It is meant to provide a range of the possible cost of a project and you can find it using the following formulas:

Lower Bound = ROM Estimate x 0.75

Upper Bound = ROM Estimate x 1.75

Fred Flinstone counting on fingers

During the planning phases of a project, the project manager can come up with an estimate of the costs involved. From here, using the above formulas, they can then calculate a lower boundary in case the project ends up being less expensive and an upper boundary in case it goes over budget.

Since it is helpful to have more room on the upper boundary to avoid running out of funding if it does go over budget, the rough order of magnitude's upper boundary is considerably higher.

ROM Example

You've probably calculated a ROM without knowing it. 💡

Say you're going to the movies with a friend. You figure there will be ticket costs plus refreshment costs. Maybe $20 a ticket since you're going to the latest Nolan IMAX film and then another $30 a person since popcorn is more expensive than steaks at the movies.

This puts you at $100 total for both of you.

The Lower Bound in a ROM calculation would be $100 x 0.75 = $75.

The Upper Bound would be $100 x 1.75 = $175.

You probably don't do this exact math in your head, but you likely have figured there could be extra expenses. You go into the date thinking you could spend as much as $150, for instance.

Angry Bird eating popcorn at movies

Conclusion

Rough Orders of Magnitude are extremely important in organizational projects. It is vital to decide at the onset whether or not the project is feasible. And the principals behind ROMs are both common sense and easy to calculate.

I hope this has been helpful to you!

You can find and follow me on LinkedIn. I'd love if you said hey! 👋

I've wasted hours on projects in the past due to a lack of organization, processes, and general good practices. So this time I wanted to sharpen my project management skills in a way that would be replicable for my future self.

My perspective is particularly honed because I've worked for many years as a small business operator. I had to source contract and agency work before getting into web development myself.

The premise of this kind of one-man-shop project management comes from Brett at DesignJoy:

Below are some lessons learned after I implemented this over the course of a few weeks.

1. Organization is key
2. Time restraints are tricky
3. Deliver on time
4. Define the scope
5. Define the process
6. Test, test...and keep testing
7. Polish is important
8. Results matter most
9. Previews are good
10. Let the client lead when possible

Organization is Key

Prior to Trello, I was doing a combination of email, texts, and Google chat. That's fine when you're starting out and have one client at a time. But having one place where all communication about a single project lives saves time and effort.

Clarity on the order of events was incredibly helpful too. I set up lists where different tasks would live:

• Directions, assets, and general information in the first column
• Task queue in second column
• Active work in third column
• Work ready for client review in fourth column
• Approved work in the fifth column

It's a very simple but effective setup that allows for asynchronous communication (I have had zero phone calls so far) and a clearly defined pipeline for requests/work/review.

I grant the client full access to the Trello Board and they're able to rearrange the queue such that the work that needs to happen first gets put at the top.

From there, I grab the top item, and work on one thing at a time in active work. This is valuable for the client to see what I'm working on. And, bonus – it's incredibly helpful for people like me who are easily distracted from one task by wanting to go do another one "real quick".

Time Restraints are Tricky

Hot take: don't set time restraints unless you have to. Often I resist the urge to add a note about timing for delivery. It's common to do this when talking to people, but unless I'm asked for a scope of delivery, I leave this off.

This allows me room to expand on design work, try out different implementations for coding, and not be crunched on non-time sensitive items.

Deadlines are just tricky. A lot of times you have to move them after you set them. And a lot of times they're arbitrary to begin with. I avoid them unless I have no other choice.

That said, if you're not disciplined enough to put in the hours without them...you may need to have a few. 😂

Deliver on Time

It's unlikely that you'll have zero time restraints, though. Otherwise, the project may drift on in perpetuity. And then, caught in its numbing undertow, you'll turn around in 6 months only to realize how little you've progressed and how much anxiety lingers under the surface as a result of a lack of closure.

You don't want this. 🚫

So, when you do have a deadline, deliver before it. Give yourself some room so that you can likely deliver ahead of schedule, and at the very least deliver on time.

Define the Project's Scope

What are we building? What are the guardrails? Is it a marketing page? Is it an ecommerce site? Will it require skills beyond my knowledge? There are many questions like these to answer up front.

Starting out, it's easy to want to say yes to any and everything. And in most cases, go for it! There were a couple things in my last project that I had to research and figure out mid-stream.

But, try insofar as is possible to define the scope up front so that you can structure your project well and have a good idea of what it will take to get from start to finish.

Your client may or may not know their own scope. You will be a very helpful resource for them throughout the process, especially if they are not technically proficient.

Define Your Process

This is where Trello really helped me with some of my natural weak spots. Organizing the board and setting it up to be as simple as possible for both of us really paid off as we worked together.

At the onset, I built a template card with instructions. This both defined the process for me, and gave a reference for my client.

The process of working on tasks throughout the project was extremely straightforward and left little room for confusion. On tasks where explanation was needed, screenshots, notes, and checklists were available to box up issues into containers.

Test, Test, and Test Again

You can never test enough, and there will likely be things that slip through anyway. At least that's been my experience! Always test on mobile devices and not just the Chrome Dev Tools.

I broke some image gallery functionality and didn't realize it until client sent screenshots from his cell phone.

Not ideal! 😅🤦‍♂️

Polish is Important

Get the meta tags and favicon stuff right. Depending on the platform you're developing on, this may be done for you, but just make sure you've taken care of it before launch. It's easy to overlook things like this.

If you're doing these yourself, I found some helpful tools to generate and test them:

• https://metatags.io/
• https://realfavicongenerator.net/
• https://socialcarding.com/
• https://developers.facebook.com/tools/debug/
• https://cards-dev.twitter.com/validatorst

Results Matter Most

I overrode some Bootstrap 5 CSS in my main.css. I tweaked an npm package. Your client doesn't care what you do, or about the perfect best practices. Results matter most.

Don't break stuff, but that aside, you may bend some rules to simplify things if you need to.

Your client wants you to do awesome. Concern yourself with the best way to get them the results they desire.

Previews are Good

Clients are not always technically savvy. Descriptions, screenshots, and so on are often insufficient for them to grasp and approve what you're working on. Be able to send them a working preview build when possible.

I developed this project using GitHub for my codebase and Netlify for deployment. Deploy previews are a built in feature at Netlify, and you can share URLs based on pull/merge request numbers. That way, if there is a working site up and running, the client can preview changes separately.

Let the Client Lead when Possible

Hold your feelings and opinions loosely. This is their project, not yours. It's easy to get that backwards.

But the client is in charge and knows what they want even if they don't know how to get there or even how to describe it.

Part of our job as developers is coaxing that out of them by using the tools we are proficient with. Communication, organization, and teamwork are equally or more important than our technical toolkit.

As a freelancer, we are valuable assets to their business and should be pointing toward serving them well during the course of all our work.

Let them lead when possible.

Make suggestions when asked or when it's necessary.

But be helpful above all.

Empathy 😊 is the name of the game.

Master this and the coding will often be the easy part.

Thanks for Reading 👊

I hope this has been helpful for you!

Come say hey 👋 over on Twitter: https://twitter.com/EamonnCottrell

So if you have been working as a PM for a few years, this guide will show you how you can take the next step.

I'll cover exam costs, degree requirements, experience requirements, and share some study resources, too.

How much is the PMP exam in 2022?

This varies from country to country. I created this table of exam prices for several major countries:

+--------------+----------------+
|   Country    | PMP Exam Price |
+--------------+----------------+
| USA          | $555           |
| Canada       | $555           |
| Australia    | $719           |
| New Zealand  | $719           |
| UK           | £339           |
| Ireland      | €399           |
| South Africa | R5999          |
| India        | INR 35000      |
+--------------+----------------+

What is the total cost of PMP certification?

In terms of money, it's US $555. But keep in mind, passing the PMP exam will also require preparation. Exam prep programs cost between $600 and $1,200.

And then there's the real cost: time. You have to earn a considerable amount of work experience before you are qualified to sit for the exam.

Is a PMP worth getting?

This ultimately depends on your career goals. Do you plan to make Project Management your long term career?

If so, Project Management Institute (PMI) certifications like the PMP may be required for you to continue to get promoted. And getting promoted is probably the surest path to salary increases.

So from where I'm sitting, it seems like an easy decision.

Does PMP certification increase salary?

Yes. In the US, certification is tied to new potential job roles. Here's a table of median wages:

+---------------------+---------------+
|      Job title      | Annual salary |
+---------------------+---------------+
| Project Manager I   | $83,000       |
| Project Manager II  | $96,063       |
| Project Manager III | $115,000      |
+---------------------+---------------+

This information comes straight from the PMI (who oversee PMP certification).

And PMI says that PMPs in Pakistan, Egypt, Saudi Arabia, and New Zealand have experienced even more dramatic salary increases than that.

Who is eligible for PMP? How many years of experience do you need?

In order to sit for the PMP exam, you have to be a Project Manager who meets the following qualifications:

1. A four-year degree
2. 36 months worth of experience leading projects
3. 35 hours worth of taking formal project management training, or earning the CAPM Certification

That's 3 full years of working as a project manager.

But wait – what if you don't have a 4-year degree? Is there is an alternate path.

Can you get PMP without a degree?

Yes. Thankfully, PMI allows people who didn't earn a 4 degree to still get PMP certified. It just requires an extra 2 years worth of project manager experience. (5 years total.)

Here are the exact qualifications:

1. A high school diploma or an associate’s degree or equivalent. In the US, this would be a GED.
2. 60 months worth of experience leading projects
3. 35 hours worth of taking formal project management training, or earning the CAPM Certification

How do I start preparing for PMP?

I recommend you create a study plan, and schedule out exactly what you're planning to learn in what sequence. Be realistic. This is not an easy exam, and you will probably want to over-prepare.

You can review PMI's official PMP Exam Content Outline PDF.

I also recommend reviewing this free PMBOK Exam Tips PDF book. Note that this is from 2014, but it is by far the most comprehensive guide I could find. If you find a better free guide, send it to me and I'll update this.

Finally, take practice exams and review your results periodically. This will help you identify areas you can improve upon.

Is the PMP test hard?

Yes. This is a serious exam that will require serious preparation. Again, you can review its contents through PMI's official PMP Exam Content Outline PDF.

This said, if you have been working as a project manager for the past 3 years (or 5 years if you don't have a 4-year degree), I imagine you'll have plenty of exposure to most of these concepts. So exam prep may be more of a review for you.

Is PMP only for software?

The Software industry is a a massive employer of PMP-certified project managers. But it is far from the only one.

Earning the PMP can help you find project management work in a variety of fields. Major employers include the construction industry, manufacturing, and non-software engineering projects.

Should I get CAPM before PMP?

You do not need the CAPM in order to take the PMP. But if you have the CAPM, it will save you from having to get the 35 hours of formal project management training required to sit for the PMP.

Go forth and actualize your project manager career goals

I hope you've found this helpful. If you want to learn more about programming and technology, try freeCodeCamp's core coding curriculum. It's free.

PMP stands for Project Management Professional. It's a designation awarded by PMI to people who successfully complete the PMP exam.

The exam tests your knowledge and understanding of the project management framework and how to apply it in a real-world setting.

This is only one of the 8 certifications offered by PMI, and is often the first certification a project manager will get. Some other popular certifications include:

• The Certified Associate in Project Management (CAPM)
• The PMI-ACP (Agile Certified Practitioner)
• and the PMI-PBA (Professional in Business Analysis)

What is the history of the PMI?

The Project Management Institute (PMI) is a global professional association for project managers. PMI was founded in 1969 and is headquartered in Newtown Square, Pennsylvania, United States.

As of March 2018, PMI has more than 700,000 members and credential holders in more than 195 countries.

Who is eligible for PMP certification?

To be eligible for PMP certification, you must have a minimum of 4,500 hours of project management experience and a high school diploma (or equivalent, such as a GED in the US). You must also pass the PMP exam.

Is the PMP exam hard?

The PMP exam is considered to be challenging, but not impossible. If you are well-prepared and have a strong understanding of the project management framework, you stand a good chance of success.

Is PMP certification equivalent to a degree?

PMP certification is not equivalent to a degree. A degree typically requires a greater time and financial investment than certification.

This said, both a degree and a certification can demonstrate your knowledge and expertise in project management.

What are the Benefits of PMP Certification Training?

There are many benefits to PMP certification training. PMP certification is globally recognized and demonstrates that you have the experience and education to lead and manage projects.

PMP certification also gives you access to a network of other certified project managers who can provide support and guidance, and it can help you earn a higher salary.

Is it worth getting a PMP certification?

There is no one-size-fits-all answer to whether or not PMP certification is worth it. It depends on factors such as your career goals, work experience, and employer's expectations. However, in general, PMP certification can be beneficial in terms of career advancement and earning potential.

The certification is globally recognized and can help you advance their career in project management.

What are the Different Types of PMP Certification Training?

There are several different types of PMP certification training available to help you prepare for the PMP certification exam. You can find online courses, in-person courses, and online practice exams, among other resources.

The type of training you choose should be based on your learning style and the time you have available to prepare for the exam.

• Online Courses: Online PMP certification training courses are convenient and allow you to learn at your own pace. You can usually find online courses in a variety of formats, including video, audio, and text. You can also find online practice exams to help you prepare for the actual exam.
• In-Person Courses: In-person PMP certification training courses are often more expensive than online courses, but they offer the benefit of being able to attend live lectures and get feedback from instructors. You can also get more hands-on experience with the material than you would from an online course.
• Online Practice Exams: Online practice exams are a great way to prepare for the actual exam. These exams are usually based on the PMP exam content outline. They can help you identify your strengths and weaknesses. You can also find online practice exams that are specific to the type of PMP certification you are pursuing.

The type of PMP certification training you choose will depend on your learning style and the time you have available to prepare for the exam. You can find online courses, in-person courses, and online practice exams to help you prepare for the PMP certification exam.

How Much Does PMP Certification Training Cost?

The cost of PMP certification training can vary depending on where you take the course and how long the course is. Expect to pay between $500 and $1,500 for a course that is between 35 and 40 hours long.

Where to Find PMP Certification Training

Some popular providers of PMP training include the PMI itself. You can also read the PMBOK (Project Management Body of Knowledge), a book published by the PMI.

There are also schools that provide training for the exam. And you may be able to find some free learning resources and YouTube channels.

Does freeCodeCamp.org offer PMP Certification Training?

Not yet. We may explore this in the future. For now, I recommend shopping around for courses through those providers I mentioned earlier.

If you are serious about becoming a PMP, know that it takes several years of hard work and study.

I hope you've found this helpful. If you want to learn more about programming and technology, try freeCodeCamp's core coding curriculum. It's free.

Have you ever thought about having your own open source project? I bet you have — you’re reading this article.

Maybe you are thinking about it right now. Maybe you came here to learn what to expect, what challenges you’re going to face, and how to deal with them. Well, you’ve come to the right place.

The following guide is based on my personal experience in owning an open source project. And I do mean owning – not just contributing to – an open source project. There is a big difference, and we’re going to learn why.

So let's get started with...The Ultimate Owners Guide to Open Source

Table of contents

• Intro
• What is Open Source
• Why Start an Open Source Project
• How to Start an Open Source Project
• How To Write Documentation
• How to Publicize Your Open Source Project
• How to Manage Issues and Pull Requests
• How to Automate Your Process
• Version management

First, A Bit About Me

My name is Jeb and I’ve been maintaining a few open source projects for a couple of years. The most popular one and the one from which I’ve learnt the most is @angular-builders. At the moment of writing it has ~900 stars on Github and about 1M monthly downloads.

Yes, it’s not even close to huge projects like Angular or React – but I feel that I have enough experience to share with you to help you avoid the same mistakes I made. And more importantly, to help you understand the cost of owning an open source project.

So What is Open Source?

Let’s first establish a common language and align on key terms and definitions.
What is open source? Here is a very generic definition from a well known Open Source Encyclopedia (aka Wikipedia):

Open source is the concept of the information allowing the replication or modification of something being open to the public.

or, in terms of software development models:

The open-source model is a decentralized software development model that encourages open collaboration.

A main principle of open-source software development is peer production, with products such as source code, blueprints, and documentation freely available to the public.

In the case of Wikipedia, we have those who edit the articles (contributors) and those who approve the edits (more experienced members, moderators).

If we project it onto the software world, the editors would form a core team of an open source project and the contributors would be, well, contributors.

Wikipedia is a huge open source project but it all started from something small. Wikipedia was born from Nupedia and it was created for a reason:

Despite its mailing list of interested editors, and the presence of a full-time editor-in-chief, Larry Sanger, a graduate philosophy student hired by Wales, the writing of content for Nupedia was extremely slow, with only 12 articles written during the first year.

So here’s where the first question comes into play...

Why Should You Bother With Open Source?

As you can imagine, one of the main reasons for opening something to the wider audience is to gain collaborators.

Together we’re strong.
(Zarya, 2016)

At the moment of writing this article, Wikipedia has 37,899,499 registered accounts of which 134,022 are actively editing.

Just think of it… 134,022 active collaborators. Oh, and it has 6M content pages!

Would the numbers have been the same if Nupedia didn’t move to an open source model? I highly doubt it.

Nothing is different when it comes to software. In order to solve a certain problem you have to write code. In order to solve a big problem you have to write a lot of code. And in order to solve it properly, you have to write high quality code, make a high quality design, and so on.

All this requires resources, which, let’s be honest, you probably don't have. You have a rent to pay, after all.

Why Start an Open Source Project?

While gaining collaborators is a reasonable incentive, almost no one starts a new open source project solely because of that. Your reasons might be different, but let’s talk about most popular ones.

#1 You want to solve a problem for which no free solution exists

You face a problem, but there is nothing out there that solves it for you (or there is something, but it costs money) so you have to solve it yourself. You manage to solve it, you’re really excited about your work, and you think others can benefit from it. So you open source the project.

#2 You want to be a founder

You want to be recognized as a founder of an open source project, and you want that fancy line in your CV. You have an ego (we’re all human, after all). If this is the main reason for you, then I promise you – after reading this guide you’ll reconsider. It’s likely not worth it.

#3 You want to solve a problem better than someone else does

You face a problem, and there is an open source project that actually solves it for you but it’s not good enough (in your opinion) or doesn’t have the exact feature you need.

If you create a new open source project solely because of this, then most probably you’re at #2 (ego). Make yourself a contributor, and create a PR to the existing project instead.

If the existing project has a different vision and making a PR is not an option, you should consider either extending it by reusing its functionality in your project or forking it. It may save you a lot of headache later.

#4 You want to solve a problem by creating an open source project

You face a problem and there is nothing out there that solves it for you. So you think that starting the solution as open source from the very beginning is a very good idea.

In my opinion, it’s not.

Solve the problem, make sure it works for you, and after that go to #1.

These are the four incentives I most commonly find for people creating a new open source project. But in this guide we’re going to focus mainly on scenario #1.

The reason is simple — I believe that if your main reason for starting an open source project is anything other than eagerness to share and contribute what you've made, then this won’t hold.

For quite a long time the fact that you’re helping someone might be the only reward you get. And if this is not the kind of satisfaction you’re looking for, then maybe you should stop here and not waste your time.

There is another quite popular scenario which is worth mentioning: there are companies that open part of their code to the community. Examples of this are Angular (maintained by Google), React (maintained by Facebook), VSCode (maintained by Microsoft) and more.

Their reasons may vary, but gaining collaborators and contributing to community are surely among them.

While I can’t argue with the importance of this practice, this scenario is quite different from the others because employees that maintain such projects get paid for their job.

If you work at a company that considers the possibility of creating an open source project, the majority of the content here will be still relevant for you, however the incentives might be different.

So should you create an open source project?

If I had to summarize this part in one sentence it would be:

Make sure your intentions match your expectations.

Believing that you want to have an open source project is not the same as actually having one, as you will see in the following chapters.

How to Start an Open Source Project

So you’re in scenario #1 – you have a solution for a specific problem and you’re eager to share it with the world. Let’s emphasize it again:

1. It’s not about your ego
2. You’re not hoping to benefit from it
3. You truly want to help others with the same problem

If you answered yes to all of these things, then here is a quick checklist for you to make sure you’re doing the right thing:

1. Make sure that open source is the right format. If it’s something small that you want to share with the world, then a blog post might be just enough.
2. Double check that a similar project doesn’t exist already. Maybe your solution makes a perfect PR for an established open source project.

Be prepared for what’s coming

As I mentioned, owning an open source project carries with it a lot of challenges.

One that stands out is that it requires a lot of your time. Everything that you do for your project requires time, whether it’s writing code, managing issues, updating dependencies, talking to people, answering questions, and so on.

Every minute that you invest into your open source is a minute that you could have but didn’t invest in your family, your hobby, your health and what not.

The only thing that you can do to make this better is to start delegating. When (or should I say “if”) you have enough collaborators, you can outsource part of your responsibilities to the people you trust.

Code separation

So here we go, you have a solution for your specific problem and you think others can benefit from it. It is still integrated within your code base and you probably don’t want to make the whole code base open source (unless you do).

First you have to separate this code from the rest of your code base.

…which will eventually mean that all the code that is going to be opened will reside in a separate directory.

Make the code generic

Make sure that the code in the new directory is generic and is not bound to your specific problem. Make an abstraction layer if needed.

As an example, I started angular-builders with a very specific need (coming from one of my other open source projects) of adding a custom loader for native modules to Angular build.

I could have created native-module-builder which would serve only this very purpose. However, I realized that at a relatively low cost I could create a more generic solution that would solve similar (but not the same!) problems.

This is how custom-webpack builder was born.

Keep it simple

Generic is great, but be careful not to get too excited about that.

Premature optimization and over-generalization are two very well known problems in software engineering. You should find this sweet spot where your solution solves problems other than yours but not all the problems in the world.

If you build a scale where the solution for your specific problem is 1 and a solution for all the world problems is 100 then you should start with 2.

Your generic code should be able to solve a a few more problems than your specific code.

Eat your own dog food

Keep using this generic code in your code base at every step — doing so makes sure you eliminate the unnecessary parts and leave only what’s needed. It also ensures that the code you’re going to open is working properly.

Remember, you are the very first user of your open source project.

Don’t get sued

If you’re extracting the code from your company code base, consult with your superiors and if needed with the legal department. Make sure that they support your initiative and that the code you’re going to open is not subject to the IP (intellectual property) of your company.

This will also help you to decide which open source license is more suitable for your project.

When everything is working, the code is separated and is generic enough, and you have all the approvals (if needed), then it is time to open it to the world.

Once your open source code is separated and generalized it’s time to disconnect it completely from your code base.

Go public with your code

First, you have to open the source code of your project (at the end of the day that is what makes it an Open Source Project!).

There are different options for hosting source code online, but we’ll go with the default — GitHub.

1. Create a new repo on GitHub
2. Clone the repository
3. Move the sources from the directory you previously created (don’t remove the directory yet).
4. Commit & push — voilà it’s now an open source project.

Or is it?

Create a package

Your project is publicly available, but no one is using it (including you, since you’re using a copy of this code within your larger code base). And no one is aware of its existence.

Furthermore the only format in which your project is publicly available on the web is the source code. And the only way to consume it is copy-pasting the code into a code base. Not a very convenient way, right?

In order to properly distribute your project, you have to:

1. Create a package out of the source code
2. Make this package available on one of the public package registries (depends on your ecosystem, for example, for Java it might be Maven Central Repository, in the case of JavaScript it might be Npm Package Registry and so on)

This is when you add a build chain to your new shiny repository, define your project's name, and more.

I’m not going to break down the whole process because it is very dependent on your ecosystem, set of tools and language you are using.

You might be an all around person to whom defining a new project as well as adding a build chain and publishing the package is a piece of cake. If this is the case — good for you!

You also might be a person that is used to only writing code but has never faced all these definitions, configurations, artifacts and stuff like that. It might be a whole new world to you.

If you're that person, it's time to learn. Not going to be quick, I promise you that, but we'll get there.

In any case...

When you’re done filling in all the missing puzzle pieces in your head, you’ve learned everything about the relevant package registry, and your package is actually published, then and only then can you truly consider your project open source.

At this point you can actually tell people: “Hey, I already have a solution to your problem, just add this package to your project and use it!”

Perform a sanity check

Before your project goes viral, make sure it works.

A sanity check for your package would be actually removing the generic directory from your larger code base and use the publicly available package instead.
After all, you’re the very first user of your open source project.

How to Handle Further Development on your Code Base

When you start using the package in your code base, the development flow is likely to change. Previously, the now-open-source-code was part of your code base – you could consume the changes right away.

But now it’s as much of an external package as any other 3rd party package used in your code.

Thus, when you develop a new feature in your shiny new open source project, you’ll have to publish it first in order to be able to consume it in your larger code base. However you cannot publish it if you aren’t positive it works, because once published it might affect other users.

So here are a few things you can do in order to avoid publishing broken versions:

1. Cover your code with tests, both unit tests and end-to-end tests.
   I don’t think I have to convince you how important the tests are.
2. Package and install the new version of the package locally, into your larger code base.
   Once verified that everything works as expected, you may publish it.
3. Publish a beta version which is available only to those who explicitly want it rather than to the whole world.
   For example in the npm package registry there are dist tags that can be used for this purpose.
   The default tag is _latest_ and when you run _npm install mypackage_ it effectively runs _npm install mypackage@latest_. When you publish a new version under another tag, for instance _beta_, people will have to explicitly install from this tag in order to get the latest version:
   _npm install mypackage@beta_ .

Wrapping it up

Unlike the previous part, which was completely theoretical, this part actually requires some work from you. Depending on your experience and learning abilities it might take you a few days or even weeks to complete this mandatory step. And we haven't even started yet.

This is why it is my duty to ask you again:

Are you fully prepared to give a decent amount of your precious time to the community?

How to Write Documentation for your Open Source Project

The first two parts of this article were targeted to those who are considering creating an open source project. I wanted to let them know what to expect and give them a head start in the open source world.

This part, as well as the upcoming ones, will also be relevant to people who already maintain an open source project and want to improve at what they do.

The baseline for this part:

You already have an open source project, it is available on GitHub, and it can be consumed easily via one of the package registries.

Why Do You Need Documentation, and What Should It Contain?

An open source project without documentation is a dead project

It is dead because no one will dive into your code to find out how it should be used. And even before how, no one will even know what your code is supposed to do.

So these are basically the two things that your documentation should contain — what and how. These are the corner stones, the must-haves of documentation.

How to Write a Description of Your Project

The description is the first thing everyone sees when they enter a GitHub repository. Therefore a good description should answer in a short and informative manner the what question. For example:

React:

A declarative, efficient, and flexible JavaScript library for building user interfaces. https://reactjs.org

Moment.js:

Parse, validate, manipulate, and display dates in J_ava_Script. http://momentjs.com

Angular builders (this one is mine):

Angular build facade extensions (Jest and custom webpack configuration)

You can edit description in the About section of your repository:

How to Write a README.MD File

README.MD is a file in the root directory of your project, written with Markdown syntax, which contains all the information someone needs to know about your project.

The README file should contain a detailed description (which expands on the what question) and very detailed instructions on how to use you project.
The instructions should cover every single piece of public API, preferably with usage examples.

Here are a few points for writing a good API documentation:

• Keep it simple – The simpler the API and the example, the easier for a user to understand what it does on how to use it
• Keep it structured – Use the same template and visual structure for every API method. This way you’ll define your own language for communicating the API to the user.
• Be a user – Always write API description from the user's perspective. Assume that you know nothing about the internals and this documentation is all you have.
• Keep it up to date – As your project evolves, the APIs might change. Make sure that your README file always contains the most current APIs and examples.

The README can (but doesn’t have to) contain the following things:

• Link to a contribution guide
• List of contributors
• Link to a change log
• Latest version
• License
• Build status
• Downloads counter
• Link to a chat for fast feedback

Here is a an example for what a good README could look like.

What Are Badges?

Badges are a fairly good way to visually expose the essential info about your project, such as: build status, version, license and various tools used by your project.

There are quite a few options, but I’d recommend you use shields.io badges.
They have a badge for literally everything.

Adding a badge to your README file is really simple:

1. Go to shields.io
2. Choose the appropriate category
3. Click on a badge you’d like to add to your README
4. Fill in the required information (if any)
5. Choose Copy Markdown from a drop down menu
6. Paste the markdown into your README file

The badges are usually put at the top of the README file right before the detailed description. This is what it looks like:

Make Sure You Have Tests

API reference is great, but nothing compares to real code using your public APIs.

One of the best ways to complement your documentation is having good code coverage with descriptive tests. Sometimes tests explain the code better than any documentation.

Wrapping it up

In this part we’ve only covered the basics of documentation. There's a lot more than just a README or a description, for example. As your project grows and issues arise, they become an integral part of the documentation.

However, having a README file that covers the public API is the bare minimum for any decent open source project

How to Publicize Your Open Source Project

We’ve already discussed what it means to start a project, how to do it optimally, and how to write good documentation for it.

Now let's talk about drawing the public's attention to your project and optimizing it to both attract and correctly manage contributions.

The baseline for this part is:

You already have an open source project, it is available on GitHub, it's well-documented and can be consumed easily via one of the package registries.

How to Spread the Word About Your Project

Let’s address the elephant in the room: as your project grows, you simply wont be able to handle everything by yourself. So you'll need more people to work on the project if you want it to live long and prosper.

To get more people involved in your project you need more people to know about it and above all else to believe in it.

From my experience the best way to expose your open source to the right audience is to use one of the well known resources and write a blog post about your project.

The resource might be purely dev-oriented (like dev.to) or not (like Medium).

One commonality between all these resources is that they have an established audience and it is the relevant audience.

You can also cross-post your article between various online resources so that you cover an even larger audience. But be aware – cross-posting has a few downsides:

• Each of these platforms may have a different mark up language and you’ll have to redo all the formatting
• Maintenance — if something changes (and things will change) you’ll need to update your blog post across all of the resources.

If you go for Medium, I’d highly recommend you submit your article to one of the large publications. It will require additional effort on your end, since you’ll have to align your article with the publication's requirements. But it will also ensure that your article is exposed to a large and, which is even more important, relevant audience.

You can also decide to go behind a metered paywall (you can earn money from doing this!):

Stories that are part of the paywall are also eligible for distribution to Medium readers through topics, which power recommendations on Medium on our home page, on our topic pages, in our Daily Digest and in our apps

I can’t tell you which one is better, but my personal preference is publications because it ensures your article is exposed, instead of the vague “eligible for distribution” term.

If your blog post goes viral then it can create a cascading effect and add even more leads to your open source project.

For example, if after publishing the article your Github project received a few dozens of stars in one day it can get to the Github Trending page which is in itself another source of exposure.

A few points to make your blog post great:

• Start with a problem statement. It might even be the title of the blog post.
  Usually people are looking for a solution to a specific problem and before they decide to invest the time to read your post they should have an idea whether it’s what they’re looking for. Here's an example of an article I wrote.
  As you can see it clearly states the problem that it solves in the title.
  If you google “Customizing Angular build” this is one of the first _result_s you’ll get and right from the search page you can see which problem it addresses.
• Describe why and how exactly your project solves this problem
• Provide a detailed step-by-step guide, starting with installation and finishing with a working example.
• Create an example project that uses your open source and link to the sources in the blog post.
  There are lots of developers who prefer a working example to any blog post.
• Get some feedback before publishing it.
  Make your friends go over it without telling them what it’s about and see if they can figure it out themselves. If they can’t then probably it’s not that clear and you need to elaborate.

After you’ve published your blog post, make sure you share it on social media, with your friends, your family, and strangers on the street.

This will increase your project’s exposure – but you also have to make people want to contribute to your project.

How to Make your Project Attractive to Contributors

The best thing is to start an open source with other people. This way from the very beginning you have a team with which you can split the burden.

However, that’s not always the case.

If you started alone, you have to attract contributors. And in my experience there are two types:

1. Someone who wants to make an impact and looks for a project to contribute to (these are rare but still exist).
2. Someone that uses your package and found either a bug or lack of certain functionality.

In both cases just having your source code shared on Github and a single blog post on how to use it are not enough. Here are a coupe of things that can make people want to contribute:

Have a pending implementation list.

It might contain known bugs, planned features, or something else. This list will make it simpler for contributors of type #1 to pick the right item and issue a PR.
It can be a standalone list or you can (and probably should) use issues and labels on GitHub.

Have a contributors guide.

A very basic contributors guide should explain the repository structure and have a step-by-step guide for building and running your project and tests. The expanded guide can contain architecture, design decisions, code of conduct and more.

A good example is Atom’s contributors guide. Don’t underestimate it’s value! It’s something that takes a decent amount of time to make when the project has grown, and I wish I created it at the very beginning and updated it gradually as the project evolved.

Unfortunately, I didn’t have someone to point out its importance, and today my project has no contributors guide. It’s always on my TODO list but there is always something more urgent than that.

Recognize your contributors.

Listing your contributors on the main page of the project will give them additional incentive to make a contribution.

Just adding user names can be enough, but I’d recommend that you use All Contributors. Apart of creating a fancy section with profile images and badges for your all your contributors, it automates the addition of new contributors by creating PRs that add contributors to this section.

Wrapping it up

In this part we’ve discussed several things that will increase your project’s exposure and provide people with an initial incentive to open a PR or an issue.

But this won’t keep them as contributors, nor will it make sure they will finish the work they started.

How to Manage Issues and Pull Requests in Your Open Source Project

Now that we've explored sharing information and making your open source project more attractive, let's discuss contributions, the holy grail of every open source project.

What are open source contributions?

A contribution to an open-source project is any change that’s done by a person other than the owner. In practice it comes in two forms:

Issues

Here’s what Github says about issues:

You can collect user feedback, report software bugs, and organize tasks you'd like to accomplish with issues in a repository. Issues can act as more than just a place to report software bugs.

In a nutshell, an issue is any piece of information that requires some sort of action.

Pull requests (PRs)

Here’s what Github says about pull requests:

Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

In a nutshell, a pull request is an actual change to the project.

How to Work with Issues and PRs

So how do you actually work with issues and PRs, and how do you approach issues and PRs created by contributors?

Use a Personal Example

The best advice I can give you is to use a personal example to incorporate a certain work method. This means that when you’re working on a new feature you should create a PR for this and merge it once it meets all your standards.

And when you find a bug or think of some missing functionality you should create an issue.

Not only will this method organize your work and bring order to your project, it will also provide contributors with a reference from which they can learn and adapt their issues and PRs accordingly.

Additionally, if you have high standards (meaning that you believe that every PR should come with proper documentation, test coverage, and so on) then you should treat yourself just like you would any other contributor. You can’t demand from others something what you’re not doing yourself.

Moreover, sometimes you should be even more lenient towards the contributors than to yourself. Especially if your project is at an early stage and doesn’t have a lot of contributors. This brings us to the following point.

All Work is Appreciated

Collaborating with others is all about mutual respect. You should respect your contributors. Be patient when answering their questions (even ones that seem simple) and be polite when providing constructive criticism.

Remember: it’s vital to appreciate your contributors’ work. If someone just created an issue (even without thorough research, even without reproduction) — thank them. They bothered to move their chair a bit closer to the table, they sat up straight and typed something they thought could be beneficial to you. Thank them and if needed, ask for additional details in a polite and respectful manner.

If someone created a PR that doesn’t meet your high standards — thank them. Thank them and ask politely to make code changes/write tests/add documentation and so on. Give them a link to one of your PRs for reference or provide them with a link to the contribution guide.

A constructive and positive conversation will give those contributors additional incentive to continue their work. Or it won’t…

Quality Versus Quantity

Eventually, there’s almost always a tradeoff (unless you own a huge open source project, like Angular or React). You can decide that you’re not easing up your standards, not even for a little bit, and most probably you’ll end up implementing all of the work yourself.

Or, you can decide that you’re lowering the standards for contributors (but this would make your standards futile as they’re not applied).

I’ve learned that every contributor requires a different approach. It really depends on the person and their personal interest in their contribution.

You should take into account such factors as the urgency of the issue, the experience of the contributor, the complexity of your code, the complexity of the required fix or feature, the contributor’s motivation, and more.

Usually, I politely ask for changes, wait for a few days, and if nothing happens I make the changes myself, given of course that the issue is considerably important.
As for less important (nice-to-have) fixes or features — I usually leave them entirely to the community.

Over time as the number of issues and PRs grows it becomes an ambitious task to keep track of, prioritize, and categorize them. This means that labels become incredibly important.

Use Helpful Labels

Github labels is a great tool for keeping your issues and PRs prioritized and organized. While this allows you to search and filter by labels, what I find most helpful here is it’s ability to aid in the visualization of the overall state of your project.

Thus, you can enter the “Issues” page and see that most of your issues are labeled as bug(meaning that you should stop pushing forward and instead focus on fixing them.)

Alternatively, you can see that most of the issues are labeled as enhancement or required features. priority is another useful label that helps you focus on the significant things first.

Additionally, your contributors can (and will) benefit from you using labels. For example, going back to Getting collaborators, someone can enter the “Issues” page and visually identify the issues that require the help of the community (help-wanted, pr-welcome, and so on.)

Aside from the labels with single responsibility (like bug or enhancement ), I recommend using labels for scoping an issue/PR or putting it on a certain scale. For example:

• priority:low , priority:high
• required:investigation , required:tests , required:docs
• Or in the case of mono repo: packages:package1 , packages:package2 etc.

Here is an example of the labeled issues page from my project:

Labels make it pretty easy to distinguish at a quick glance what the issues are that require your (or your contributors’) attention, to which component these issues are related, and what is required in order to proceed.

Use PR and Issue Templates

I highly recommend that you spend a few minutes of your time and define templates for Issues and PRs.

With issue and pull request templates, you can customize and standardize the information you’d like contributors to include when they open issues and pull requests in your repository.

This will save you a lot of time since you won’t have to respond to each issue or PR with a request for additional information or changes. You’ll still have to do it sometimes (because there are contributors that simply don’t pay attention to the templates) but it will happen far less often than it would if you didn’t create templates.

Here is an example of a default issue that you see when the corresponding template is defined in your repository:

Use Github Apps and Actions

There are quite a few Github apps and actions that can help you manage PRs and Issues. The list constantly grows, but I personally find these to be most useful:

• Stale bot
• WIP
• Autoapproval
• PR labeler

Make Sure You're Responsive

If I open an issue or a PR to another open-source project and it takes an eternity to get a response, then I switch. Here is one example:

• The initial response was quite quick, taking only two days
• The discussion was pretty fruitful
• The PR is still open with no updates on what exactly is missing/wrong

As a result, I switched to another package.

The same will hold true for your project if you’re not responsive: if it takes you two weeks to respond to PRs that are waiting for you, instead of pending for contributor’s changes required by you, then you’ll lose users (i.e. potential contributors).

So do yourself a favor — be responsive. It doesn’t have to be an immediate solution to someone's problem but even letting the user know that you’ll look into their issue next week already gives them some certainty and time frames.

The bad news is that you should stand by your promises. If these get away from you from time to time, don’t worry — we all have personal lives and it’s understandable if you had some urgent matters which postponed your work on the open-source.

If this occurs then give a short update — it’s not a big deal, just write a word or two to let people know that the feature they’ve been waiting for has been postponed.

How to Prioritize your Issues

There are a few methods that can help you prioritize your most important issues.

First, how should someone identify the most important issues? As I see it, the most important issues are the ones that users want the most, whether it's a new feature, a bug-fix, or something else.

Sometimes a user will express their interest in the issue but most likely they won’t. Therefore, I present to you quite a simple way to know what users are interested in:

Every project on Github has an “Insights” tab, with a “Traffic” section:

At the bottom of this section you can find the Popular Content table which gives you insights into which pages are most viewed by your visitors:

The issues listed in this table are the most visited issues and therefore are most like to be important to the users.

When you have identified the most important issues you need to highlight them on the issues page. Here are a few ways to do that:

Pin the issue

You can have up to three pinned issue per repository. Pinned issues appear at the top of your issues page so it’s nearly impossible to miss them:

Add a label

We already talked about using the labels, and this is an excellent example for applying the help-wanted as well as priority:high labels. Those labels will let the potential contributors know that this issue is important and that any help is appreciated.

Continuous Integration

Having every Pull Request built and tested before it is merged into the master will give you a decent amount of confidence in the code you’re about to merge into your master branch (depending on the test coverage).

While I couldn’t but mention it as a part of the PR management process, it’s an automation of a task that otherwise you’ll have to do yourself, therefore it is not directly related to PR management.

You can still check out every PR, build it locally, run the tests, and merge if everything is green (therefore Continuous Integration is not directly related to the PRs management). Don’t worry though, we’ll cover it in detail in the next section.

Wrapping it up

It’s very important to keep your project clean and organized because — as we all know — cleanliness is next to godliness. Not only does it make the management process more effective, but it also improves the overall impression of your project.

PRs and issues (along with the codebase) are integral parts of your open source projects facade. Don’t underestimate their value.

How to Automate Your Process

A natural part of managing contributions (that is, issues and PRs) is automation — probably one of the most important aspects of OSS project management.

Why automate?

If there is anything I’ve learned over the years of owning an open-source system, it’s that the less routine work you have to do yourself the more free time you have for actual work (like fixing bugs and developing new features). Therefore, I seek to automate whatever I can.

Here’s how I’d like us to approach this aim: let’s first examine both workflows, (the non-automated and the fully-automated) to see how much of your time is actually put into routine tasks. We’ll then go into how we can achieve an improved workflow leading to more time to fix bugs.

Worst case — no automation

As you can see, in a case where nothing is automated, you do all the work. It is a lot of work just for a bug fix, and on top of that, this is the work that you’ll have to do every time there is a bug fix or a new feature!

Now let’s take a look at an alternate scenario.

Best case — everything is automated

In this case you only do what you have to do — inspect the code and (sometimes) approve the pull request. Everything else is done automatically.

Science fiction? No, it’s called continuous integration and continuous deployment. We’re not going to get into the details of building scripts and system-specific configurations here. Instead we’ll review the tools you need to make it work and I’ll let you decide on the specifics yourself.

What is Continuous integration (CI)?

Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project. The CI process is comprised of automatic tools that assert the new code’s correctness before integration.

A very basic CI run would include build and unit tests, however it is not limited to these two. It might also include all kinds of static code analysis tools, linters, and so on. This is where you define your standards.

Why You Should Use End-to-End Tests

Build and unit tests provide you with quick feedback for code changes, take a relatively short time, and fail quickly if something goes wrong. But end-to-end (E2E) tests have a special place in CI.

E2E tests should cover not just the correctness of the code but also your deployment flow, package integrity, and so on.

I myself realized this when I accidentally published a new version of a package that didn’t contain any code. The build has passed, the unit tests were green as well as E2E tests (those at a time were installed by linking the build output directory from the test project). Where did it fail? In the packaging phase.

A key takeaway here: E2E tests should test your packages as if it was used by a real user.

In order to achieve this I recommend the following:

1. During your CI run, start up a local package registry. Each language/ecosystem has a few options, for example for Java or Scala projects you have the Nexus Repository, and for JavaScript there is Verdaccio (which I’m using in @angular-builders)
2. Have a separate project that makes use of your package (this can reside in the same repo). The tests in this project should test your package’s functionality.
3. Configure this project to use the local package registry.
4. After your package is built, publish it to the local package registry (started up in your CI system).
5. Install the latest version of the package (that you’ve just published) into your test project.
6. Run the tests.

Not only will it test your package integrity and reliability, but it will also save you some work when it comes to continuous deployment.

How a CI System Works

There are plenty of CI systems that have a free plan for open source projects, among them Travis CI, CircleCI, AppVeyor, Github Actions, and others.

They are all more of the same and do basically the same in that they check out your code to a virtual machine, run a script that you define (usually run build and tests), and then report either a success or a failure to GitHub.

All of these systems have an app for integration with GitHub and the integration flow is pretty similar in all of them:

1. Register on the platform.
2. Install the corresponding app in your GitHub account.
3. Configure access to the selected repositories.
4. Create a configuration file (like travis.yaml ) that defines the build matrix, required build chain, and CI script.
5. Push it to the master

This will make your CI run on every PR and report the status to GitHub – but this isn’t enough. What you really want is to block the merge to the master branch until the PR has passed all the checks.

This is done by defining the branch protection rules. In order to define those, you should go to the “Branches” section in your repository “Settings” and press the “Add rule” button:

Then check the “Require status checks to pass before merging” checkbox:

As you can see, the corresponding Github Apps checkboxes already appear here, so the only thing that’s left is to enable them.

The exact build script really depends on your ecosystem, the language your project is written in, the frameworks you’re using, and more. Therefore we won’t cover it here — you’ll have to check out the documentation of the CI system yourself to get into specifics. However, you now have a pretty good idea of what CI is and how it automates your PRs, so let’s move on.

How Continuous Deployment (CD) Works

Continuous Deployment (CD) is a software release process that uses automated testing to validate if changes to a codebase are correct and stable for immediate autonomous deployment to a production environment.

In our case, the production environment is when a package is publicly available in a package registry. This is a point-of-no-return phase, as once you have published it you cannot un-publish it since this is publicly available (and hence potentially in use).

There are multiple strategies for continuous deployment which really depend on the project and its complexity. But in my opinion, releases should be made solely from a master branch as this makes the workflow pretty easy. Here’s how:

1. Each PR represents either a bug fix or a new feature.
2. The code is tested (including E2E) before it even gets to the master.
3. The master is a protected branch so as long as you don’t merge failing PRs the master stays stable.
4. Every PR merge to a master triggers a master CI run which eventually releases a new version.

This will ensure that all the releases are sequential and will make it really easy to associate certain PR with specific versions.

To automate package releases, we’ll need a few things:

1. Automatic version advancement based on commit messages.
2. Automatic CHANGELOG updates based on commit messages.
3. Automatic package publishing to a public package repository.
4. Automatic release on Github.

Good news everyone: all of these are already supported by semantic-release. Bad news: you’ll have to invest some time to make it work (but eventually it pays off).

How Semantic-release Works

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.

This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.

We won’t be covering the whole integration process here as they have very good documentation and there is no reason to recapitulate it here. I will mention a few points though:

• Make sure that you understand semantic versioning specification and the conventional commits format before you start with Semantic Release.
• To make semantic-release work well, you should enforce certain commit message formats. To do so you can run commitlint as a husky precommit hook. It will enforce conventional commits when someone creates a local commit, but it can’t do anything about commits that are performed directly from the GitHub web UI (which often happens when someone wants to make a quick fix to their PR). Therefore I recommend that you back it up by commitlint Github Action.

After you set up the semantic release as part of your workflow, you’re pretty much done and you no longer have to spend your time on these routine processes. Although there is one more optimization you can do.

How to Keep the Project Up to Date

If your project has no external dependencies — skip this part. However, most projects depend on other packages, and other packages tend to change.

Keeping your project up to date with its dependencies is important but it is time-consuming. Luckily for us, there is a solution. In fact, there are a few of them such as Greenkeeper, Renovate, and Dependabot.

The idea is pretty much the same in all of them so I’ll just quote Dependabot’s “How it works” section:

1. Dependabot checks for updates
Dependabot pulls down your dependency files and looks for any outdated or insecure requirements.

2. Dependabot opens pull requests
If any of your dependencies are out-of-date, Dependabot opens individual pull requests to update each one.

3. You review and merge
You check that your tests pass, scan the included changelog and release notes, then hit merge with confidence.

As you may have noticed it only makes sense when you have a working CI.

Wrapping it up

If you have a fully automated CI/CD cycle and a new issue is opened in your OSS repository, you can provide a bug fix within minutes.

In fact, you can enter the mobile Github version from your phone, fix the buggy line or two, and commit the code. The rest is done automatically, and your customers are provided with a new version right away.

I myself was able to quickly and painlessly get a fixed version to my customers multiple times.

Having great automation is not about freeing up some time for leisure, it’s about dedicating your time to really important things and increasing your responsiveness.

Version Management

To conclude the guide I'd like to talk about Versions Management, an aspect that always becomes relevant for any OSS project that has a decent number of users.
You’ll learn about version notations, breaking changes, back-ports, and more.

What is Software Versioning?

Let’s see what Wikipedia has to say about software versioning.

Software upgrade versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software.

_Modern computer software is often tracked using two different software versioning schemes — internal version number that may be incremented many times in a single day, such as a revision control number, and a release version that typically changes far less often, such as semantic versioning[1] or a project code name._

Indeed, there are multiple ways of uniquely identifying your software product version.

The most widely known way is by giving it a name.

The vast majority of people on Earth, even those indirectly connected to technology, have probably heard of Android Ice Cream Sandwich and Marshmallow or Mac OS Leopard, its frozen cousin Snow Leopard, and Big Sur.

Programmers have probably heard about Eclipse with its celestial bodies Luna, Mars, and Photon.

All these are major versions of software products.

Though names are great for marketing, they can also be confusing sometimes.
In fact, Google has dropped the usage of candies in their Android version names because they:

Heard feedback over the years from users that the names weren’t always intuitively understandable by everyone in the global community

And rightfully so, yet perhaps we just haven’t evolved enough to extrapolate version numbers from animal species, even though Snow Leopard is much cooler than Leopard.

Celestial bodies and candies are a bit easier concepts to grasp, but only if you name them alphabetically (as Android and Eclipse do). But one thing is certain — there is no better way to determine succession than numbers.

Thus, if you name the first version of your software product “Product 1” and the second version “Product 2” it’s pretty intuitive to say that the second version is the more recent, isn’t it?

However, unlike standalone software products that don’t expose APIs, software that is consumed by other software (like the majority of OSS products) needs better versioning than just a sequence of numbers.

For example, if we used a simple numbers sequence for versioning, how would the user distinguish between a bug fix and a change that is breaking the existing API?

The answer is…semantic versioning.

What is Semantic Versioning?

Semantic version (also known as SemVer) is a widely adopted version scheme that uses a sequence of 3 digits in the following format: MAJOR.MINOR.PATCH .
The rules are simple — given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backwards compatible manner
• PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

It provides a clear and concise way to communicate the changes in your software product to your users.

But most importantly, it is widely adopted by all kinds of package managers and build tools (like NPM and Maven), which allows users to depend on a specific range of versions rather than on a specific version.

For example, specifying the version range ^2.2.1 rather than an explicit version 2.2.1would let the user accept any backwards compatible bug fixes or new features that will be released on top of version 2.2.1.

That said, build tools and package managers rely on a contract between a user and a package owner — a contract that is defined by SemVer.

That means the responsibility is yours— you’re the one who defines what a breaking change is and what a minor change is. You can accidentally release a breaking change as a bug fix (patch version) and it will break builds that depend on a range.

Breaking builds is a horrible thing to do so I’d recommend you use semantic-release with a predefined message format together with a commits format enforcement tool.

You can find more info about Semantic Versioning on the official website, semver.org.

Now, that we learned about identifying the breaking changes, let’s talk about introducing them.

How to Manage Breaking Changes

Breaking changes are changes to your public API that remove, rename, or change your contracts with the user in an incompatible way.

Ideally, you would maintain backward compatibility in your code and wouldn’t introduce any breaking changes ever. But then you wake up to a harsh reality.

Software is evolving and so does your code. The needs of the users change and so does your API. You grow as a developer and so does your product.

Therefore, especially as an open-source developer who doesn’t get paid for their job, you just can’t allow yourself to maintain all the legacy code that exists in your project. Sometimes, you need to get rid of it.

The question is how?

As always, it is a tradeoff. You would know better how this change or another impacts the users.

You don’t have to maintain backward compatibly at any cost, nor do you have to implement all the new features in every old version. But it is certainly something that you should take into account.

If the migration cost is relatively low for the user, then it’s fine to make a breaking change and it’s quite reasonable to not support this feature in older versions.

However, if the migration cost is high and the vast majority of users cannot afford this effort, you should probably consider making this change backward compatible at first and releasing a deprecation warning.

A deprecation warning is often released together with a new API, while the old API is still supported. This way the users have time to migrate. Once they do, in the next major version, the deprecation warning and the old API can be safely removed.

In any case whenever you introduce a breaking change make sure you have a migration guide that has step-by-step instructions for the migration.

In addition, as an act of courtesy, it would be very nice of you to give users the time to prepare for a breaking change, especially if it doesn’t have a grace period (where both old and new APIs are supported).

A little heads-up that explains the breaking change, the reasoning behind it, and the expected time frame is very helpful. It can be a tweet, a blog post, or even a new minor version of your product with a deprecation warning.

Remember that while a breaking change is essentially a negative experience, a sudden breaking change is an extremely negative experience.

Automatic Migration

We can divide breaking changes into two categories — non-deterministic and deterministic.

Non-deterministic are the ones in which you can’t predict the outcome of the migration effort, for example when you completely remove a certain portion of an API.

In this case, it’s up to the user to decide whether they want to replace it with some other 3rd party library, implement it themself, or depreciate it as well.

Deterministic changes are the ones that, given code X and user input I, allow you to transform it into code Y. For example, changing a function name or an import statement.

If you introduce a deterministic breaking change you can write an automation that will change the user’s codebase and adjust it to the new API.

With this automation in place, you won’t have to care about backward compatibility and detailed migration guides. You provide the user with a way to upgrade their code with zero effort from their side, which is crucial in software updates.

However, there is an inherent tradeoff here as well. Writing code takes time, just as writing a migration guide does. And naturally, writing code that migrates a complex code flow into a new API will take more time than writing code that replaces a function name with a new one.

Sometimes you just can’t afford this kind of effort.

In case you do decide to go for it, there are tools that can help you achieve what you want.

The most widely known and language agnostic one is Codemode by Facebook.

codemod is a tool/library to assist you with large-scale codebase refactors that can be partially automated but still require human oversight and occasional intervention.

There are also more sophisticated tools that use AST and can be used for more complicated tasks than just Find & Replace.

For example, another Facebook library (JS/TS specific) called JSCodeShift.
Or code-migrate — a tool (again JS/TS specific) that allows you to write a guided migration relatively easy and provides a user with nice CLI based prompts.

Some big OSS projects even have a solution of their own. One example for such a solution is Angular schematics — a template-based code generator that supports complex logic.

Automatic code migration can be published as a separate package (like my-cool-oss-migrate-v4-v5 ) and mentioned as a step in the migration guide.

Alternatively, the migration can be a part of your major version that contains breaking changes and be executed upon installation of this version in the user’s codebase. The choice is yours.

Back-porting

Another common practice is back-porting important changes to previous versions. For example, a critical bug has been found after a major release (with a breaking change) but it also applies to a previous version.

In this case, you can’t expect your users to perform a tedious migration because of a single bug. On the other hand, checking out the older revision, implementing the fix on top of it, and releasing it as a minor bump of an older version might be cumbersome.

The solution: have a protected branch per major version.

Every time you plan to release a major version you create a branch from the main branch named c.x.x where c is the current major version number.
You make all such branches protected (just as the main branch) so that you don't accidentally break them. Then, anytime you have to back-port a feature or a bug fix from a newer major version, you either reimplement it on this branch or (if possible) cherry-pick the commits from the main branch.

In addition, a strategy that is worth mentioning is having a separate branch for the next major version as well (as opposed to only having branches for previous major versions).

This is usually relevant for large scale projects (like Webpack or Babel) that have a lot of changes in every new major version.

Having a separate branch for the upcoming major version allows working on it and having it published for testing, while still keeping the most relevant version (and working on it) in the main branch.

Once the new major version is published, its branch becomes a main branch and a new branch is created for the next major version.

Final Thoughts

I hope you enjoyed this guide, and have a pretty good understanding now of what it means to own an open source project.

In the end I’d like to share with you one thing that you should always keep in mind while owning an open-source project.

Listen to Your Users

It might sound counter-intuitive, but that is the truth — you’re not the only one who defines the road map, users define it too. In fact, users define most of it.
If you own an open-source project then you do it to help others, not yourself.

Have multiple channels for feedback. There are users that only have a quick question to which you can provide an answer within a second.

There are potential contributors that would like to discuss the roadmap but don’t want to do this in public. Give them a way to contact you. Provide a link to Slack or Discord, share your Twitter account, and so on. The more channels the better.

Speaking of channels, you're always welcome to DM me on Twitter in case you have any questions or thoughts.

You can also read more articles like this on my blog.

Working as a developer means you need to know how to dive into existing code bases. When you inherit a project, there are a lot of specifics that you don't know, like why some of the code is written a certain way.

So when it's time to go into a hand off meeting, you need to know what questions to ask. This is the best time you will have to get the information you need to get up and running.

These questions come up in every project. You could be starting a new job or working on a different project at your current company. Regardless, here are a few things you should bring up in transfer meetings.

Know what it's supposed to do

What exactly is this application used for and who uses it? Without this context, it's going to be really hard figuring out how to implement new features or fix bugs.

Ask about the overall use of the app. Learn about the workflow for different parts of the app and how users move through it. If there's a task list, get a walk-through or more details about each of the items on the list.

This is one of the rare moments everyone is prepared to focus on answering questions about the project. So if there is anything you're unclear on, don't leave that meeting without getting a better understanding of it.

Of course things come up once you start digging in, but this is your chance to preempt a large chunk of confusion. Try and get a high level understanding of the app before you dive into specific questions. Learning about the industry the app operates in can help answer questions that come up in your development as well.

Know how source control is handled

While most projects use Git, not everyone uses GitHub. Some projects could be hosted in BitBucket, Azure DevOps, or even on a SVN. You need to know where code is kept in version control so you can pull it down to your machine and also so you can do troubleshooting when those inevitable production bugs appear.

Make sure that you have access to the code repository and that you have the right level of permissions to do the work you need. When you receive the your login credentials, check them immediately.

The sooner you can find little problems like these, the smoother the project will go in the long run. Fix a small bug and do a quick commit to make sure that you can push up your local branches to wherever the remote repository is.

Also, take a quick look at everyone who has access to the repository. This will be useful info when it's time for pull requests and code reviews. This is also the time to ensure that only the necessary people have access to the code.

Note any users you are unfamiliar with and check with a project manager or someone to see if they still need access.

Know how to run the project

The hardest part of taking on a new project can be getting it set up and running on your machine the first time. There are a lot of one-time commands that can be lost if the process hasn't been well documented.

A few things you need to check that might not be obvious include your env variables, the versions of the software you're running, and the file names you are referencing.

Other things that might come up are setting up a new local database and loading the seed data and changing any connection strings to APIs or databases.

REACT_APP_NAME="Boogaloo"
REACT_APP_API="https://not-staging.morwl.com/api"
API_KEY=ij2i0r9j02tt904tn93

If you are going through setup and you notice yourself running into issues, make sure you're documenting them so that it's easier for the next developer to do it. Plus you never know when you'll need to factory reset your computer and those notes will come in handy.

Once you have the app running, check that everything is functioning like it does in development or production. You should see the same behavior across all of the environments until people start pushing changes.

Know the testing process

There are many different forms of testing that your app can go through and you need to know how that process works. Unit tests are common in most projects to some degree so always check for those. Some companies do integration testing to make sure no breaking changes sneak into the build or deploy pipelines.

Other places even have dedicated software testers that will run through user scenarios to see how things will work when real users see the updates. You need to be aware of all the steps your app will go through.

When you start this new project, looking at the tests can give you a good idea of how the app works. If there aren't any tests in the project then this is your chance to start adding them. Having some code coverage sets the tone for the app in the future that there should probably be more tests added as the code developed.

import React from 'react';
import ReactDOM from 'react-dom';
import { configure, shallow } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
import Items from '../src/components/Items';
import CreateItemModal from '../src/components/CreateItemModal';

configure({ adapter: new Adapter() });
jest.mock('../__mocks__/getAllItemsMockRequest.js');

describe('Items component works', () => {
    it('Items renders without crashing', () => {
        const div = document.createElement('div');
        ReactDOM.render(<Items />, div);
        ReactDOM.unmountComponentAtNode(div);
    });

    it('should toggle CreateItemModal', () => {
        const div = document.createElement('div');
        const ItemComponent = shallow(<Items />, div);
        ItemComponent.find('#add-item-icon').simulate('click');
        expect(ItemComponent.contains(<CreateItemModal />)).toBe(true);
        ReactDOM.unmountComponentAtNode(div);
    });
});

Working with software testers is usually a more involved process. There's typically some kind of system in place like Jira or Basecamp where bugs and features can be discussed and tracked through sprints. Follow the process they have in place and it'll help get your code to the deploy phase faster and more consistently.

Know the deploy process

Although cloud services have just about taken over the hosting needs for most companies, you might still need to work with a physical server. Having this information will help you understand the deploy strategy you will be working with.

Is there a continuous build/deploy process in place or will you need to do manual deploys from your machine? Know how migrations should be handled across the different environments. Get all of the common parts of deploying an app clarified for this particular app.

Little wonky things happen with the cloud services that only the people who handled the deploys before know about so make sure you ask if there is any weird behavior you should look out for. Since you've already fixed a small bug to check that you can push up your changes, go ahead and deploy that small fix to the development environment.

version: 2
jobs:
  build:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
  test:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test

This is your test to see if you really understand how the deploys will work. Hopefully you won't have to do many manual deploys and you'll work with CI/CD pipelines so the process will stay consistent.

Know who you can turn to for different parts of the project

Unless you are responsible for the entire application from the front-end all the way to the database, there are probably other people who cover parts of the code or system you'll never touch. It's important to know who those people are so you know who to turn with questions.

Plus this is a great way to get to know other teams that work on the project and learn what they do. If it's just you working on every part of a project, make sure that you get every login credential that you can because it'll be up to you to answer all the questions.

Know which third-party services the project uses

When you start debugging issues, knowing where to turn for documentation is the fastest way to fix things. That means knowing what services the application uses and where they're used. One way to find this is to check the package.json or App.config file of your project to see what's installed.

{
    "name": "dog-finder",
    "version": "0.1.0",
    "scripts": {
        "build": "npm install",
        "start": "npm run build && concurrently --kill-others \"node ./server.js\" \"http-server\""
    },
    "dependencies": {
        "concurrently": "^5.1.0",
        "cors": "^2.8.5",
        "express": "^4.17.1",
        "johnny-five": "^1.4.0",
        "path": "^0.12.7"
    }
}

This will help you sort out a lot of issues that come up in production and it'll help you ask better questions. You'll also need credentials for most services so that will likely come up when you try to run the project the first time.

A few big advantages to looking at the third-party services early are to learn about any version compatibility changes and any known issues.

A common complaint you'll run into on older projects is that the app doesn't work the way it used to and no one knows why. Looking at these services is a quick and easy place to start looking while you get ready to take over.

Know the best way to get in touch with the decision makers

Even though you are taking over the primary development of a project, there will still be someone like a project manager that will guide the tasks you work on. Get their contact information as soon as you get approval to start on the project. This is one of the people that will be able to get your high level questions answered.

If you're working with a smaller company it would also be good to have the contact info of someone like the CEO or CTO because they will be able to give you a direct yes or no on many of the questions you have.

For example, if you've researched a new database service that will decrease their bill by 10% and increase the overall performance of the app, you want to know if you can make those changes or not.

Learn who the people are that can give you approval or guidance for the next steps you take and then save their emails and phone numbers.

One instance this is especially crucial is if there's a fire in production. When you can get those quick decisions immediately, that can save a company thousands of dollars so they will understand if you call them.

Know what your timeline is

Sometimes it's so easy to get wrapped up in the minute details that when a timeline is thrown out, agreeing makes sense.

Before you fully commit to any length of work, make sure that you've done a proper evaluation of what you are being asked to do with the resources you're provided. Do a quick code sweep to get an idea of what you'll be working with and see how long it takes for people to respond to your initial questions.

That way when you are given a deadline you can explain why it is or isn't reasonable for the amount of work being asked. You always want to give realistic estimates on so that your client or project manager doesn't get other people's hopes up. It's better to tell them upfront if something will take longer or not as long as they expect.

When you have reasonable expectations, it makes the whole project flow better for everyone. There aren't as many panicked sessions of coding and you are able to deliver quality code that won't have to be debugged in production.

Know what the scope of your work is

The scope of projects tends to slowly expand as you make progress. You start getting a little feedback here and there about "little tweaks" that should be made. Then it turns into a question of what takes priority over what and it's not the original work you started with.

One way to prevent scope creep is to agree on a set list of tasks or a specific functionality that needs to be implemented. Anything else can be written down and brought up in another part of the project work, but not right now.

Once the work has been agreed on, then there should be a clear finish state that the project will be in at the end.

Final Thoughts

Taking over an existing project is a special skill because it's not something you do all the time. Some people work on one product or product line for a bulk of their career, so setting up new projects only happens every now and then.

Although if you ever do consulting or freelance work, you'll need to know how to do this with confidence on a regular basis. Usually there are small configuration changes that you have to figure out and once you set them you never have to worry about them again.

These are just a few things I try to check for when I'm setting up a new project. Some of these tips apply to open source projects as well. Do you have anything you always check for when you're getting set up?

I write about other random stuff in tech too, like air guitars and VR. You should follow me on Twitter to learn about that cool stuff.

• 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!

Guides to help you work remotely seem to have swept through the Internet these days.

Do this, avoid that, stay productive, and all those run-of-the-mill tips we’ve already tried out.

So instead of talking about how your remote team needs to schedule out their day effectively or clean their desk, here I am focusing on the hands-on tips you can apply to manage your software development team while working remotely.

First, we need to understand the exact meaning of “remote teams”.

This will allow you to clearly see that having even one individual who’s working separately means you should improve the way in which you manage your team and the process they use for remote team collaboration and task execution.

What are remote teams really?

Today, millions of companies are faced with remote work situations in one form or another. Whether they’re fully-distributed organizations, have a couple of employees working from another part of the world, or just regularly work with external collaborators.

The first thing that comes to your mind when you think of remote teams is something like: different people working from all parts of the world and distinct time zones on a single project and having the same general goals.

In reality, there are many remote teams that have employees in a single country or even in one city. It’s just that everyone works from their own home, without having to go to the office. ? This saves on costs while managing remote teams.

Source

But many companies (software development included) have offices in multiple countries. When your US team members talk to their colleagues from the UK, they’re essentially collaborating remotely. So remote team communication is a must in these cases even if everyone is in the office.

This being said, whether work is done from an office or not is not necessarily a defining factor for remote teams. The problems you could experience lie solely within the communication and work processes.

Best practices for managing remote software development teams across multiple time zones

Since you’re probably used to all the “do this to be productive” rants, I’ll try to tell you what you might not know.

Hire the right people for your remote teams

People are the heart of any team.

So if you hire the right professionals [and humans] for your team, you’re halfway to success.

On the hiring and interviewing process, here are some of the best tips from Shannon Hogue, Global Head of Solutions Engineering, @Karat:

“I always tell hiring managers to start at the review and work back to determine which core competencies should be listed in a job description. Then, to keep things standard across a global network of Interview Engineers, we put those competencies into structured scoring rubrics for each interview.

Here are 3 quick steps for building a structured rubric that can help keep everyone on the same page, be it for hiring or managing:

Identify what competencies are both relevant and important to assess.

For each competency, list observable behavior and results as checkboxes (select all) and/or radio buttons (choose one).

Write down an “algorithm” to help interviewers summarize a completed rubric into a single conclusion.

For example, if Technical Communication is a relevant competency you might list it on the rubric with a specific scale.”

Here’s what Shannon’s example could look like:

Beyond any hiring tip, effective remote work also imposes a question on whether your office workers will adapt to the new lifestyle.

If you’re switching from an office team to a distributed one or even if you want to hire someone who hasn’t worked remotely before, you need to guarantee they’ll fit in the team and work efficiently in your remote team even before day #1.

For software developers the demand is so high that you’ll often bump into this problem:

How do I make sure that who I’m hiring is the perfect fit within our team when they haven’t worked remotely at all? ?

Perhaps tech professionals are some of the easiest to assess beforehand. Check out any of their side projects, if they own a business or do freelancing, and even look at their online presence.

A developer who’s only been putting work for their official job and has no GitHub repositories and projects to boast is clearly not going to be someone you’ll trust right away.

Trust and accountability are the 2 main attributes to consider beyond any hard skills.

These two character traits (which we often ignore because we’re too focused on business results) can predict whether that person will fit within your team culture. And, even more importantly, if they’re willing to stay with your company for many years to come and dedicate themselves to your project.

From then on, managing remote teams is also a matter of how you handle their training.

Onboarding and training

The trial period all HR experts recommend exists for a good reason. It allows you to literally SEE how they work, collaborate, and get along with the rest of the team.

Many managers make the mistake of hiring a developer, letting them start the trial weeks, but not monitoring what they’re actually doing.

Don’t assume that someone who seems skilled and experienced will deliver the same commitment and quality of work to you too. May I say this is the best and only time to be a micromanager and literally oversee all of their actions.

But do offer your help within the first days by making sure they have all resources needed and making the appropriate introductions to your team.

Get them involved in the code writing process for your project as soon as possible so you can get a better feel of how they conduct their work. I’ll also advise you to try a pair programming session during the hiring process too. More on this procedure later in this guide.

Prepare the right work methods

This is largely the manager’s decision. Team feedback is only valid when everyone knows the relevant best practices and benefits of each work method. This doesn’t mean you can't get their input on the methods they’d prefer to use. However, letting them take care of the decision process will only give rise to conflicts and postpone the choice for the time being since there simply will be too many opinions for you to sort out.

“While you do not want to micromanage a remote team, you certainly want to set up clear minimum administrative processes. For a previous remote team I had to manage, this included setting-up very precisely the infamous JIRA workflow.

While it is good to leave a remote team some freedom, work also needs to be clearly organized, so there should be a few processes that have very precise descriptions. In development, the most important of such processes are issues management, and also the build process. This should be described in detail, and followed strictly.

To make sure key processes are respected, there should be set points when work needs to stop until the process is followed. As an example, I gave strict orders to my business team not to look at any incident that is not documented.” - Nicolas de Mauroy, CEO @Open Lowcode

But how close should supervision really be?

Surprisingly – not that in depth.

Keep your devs under your radar only enough to guarantee that all processes run smoothly and you’re able to maintain a trust both ways. Yes, 50% of data breaches across all industries are caused by insiders, but that doesn’t mean you must force everyone to track their time or record their screens.

Developers should really only have to track their time in 2 instances:

1. They/you really want to improve your work processes.
2. They’re getting paid by the hour.

Your role as a manager goes beyond the person who is seemingly in charge of everything. You’re a liaison. That key link between one team member and another, helping your development team collaborate with operations, marketing, design, customer support, and sales while also ensuring all team members are happy and their needs are met.

I’m super disappointed to tell you that only 35% of managers are engaged with their work. How is this going to motivate someone else?

Employees who are supervised by highly-engaged managers are in turn going to be better and happier performers themselves. This will boost your employee retention rates and create that long-lasting company-worker bond most companies can never attain.

This takes me to the importance of knowing when and how to communicate. Both ways.

Craft your remote team collaboration plan

Collaboration goes hand-in-hand with your work method and how you manage tasks. It’s the little things like crafting clear task descriptions and expectations that add up to distinguish a positive collaboration experience from a chaotic one.

Tinjo Thomas, Design Technologist @Coredes Interactive also recommends the following two tweaks you can make:

“1. Always set a due date for each task even though your developers are experts and can make estimates themselves.

2. If you are giving instructions to only one or two people, don't send the message to the whole group. Reach out to every individual in private. People spend a lot of time reading unnecessary conversations on channels.”

On meetings

Meetings are honestly a very controversial topic. Managers love to call meetings. Devs, though, hate most of them but are afraid to voice their thoughts.

To keep meetings relevant, here are some actionable points to keep in mind:

“On a more macro-level, knowledge sharing can happen through a weekly team meeting with a Q&A via video whereby the members of the team can share what they learned from the codebase with each other as well as ask questions. In terms of knowledge sharing through team meetings - you can have several types of meetings.

The overall idea for these is to encourage collaboration in an effort to turn explicit knowledge into tacit knowledge. So you can have brainstorming sessions or meetings geared more towards lessons learned (this can be in the form of a demo or presentation). All done entirely remotely.” - Emil Hajric, CEO @Helpjuice

One huge mistake first-time remote team managers make is filling up entire days with meetings:

“First-time remote team managers need to be quite aware of the differences between collaborative work [like Scrum meetings and software architecture design] and individual focus work [like coding]. It is important to schedule time and ensure everyone can contribute to the collaborative session, but then leave your professionals alone to do what they were hired to do, write great software.” - Pedro Henriques, Co-Founder & CEO @BRIDGE IN

You’ll want to always remember to press that record button during meetings. We’re not necessarily fans of paper trails, but you’ll need them to avoid bothering your team with issues that have already been discussed:

“You should be recording and saving absolutely everything from remote team meetings and strategy sessions. While working remotely, we've noticed a huge uptick in productivity when managers and team members can refer directly to meetings instead of having to play phone tag or email back and forth for simple information. It's a huge boon to workflow across the board and should really become the new normal with the increase in remote team management.” - Alexander M. Kehoe, Co-Founder and Operations Director @Caveni

Keeping up-to-date with all changes is even more important when your team’s distributed. But remote teams have different approaches to how they make sure they don’t just communicate, but also apply and consider every opinion.

Here’s where the real-time vs asynchronous communication battle comes in. Everything’s already been said about this. So the conclusion is:

There’s a right time for each type of communication. A predisposition for certain types of tasks will also make your remote team more likely to go for one method of communication over the other.

Just like the video vs written communication issue.

The Voro team, for instance, has used their office and remote communication tests to conclude that written collaboration worked best for them:

“My #1 tip for managing a remote team is to default to written communication rather than video calls. This forces you to clarify your thinking and communicate succinctly. When we all worked in the same office, it was easy to walk over to someone’s desk to talk through a problem. It would waste a great deal of time to replicate that with a scheduled video call.

Since we are 100% remote, more of our communication has been written, and we try to memorialize most of that in internal documents, so we continue to move fast and share institutional knowledge seamlessly.” - Tomas Hoyos, CEO @Voro

Invest more time in one-on-ones

With one-on-ones, you’re focusing more on sharing the status of specific tasks and individual activities, while every single member on your team gets to make their own suggestions. One-on-ones are commonly held between one team leader and the other members at a time.

Having these twice a month is your best bet to make sure everything gets covered. Holding them weekly is too often as you won’t have time to focus on your other tasks because you’re too busy with meetings.

These one-on-one meetings are also a good opportunity for you to hold reviews and updates on the OKRs. To facilitate the feedback and ideation process, Charles Ahmadzadeh, CTO @Bunch uses checklists during these meetings:

“I like to use checklists with my team. I'll ask each team member to create a checklist each day of what needs to be done before ending the day and before submitting their work. We review these checklists in 1:1s to spot patterns.

I mostly use this to help others around me grow or keep myself accountable to the feedback I receive from the team.

The good thing about them is that they work no matter how senior you are (even astronauts live by checklists). They’re easy to share in 1:1, even if your team is remote, and very simple to use, as long as you’re committed to improving yourself.”

NOTE ON OBJECTIVES AND KEY RESULTS: Team leaders can establish these at a team and individual level by also taking into account suggestions from developers.

For instance, each department or team can have specific targets: to release a feature on time, avoid more than 2 major bugs after a release, keep the error rate low, etc. Individually, each member should take care of one release so that every single team member will know how to handle them.

Here’s an actionable idea: Use TrackJS [or other error tracking tool for your programming language]. Every member can choose a top error and fix it. This allows members to increase their accountability and learn new things to avoid freezing their skills.

Pair programming finally getting the attention it deserves

Now is also the best time to experiment with pair programming. This practice allows two developers to work simultaneously, often on the same tasks. While this is usually done from the same computer, you can switch it up a bit and make use of tools like TeamViewer or screen sharing.

Pair programming also helps distributed teams improve the quality of their code, tighten bonds between colleagues, transfer information and know-how from one dev to another, increase their own accountability, and speed up the entire development process.

Does this make you feel like you’ve been missing out on all its benefits? ? Just keep in mind some best practices if you want to get started with using the pair programming practice on a regular basis.

By using common sense, you probably won’t have both developers working on the same thing for 8 hours straight. Instead, distribute tasks evenly and allot a specific time slot for them to actually work together. Dealing with multiple time zones? Pair programmers within similar work schedules.

Communicate beyond work with your remote teams

We’re all humans. So we can’t work, work, work all the time. How about you implement some activities for people to destress twice a week as part of your remote team management process?

Playing board games online. Having a #watercooler channel on Slack. Finding some creative online team building activities. These are all ideas to help your remote teams unwind and get their mind off anything that’s stressing them out.

Pedro Henriques also shared his thoughts on the importance of implementing this type of downtime while working remotely:

“Remote teams need to deliberately schedule slack time and create informal virtual watercooler moments. In the office, the watercooler or coffee machine is often the place for spontaneous discussions about various topics ranging from a nasty software bug to vent about office politics or even troubles in personal life. These discussions are not superfluous. They’re absolutely critical for team cohesion. Therefore managers should actively promote them, but make sure not to attend.”

Choose the right tools: The basics will do, there are no magical solutions

I’ve seen so many “best tools for remote work” lists the Internet could really crash for good.

Nah, but really, stop looking for the best apps and miraculous software to somehow save your remote teams.

We already know everyone is using Slack and Zoom to collaborate and the ones who don’t use these are probably doing so because of small issues they had or costs they wanted to lower.

For instance, from all apps I’ve tested for this purpose Google Meet was the fastest and most accurate one but guess what? My clients are using Zoom already. No room to impose another tool.

The key point is not to waste weeks trying to find the right tools for your team. Others have already done this. There are thousands of options out there. All of them are copying features from each other so you end up with the same tool in dozens of versions.

So here’s your stack:

Jira - Slack - Zoom - GitHub - InVision - a bug tracking tool - every developer’s code editor

Test these [preferably the free versions first] and only look for alternatives if you have huge issues that are stilting your workflow. My two cents.

Also, some wise words from Tinjo Thomas:

“Don't try to save money on bug tracking or team management tools. You will know why it’s important when things don’t get done as you expected.”

Know a remote team manager who could use these tips? Share this remote team management article with your network to keep improving remote work processes.

If you want to get more technical with your product management skills, being able to work with flowchart or diagram creator apps is surely on your list.

The following guide aims to save you hours of time you’d otherwise spend researching the best diagramming solution for your project while at the same time perfecting the design of your flowcharts.

As a general rule, a flowchart or diagram is used to communicate requirements, processes, and workflows in a logical way so complex concepts will be a little less complicated.

In product management, workflows are commonly used to describe:

• User flows
• Processes and other systems involved in them
• Dependencies between systems and inputs, outputs, or other conditions

I’ve tested and reviewed several tools for creating flowcharts and workflows over the past few years. Here, I've picked 5 that you must try out to describe your product’s funnels and flows.

But first…

Why are diagrams so powerful in product management?

While the whole idea of using flowcharts and diagrams might be overlooked or seem like it’s an unnecessary step, there are several benefits to using diagrams in PM:

• It simplifies all processes
• It helps you spot issues or weak points at a glance
• It allows you to find any duplicate parts of a process
• It establishes clear funnels
• It supports your Quality Assurance team during the creation of test scenarios
• It acts as a roadmap for software architecture

So how do you choose the best diagramming software?

Creating any kind of diagram is a fairly easy process. Building a successful one, though, takes a bit more research and time.

That’s why you need to choose a tool that will help you save hours of work while also giving you the predefined requirements you’ll need to build accurate diagrams and keep the process fun.

The key aspects to pay attention to when choosing a flowchart creator software solution are:

• Availability of ready-made templates
• Lots of choices for shapes and arrows to work with
• Extra tools or integrations
• Exporting options
• Strong collaboration features
• Ease of use from the beginning

To make it easier for you to select your next tool for building diagrams, I’ve highlighted all of these aspects for every individual solution across the following reviews.

Next up are my favorite free flowchart creator and workflow diagram app picks you need to take into consideration.

5 free flowchart creator and workflow diagram tools

Lucidchart

Lucidchart should be your top-of-mind solution for creating customer experience maps and systems diagrams in particular. From the very beginning, the tool makes it easy for product managers to select the type of flowcharts they want to create. Matter of fact, the onboarding process and resources available online make it a tool with a fast learning curve.

From the very beginning, you’ll get all possible templates needed for you to create product strategies, create roadmaps and product flows, and even pitch your ideas to stakeholders. With ready-made templates and literally thousands of shapes and arrows to choose from, there are endless opportunities for product managers to create their materials in no time.

Also, if you’re like me and like to add a few too many colors, this diagram app comes with a bunch of theme options to help you nail the design of your creations. Bonus points for customization here from non-designers.

The reason I’ve placed Lucidchart first on this list is that it’s a complete flowchart creator tool. Collaboration options are some of the strongest with comments that can be left on charts just like you would in Google Docs, slides that can be used to present your diagrams, and even sharing and exporting options.

If you’d like to take it all one step further, you can choose from dozens of integrations with tools you might already be using like Slack, GitHub, or Salesforce.

You can also check out my video tutorial on using the tool so you won’t have to find your way around Lucidchart yourself.

Pros

• Free plan available
• Easy to learn
• Lots of templates and elements to choose from
• Strong collaboration features

Cons

• Limited space for free accounts
• No desktop app

Draw.io

Draw.io is a top choice for many PMs since the tool’s free, so you might have already been using it for several other business processes. Since the tool belongs to Google the interface is similar to other Google Apps like Docs and Slides that you’re probably working with anyway.

Compared to Lucidchart, Draw.io might be harder to use for non-designers since there are no theme colors to choose from if you want to make your diagrams eye-appealing.

Whenever you want to create a new diagram, you’ll get to choose from a series of templates ordered by their structure. There are no specifics for product management.

The flowchart tool does save itself through lots of elements you can use on your workspace. I advise you to use the search bar to find a specific item or element faster.

Since the tool is so simple that even a child could use it, Draw.io is missing the advanced functionalities and collaboration features that would otherwise allow you to communicate with your team directly on the document. To do this, you’ll need to integrate it with a tool like Confluence or Quip.

Pros

• Free to use
• Clear interface which makes it easy to get accustomed to

Cons

• Limited templates
• No collaboration options
• No mobile apps
• Few integrations

Creately

Creately is only a free workflow diagram app if you can accept the fact that all of your design will be public and you’re limited to 5 documents. Team plans start at $12 which is a fairly decent price considering you’re getting all the features with it.

I specifically found their onboarding process handy since it introduces you to the tool so you won’t start and have no idea what to do next.

In many ways, the tool is similar to Lucidchart. You’ve got lots of templates to choose from, all of which are ordered by their purpose. Then you’ve got your elements which are some of the most beautiful I’ve seen, along with other styles and theme options to help product managers who aren’t that skilled at design too.

One thing people struggle with while using Lucidchart is file organization, a feature that Creately nails by turning their tool into an alternate file storage app. The tool also eases the process of working with several elements by integrating Google search so you can find images to use without leaving the app.

In terms of collaboration, Creately works similarly to a prototyping tool, allowing people to leave comments on the exact element they have feedback to offer on. Collaboration is done in real-time via the online or desktop version of the app.

Pros

• Lots of templates to pick from
• Theme options
• Communication options
• File organization option
• Works offline too
• Easy to learn

Cons

• The free option only allows you to create public content
• Some features are still under development but will be released soon

Whimsical

Whimsical is a user-friendly visual communication tool that’s commonly used to create wireframes but has separate options for putting together flowcharts, mind maps, and sticky notes.

While the tool is highly visual, there aren’t that many template options to choose from. This is because the app is centered around creating basic wireframes and flowcharts for internal use only. Shapes and connectors are also limited, but there are hundreds of icons to go for if you want to add some extra color to a mind map or flowchart.

On to the benefits of using the tool: collaborating on each project takes fewer than two steps, with comments being placed on every single element you want to leave immediate feedback on. All work is easy to share, export, and even embed.

Ever been annoyed by losing your past versions for a product development flowchart you were supposed to show to your stakeholders? Whimsical is one of the few tools that has a fully-featured file versioning option that records every single change you’re making on a chart so you can restore better versions.

Pros

• Strong design options
• Easy to learn
• Sharing and exporting options
• Lots of icons to add to your creation
• File versioning
• Free version available

Cons

• Limited template options

Canva

Canva is not really a common option since it’s usually used by marketing and social media teams who need highly-visual content to display publicly. If you’re also looking to create a flowchart to present on your social networks, in your pitch deck, or to any other stakeholders, it’s definitely worth giving it a try.

Not only is it easy to use, but the fact that it’s a general app instead of being tailored only to building diagrams also means it has thousands of elements and icons you can choose from. Illustrations, arrows of all kinds, customizable charts, you name it. Even videos.

As for the sharing options, they’re top-notch. You can export your content into any file type you want, resize your workspace to share it on multiple platforms, and use the presentation mode, complete with notes for presenters.

Once you invite your team into the tool, you’ll be able to leave comments on your designs to keep everyone on the same page.

Pros

• Free option
• Extremely easy to use
• Versatile
• Focused on great design
• Lots and lots of options for elements
• Collaboration options

Cons

• Limited template options for product management

Haven’t decided yet?

Start by creating a list of your own requirements. Are you in need of strong templates so you don’t have to build everything from scratch? Or maybe you can give up on lots of elements as long as collaboration options are on point.

Based on your own needs and goals, go over the above list to pick an option that works best for you and give it a try. Each option has its own unique features that distinguish it from the others:

• Lucidchart - lots of template options for PM
• Draw.io - super easy to use
• Creately - most features in one tool
• Whimsical - clear interface for internal use
• Canva - focused on design

If you have any other tips on helping product managers choose their next flowchart creator workflow diagram app, let me know.

In this article, we'll discuss how agile principles and values can be applied to the way you approach data science projects.

Project management methodologies are commonly used to get projects done or get a product (often referred to as a tool) produced. They are, in general, processes and frameworks which break down the overall objective to individual tasks organised on a timeline. This can be adapted and used to approach data science projects.

In the past, the traditional Waterfall methodology (dated way back to 1970) has been very popular. It defines all requirements and parameters of the product at the start, so that the project team can work towards this target in sequential phases.

This method has been successful in the manufacturing industry where product specifications seldom vary with time. It requires very extensive upfront planning, and ideally, the output product is exactly the same as specified in the beginning.

But the Waterfall methodology started to become unsuitable for software projects. Because of this, many popular project management methodologies have emerged over the years, especially in the software development industry. Let me share the most popular one.

Waterfall vs Agile. Figure by Author.

Agile Framework

Agile is a way of working developed in 2001, and is a widely used to manage software development projects. It is suitable for fast-paced development cycles and has provision for changing specifications throughout the design and build process. It is flexible, and strives for iterative incremental improvement in the product through team collaboration. In short, Agile is to plan, build, test, learn, repeat.

Agile teams are responsive to the unpredictable requirements as the project unfolds, through iterative work processes. Below are Agile principles which serve as a framework (guideline) to the way of working:

• Customer satisfaction through early and continuous software delivery
• Accommodate changing requirements throughout the development process
• Frequent delivery of working software, as the working software is the primary measure of progress
• Collaboration and interaction between the business stakeholders (client) and developers (vendor) throughout the project, including face-to-face communication within the development team
• Support, trust, and motivate the people involved
• Agile frameworks to support a consistent development pace
• Attention to technical detail and design enhances agility
• Simplicity in looking for solutions
• Regular reflections in the self-organising team on how to become more effective

Agile projects are characterized by a series of tasks that are conceived, executed and adapted as the situation demands. However, Agile focus is not on what to do, but how to think. Agile values and places priority on:

• Individuals and interactions (rather than processes and tools)
• Working software (rather than comprehensive documentation)
• Customer collaboration (rather than contract negotiation)
• Response to change (rather than following a predefined rigid plan)

Agile way of working. Figure by Author.

Agile practices and Data Science

While Agile principles and priorities are employed for greater productivity, most of them can be leveraged for data science (DS) projects.

Moreover, data scientists do not know how to schedule the project because it is impossible to determine a specific timeline for the type of “research” and exploratory work. Most DS projects require trial and error by going down different paths and trying different techniques. They do not have an element of certainty in the output, so Agile can be used to direct the workflow.

Most other projects deal with what customers want, what the developers want, and what the business seeks. When working with DS, another perspective is added: what the data is telling you.

Data scientists cannot make any sense out of the data unless they develop a basic understanding of it. There is a lot of investigation, exploration, testing and tuning. Agile uses the concept of iteration and constant feedback in order to refine a system under development, in order to move up the Data-Value Pyramid.

Data-Value Pyramid. Figure by Author.

When working on DS projects, insights are not immediately achievable. Multiple iterations are needed before any insights can be discovered.

How agile practices can be applied

I will explain the main Agile working practices (Scrum framework), and how they can be applied to DS:

Define the business need and the project objective. This is usually driven by the product owner who is responsible for the product features and quality. It is the big picture stuff, but this is the core belief that you will refer back to as you build.

In DS, the product owner could be the client, the business, or the end customer (for example, end user of a prediction tool). Understand what problems the product owner is facing and tailor the project proposal to meet their needs.

Build the backlog. Focusing on the user requirements (“user stories” in Agile), a list of tasks is derived that you need to accomplish to build product features or improve product performance.

The DS team builds the backlog together with the product owner to determine the product features and performance targets. The backlog could start from getting the data in the structured way before they can be analysed. Then it could be a list for feature selection or feature engineering, or a list of models to select, tune and optimise.

Prioritise the backlog, identify the backlog tasks which will bring the most value with the least effort.

In DS, not every approach is worth trying, so cover the most promising ones first. When the main ones are conveyed, you might find that the remaining others are not as important as initially thought.

Do a sprint (the actual development work). Sprints are usually two-weeks cycles where high priority tasks on the backlog are worked on.

In DS, each sprint could be two to four weeks depending on the team size. During the sprint, always complete the task with the highest priority before moving on to the next in line.

Have daily standups. Standup meetings are for team members to be accountable to one another on their progress in the current sprint. Each team member take turns reporting their status — what was done the day before, what to do today, any potential obstacles. The most effective communication happens when DS team members meet face-to-face to share their work.

Review the sprint output (sprint retrospective meeting). At the end of two weeks, there should be a functional output for the project team to demonstrate, with an incremental improvement in the product.

Data scientists should share the outputs before trying to perfect the processes. Get feedback from client stakeholders and prepare for the next sprint. Regular feedback is a key principle for the Agile way of iterative incremental improvement.

Prepare for the next sprint. Identify the tasks that are going well and keep doing them, and identify those that are impediments to be removed.

It is important to understand that, unlike software development, DS is more experiment-based than task-based. DS helps explore data so it should be treated as multiple research experiments. Once again, build and prioritise the backlog so that the next sprint can be carried out, to work on the next improvement areas.

Roll out the final product. When all stakeholders agree that no more improvement is needed in the product, it is ready for the final deployment.

DS projects follow the “law of diminishing improvement”. For example, if a model has achieved 70% accuracy, the next 5–10% improvement will take a lot more effort than before, and it also depends on the limitations in the data set. Decide in the team whether the efforts are worth the incremental improvement.

Photo by [Unsplash](https://unsplash.com/@youxventures" rel="noopener">You X Ventures on <a href="https://unsplash.com/photos/Oalh2MojUuk" rel="noopener)

Challenges with the client

Besides having adequate communication between the DS team and the client, the client’s expectations have to be managed.

All clients generally love the idea that Agile is flexible, and that it grants them more opportunities to change their mind as the project develops. However, they might not realise that such flexibility is also costly in both time and money. Here are some things you should do:

The cost of flexibility

Get the client to understand that flexibility is inevitably expensive. It is like how a flexible full-fare economy ticket which allows itinerary changes will cost much more than the fixed one. Making changes also means that the client is paying for past wasted time and effort.

Set expectations

Set the client’s expectation to commit time for frequent sprint retrospective meetings (e.g. every two weeks) to evaluate the completed sprints.

On top of that, the client representative in each meeting needs to be (empowered by higher management) able to make decisions on product specifications. For Agile to work, the client needs to provide continuous feedback and priority setting to keep the project moving.

Trust is important

Earn the client’s trust and show them that each iteration is done with the best possible efforts to deliver value and improve the product.

While holding the decision making power, the client also expects an iteration to have tremendous improvement.

Such imbalance in responsibility in the client-vendor relationship should be converted to mutual trust and willingness to experiment together. Agile’s principle in collaboration means it is a team effort in both making decisions and delivering value.

Photo by [Unsplash](https://unsplash.com/@youxventures" rel="noopener">You X Ventures on <a href="https://unsplash.com/photos/6awfTPLGaCE" rel="noopener)

Minimum Viable Product

One key feature of the Agile way of working is the development of a minimum viable product (MVP). This is the most fundamental configuration of the product (or tool).

After the project objectives have been defined, the team makes a proposal regarding the approach to the problem. This includes building the MVP within the shortest possible time (like one month for DS projects). The MVP has only the most important functionalities, but its performance may not be the most optimal.

This might seem very risky – putting a less-than-finished version up for the client to test. So the team (including the client) has to be prepared for it. The purpose is to make the MVP work, test it, and see if it is really going in the correct direction of solving the problem and helping the business case.

The MVP will grow better, because the DS team is going to use what they have learnt from the MVP feedback to build an improved version. Agile is about continuously deploying and learning from your mistakes, and working with the client to make the product better.

_Iterative nature of Agile. Figure taken from TowardsDataScience._

Agile is to plan, build, test, learn, repeat.

DS project deliverable

The Agile way of working allows data scientists the ability to prioritize and create roadmaps based on requirements and goals. With each iteration, data scientists can learn something new, get more refined results, and ride on them for the next incremental improvement.

Below are some Agile project deliverables to shape and guide project process:

• Project vision statement: A summary that articulates the goals for the project.
• Project roadmap: The high-level view of the requirements needed to achieve the project vision.
• Project backlog: Ordered by priority, this is the full list of what is needed to support your project.
• Release plan: A timetable for the release of a working product (or tool), but not documentation. Projects should be self-documenting along the way.
• Sprint backlog: The user stories (requirements), goals, and tasks linked to the current sprint.
• Increment: The working product functionality that is presented to the stakeholders at the end of the sprint and could potentially be given to the client. The goal is not to deliver more but to get a higher value output.

Summary

Agile is going to be adopted by more DS project teams in the near future. Many data scientists have reported that it makes them more productive.

This is not because the data scientists have become more skilled, but because Agile can help them optimize their projects. Instead of spending time on models that are unlikely to reveal any productive results, it is better to spend that time for other result-driven purposes.

Being “agile” (flexible) means you need to adopt a dynamic approach in planning and be adaptable to the changing needs of the new situation when it arises.

The Agile environment appeals to quick action, fail quickly, discuss and evaluate, then try again using a different approach or an improved method. It works great in dynamic environments where there is a potential for changing or evolving requirements.

All the best to your DS projects!

Reference:
Data-science? Agile? Cycles? My method for managing data-science projects in the Hi-tech industry.

The holiday challenge

For a lot of teams, the holidays are a time of year when a large amount of peope take off after saving their PTO for the whole year. This time is precious, especially for those who work with e-commerce after getting through a rough peak season spending long nights making sure all the promotions went as scheduled.

SNL Holiday Band

What this means in practice, is you have a sprint with limited capacity or you have people coming in and out (depending on their schedule), carrying a lot of overhead with context switching and minimal communication throughout the week.

So what can be a better option?

Spread the holiday cheer with a tech debt sprint

The reality is, your holiday sprint isn’t going to be the most productive sprint of the year. More often than not, you’re met with chaotic schedules that are hard to truly plan around.

For example, you have Joe visiting his family, maybe he can snag a few hours between get-togethers. Then you have Nancy who’s working the full week, but only at night, as her days are packed with holiday activities. Finally you have Todd who used his PTO early in the year, so can’t take any time off, but is working his standard 9-to-5.

It’s hard to imagine having a regular daily standup cadence, let alone figuring out if and when a ticket will be get completed. So instead, schedule a sprint dedicated to tackling the technical debt that’s accrued throughout the year.

Wait, what is technical debt in the first place?

For a lot of devs, there’s a daily balance trying to determine whether the bug or concern that popped up warrants blowing up the scope of a ticket or if it’s better to dig in and fix it as they’re working through it. These things can take a toll on a team, leaving spirits low, knowing they’ll never actually get the opportunity to loop back and course correct.

Just because this concern isn’t going to bring the app down, that doesn’t mean it’s not valid and doesn’t need to be taken care of, so instead of fixing it, the next course of action is to throw it in the backlog for a rainy day.

The problem is, this rainy day doesn’t seem to ever come. That backlog of not-really-high-priority tickets adds up becoming a mountain that will throw you into technical bankruptcy!

Ghosts of Christmas past

Take advantage of the chaotic schedule

With everyone’s schedules in flux, it’s a good chance to find a backlog of narrowly scoped tickets that your team can work through on a case by case basis.

Have a few code paths that lack some tests? Perfect ticket. Have a few fragile functions that already have tests but need to be refactored to avoid future grief? Put it on the list.

This type of work–while small in the overall picture–can make a difference in how your team perceives their own work, which directly impacts their attitude towards the project.

Remember what’s best for your team

Overall, the point is to do what’s best for your team. Low spirits can impact a team’s velocity, so being able to provide these little wins can end up helping in ways you wouldn’t have thought of.

Whatever your strategy may be, it’s important to enjoy a stress-free holiday season whether you’re taking PTO or not.

Carlton dancing during the holidays

Read more of my articles on element84.com.

The desired benefits of agile development are many. Customers are happier and more willing to buy. Lead time from idea to delivery is shorter. Employees are more motivated and more productive.

Sounds good, doesn't it? In practice, certain behaviors stand in the way of the benefits. As a scrum master and agile coach, I see the same anti-patterns in many companies over and over again. Today's anti-pattern is about project budgeting and contracts.

Fixing the scope - not a good idea

In many companies, the scope of delivery must be decided on first. Then someone estimates the effort and calculates the necessary budget. Finally, there is a go or no-go decision for the project.

It is similar for many customer supplier relationships. First, a contract must be set up that describes exactly what will be delivered. Otherwise there is no order.

How else could it be? How else can you, as a customer, be sure what will come out in the end?

As an agilist, here's my answer. Customers can't possibly know the exact end result in advance. Software development is full of surprises. The requirements of today are history tomorrow.

It's important to recognize the tension between predictability and changeability. You can't have both: perfect predictability of the end result at the beginning and maximum consideration of change requests later.

What you can do instead

At the beginning of agile development, it is sufficient for stakeholders to agree on a product vision, and maybe a rough roadmap. Funding can be done incrementally, sprint by sprint.

But what if this is not possible in your company? What if the stakeholders don't want to give up the illusion of safety that comes from clarifying requirements early?

Well, it's a waste of time to specify details of requirements that will change later. So what to do?

You can agree on user stories in advance. That makes sense. But don't define the acceptance criteria! Clarification of details is postponed to development, shortly before implementation.

The advantage: you can react to lessons learned from development and new customer needs.

Change management done right

Either at the beginning of a project or during contract negotiation, stakeholders should agree on the mode of cooperation and the handling of changes later.

It is important to follow a few important principles.

If there are changes, a change management process that evaluates each change individually is NOT enough. Instead, a change should be related to other changes.

For each change that is implemented, either

• take another requirement out of scope, or
• increase the duration of the project.

During development, individual elements can therefore be replaced by elements that are equivalent in terms of development effort. Scrum supports this with the Product Backlog–by pulling a backlog item up, the other elements automatically have less urgency.

If you want to know more about agile contract design, I recommend you have a look at Money for Nothing and Your Change for Free.

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.