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

I’ve been participating and running Sprint Retrospectives now for 15 years and I truly believe that when done well, they are the best way to make a team more effective and more closely bonded.

What is a Sprint Retrospective?

A sprint retrospective is one of the key events in an Agile Sprint. The retrospective occurs at the end of each sprint and it is the meeting where the scrum team gets together to talk openly and honestly about the sprint that has just finished.

The purpose of the Sprint Retrospective is to find out things that went well in the previous sprint and things that didn’t.

Agile promotes iteration and improvement. The retrospective is a way to continuously improve the team and the team’s practices by regularly (at the end of each sprint) dissecting your working practices and trying to improve upon them.

Building the Foundation for Effective Retrospectives

Before diving into methodology, let's address three critical factors that determine how successful your sprint retrospective might be:

1. Team size matters: I've discovered that scrum teams larger than 6-7 people struggle with meaningful retrospectives. The dynamics change, people speak less freely, and you lose the intimate environment needed for honest feedback. If your team has grown too large, consider splitting it.

2. Trust is non-negotiable: I've seen brilliant retrospective frameworks fail in environments where team members don't feel safe sharing honest feedback. This foundation must be established first.

3. Actions speak louder than words: Teams quickly recognize empty exercises. If retrospective outcomes aren't implemented, people will lose faith and stop participating. Make sure you follow through.

The Mechanics of Start, Stop, Continue

The beauty of this approach is due to its simplicity.

Start, Stop, Continue is a framework that tries to get you and your team to categorize all of the aspects of work in the team (planning, execution, reviews, communication, and so on) into three simple categories:

• Things we should start doing (before starting a new code change, see if there are open pull requests to review),

• Things we should stop doing (submitting pull requests that are longer than X lines), and

• Things we should continue doing (keep the stand up to 15 minutes).

Here's how I structure these sessions:

Gathering "Start" Items

I ask: "What practices should we begin implementing that we currently don't do?"

Common themes I've seen across teams include:

• Earlier stakeholder demos

• More rigorous code review practices

• Better preparation before refinement meetings

• Cross-functional pairing opportunities

• More well-defined tasks

Finding the "Stop" Items

Next question: "What's currently slowing down our productivity or quality?"

Frequently mentioned items include:

• Context switching between multiple stories

• Late-sprint testing bottlenecks

• Inconsistent documentation practices

• Meeting overload

• Changing priorities mid sprint

Recognizing "Continue" Items

Finally: "What positive practices have we recently adopted that require reinforcement?"

This category functions as a temporary holding area. Once practices become second nature, they graduate from the list.

The Decision Framework

After generating ideas, decision-making becomes critical.

You now need to decide which items on the board (across all categories) you want to talk about.

There may be some retrospectives where you decide as a team that the most important items to talk about are all In the “start” category, there may be some meetings where you talk about items from the Start, Stop, and Continue categories. It really depends on what is deemed by the team to be the most important items that need addressing.

Here’s my preferred approach to picking the most important topics to discuss:

1. Group similar items for clarity. Are there three items on the board that are to do with different aspects of stability? Group them into one.

2. Allocate three votes per team member. Giving people limited options means that their votes truly matter. If you ask people to tag any items they see as important, you’ll more than likely get an overwhelming number of action items.

3. Select the top 2-3 items for action. It’s not possible to make too many changes in one go or in one sprint. Choosing 2-3 means that you are likely to be able to achieve them. Starting each retro by highlighting missed action items can be demoralizing. Limiting your action items hopefully mitigates this.

4. Assign clear ownership for each item. One person needs to lead each action item. Without clear ownership, the bystander effect is likely to happen.

The key insight: changing too many things simultaneously dilutes focus. A few well-implemented changes outperform numerous half-hearted attempts.

Avoiding Retrospective Monotony

Repetitive formats lead to diminishing returns.

There are various ways that you can “spice up” the Start, Stop, Continue framework to make sure that people don’t get bored and just go through the motions.

Some of the processes below augment the Start, Stop, Continue process changing it slightly to keep it interesting.

I've developed several variations to keep the process engaging:

• Silent brainstorming: Everyone writes ideas on sticky notes before sharing

• Theme-focused: Concentrate on specific areas (for example, "testing practices" or "collaboration"). Only do Start, Stop, and Continue on the chosen topic.

• Data-driven: Begin by examining sprint metrics, then discuss implications. Look at the sprint burndown, the velocity, the story breakdown and do Start, Stop Continue based on the data that you see. For instance, “Start breaking stories down to smaller chunks so that each story can be delivered quicker giving us a more smooth burndown”

• Rotating facilitation: Have different team members lead each retrospective. People engage more if they are actively leading a meeting. They will find ways to keep the others engages as well as they want to do a good job of running the meeting.

• Talking stick: Use a physical stick (yes, I’m serious) as a talking stick and only the person holding can talk. They are allowed to talk about whatever they want, good, bad, or indifferent. You can have one person taking the notes of what the person with the talking stick is saying. For instance, the person with the talking stick might say "I’d like to reduce the number of project meetings within the Sprint”. The meeting facilitator could then translate this to “Stop having so many project meetings in the sprint” and put it on the board.

The Mathematics of Team Improvement

Here's something rarely discussed in Agile circles but frequently mentioned in finance: the power of compounding. Just as compound interest transforms modest savings into significant wealth, small team improvements compound over time.

Consider this: A team implementing just one meaningful improvement per sprint will see huge results after a year. If each improvement increases efficiency by just 2%, the compounding effect after 26 two-week sprints is remarkable.

Teams that understand this principle outperform those making sporadic large changes.

Maintaining Continuity Between Retrospectives

I maintain a living document tracking all retrospective outcomes.

Before each new session, I review:

• Which items were successfully implemented

• Which items need continued attention

• Which items were dropped and why

This creates an improvement narrative that demonstrates the team's evolution.

Why This Framework Delivers in Real-World Scenarios

Having implemented this across multiple organizations, from startups to established enterprises, I've found the Start, Stop, Continue model succeeds because:

1. It creates immediate clarity on what requires action

2. It balances recognition of successes with acknowledgment of challenges

3. It creates a sustainable improvement cycle without overwhelming the team

4. It focuses on behavioral changes rather than vague aspirations

The best retrospectives I've facilitated didn't just improve processes—they transformed team cultures by establishing continuous improvement as a fundamental value.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

If you work on a Scrum team, you’ve probably heard of a daily scrum, sometimes called a daily stand-up. It’s one of the key events in scrum.

The “daily” usually takes place around the same time every day, and it should last around 15 minutes.

At first glance, it seems straightforward. When it’s your turn, you answer three basic questions. Job’s done, right?

Well, without a structure and someone to enforce that structure, a 15 minute daily meeting can turn in to a 45 minute chat.

What Is the Daily Scrum?

Scrum teams use the daily scrum to align and share their efforts.

Each person usually answers three questions:

1. What did I do yesterday to help the team meet its goal?

2. What do I plan to do today to help the team meet its goal?

3. Are there any obstacles in my way?

I call these the “classic three.” Yesterday, Today, Blockers.

From this explanation, if you’ve never attended a daily scrum, you might assume it’s just a trivial and pretty pointless meeting. But it can highlight important issues in real time.

For instance, if someone says, “I’m stuck waiting for a database script to finish,” the rest of the team can suggest a workaround.

Or if the product owner says, “We need to shift a feature’s priority,” everyone learns about it immediately.

Why Keep the Scrum Short?

In theory, the daily scrum lasts 15 minutes, give or take. Yet, many teams allow it to stretch to half an hour or more.

That’s risky.

When these meetings grow too long, people lose interest. Also, they might skip the next one, feeling like it’s a waste of time.

Beyond this, brevity encourages people to share only what matters most.

If someone dives into intricate details, it might derail the conversation.

This is not the space for describing every table in your database schema. It’s a moment to share your progress, highlight your plan, and let your teammates know if you’re blocked.

The Three Essential Questions

The daily scrum usually follows the same pattern. It’s predictable, and that’s a good thing.

Let’s expand on each question:

1. Yesterday’s Tasks: This is an update on what you finished. For instance, I might say, “I set up the new testing environment for our user login feature.” That helps the rest of the team see how tasks are progressing and whether I’m finishing my part of the sprint goal.

2. Today’s Plans: Next, we share what we’re about to tackle. For example, “Today, I’m going to fix a bug in the payment service.” That piece of information helps everyone see how the day’s work lines up with the sprint backlog.

3. Blockers: This is a crucial point. If something is stopping me from completing my tasks, I mention it here. Let’s say, “I need access to the staging environment, but I’m waiting on a permissions update to give me access.” This means if anyone on the team can fix that, we speed up progress.

In my teams, we usually have the Jira board open and associate each person’s update with the related story. This gives people a little more context. You don’t have to do this though – my teams just find it helpful.

How to Prevent the Scrum from Turning into a Status Meeting

A daily scrum is not just a status report. It’s a chance for the team to realign quickly.

But some managers treat it as a time to see who is on track. That can shift the focus away from cooperation. On the other hand, a team might treat it like a casual hangout without any structure. These extremes usually lead to frustration.

What’s the sweet spot?

It’s where the team focuses on tasks that lead to the sprint goal while also offering quick help when people get stuck.

The meeting should be about collaboration and the scrum team’s needs, not about pleasing a manager.

Also, if something requires a deeper talk, schedule a follow-up. For instance, you might say, “Let’s finish the stand-up, then we can chat about the modeling question after”.

If you find that your stand ups are getting too long, you as a team need to discuss why this is happening in the sprint retro and adjust.

A Typical Example of a Smooth Daily Scrum

Let’s paint a quick picture.

The team is working on a feature that handles user registration and payment processing. Each day, the daily scrum goes like this:

1. Developer A:

   • Yesterday, I cleaned up the user registration form.

   • Today, I’ll add form validation for email.

   • I’m blocked by a missing API key, so if someone can share that, I can move forward.

2. Developer B:

   • Yesterday, I tested the payment integration.

   • Today, I’ll fix a bug I found during testing.

   • No blockers.

3. QA Engineer:

   • Yesterday, I automated tests for the cart service.

   • Today, I’ll check the new user registration form.

   • No blockers, but I want to set up a quick chat about test coverage soon.

The entire process finishes in around 10 minutes. After the scrum, Developer A and Developer B might stay behind to swap that missing API key. Everyone else dives into their day. That’s it—short, sweet, and useful.

Common Problems That Disrupt the Daily Scrum

Let’s discuss a few pitfalls I’ve seen crop up over the years:

1. Going off on tangents: For instance, a developer might begin describing the entire architecture of a new microservice. The rest of the team is left wondering how that affects them.

2. Trying to solve every issue in real time: The daily scrum is not the place to debug code or solve other issues as a group. If something complex needs discussion, note it and talk after the stand-up with the interested parties.

3. Waiting for latecomers: Starting late can quickly become a habit. If people learn that the meeting really begins at 9:05, they start arriving at 9:10. The easiest fix is to start on time. People usually adapt once they see you’re serious.

4. No one mentions blockers: Sometimes, folks feel uncomfortable admitting a problem in front of the team. If that happens, the daily scrum loses its value. This meeting is precisely where you should feel safe to say, “I’m stuck here.”

5. Too many people in the meeting: In certain organizations, multiple teams join one daily scrum. That can lead to confusion. It’s better to keep each daily scrum small and focused. If you have a big project, you might break out into smaller Scrum teams.

Tips for Keeping the Meeting on Track

There are various ways you can help keep a daily scrum from devolving into a long, drawn-out meeting.

First, make sure you stick to 15 minutes (or shorter). A timer can really help. Some teams use an actual countdown on a screen, which can be fun. If you find that it’s consistently longer, it may be a sign that you have too many people, your team members need reminding about the format, and so on.

Second, make sure you have a capable leader who understands how to manage the scrum. Often, the scrum master or team lead can step in if the conversation strays. They might say, “Good point. Let’s park that for later.” This ensures the scrum doesn’t balloon into a brainstorming session.

You should also make sure the team is focusing on its sprint goals during the meeting. In addition to sharing tasks, remember why you’re doing them. For instance, if you know the sprint goal is to launch a new checkout flow, keep that in mind. This will help streamline everyone’s three questions.

Next, make sure you promote a culture of help. If someone mentions a blocker, invite the group to see who can help. This is a practical approach that fosters teamwork.

And finally, it can be helpful to use the scrum board. This board—whether physical or digital—helps people visualize progress. If your tasks are on sticky notes or in a tool like Jira, you can quickly show which tasks are done, in progress, or awaiting review.

Practical Ways Managers Can Support the Daily Scrum

Some folks ask if managers should attend the scrum every day. There’s no strict rule, but if you do join, here are some things to keep in mind to help your team stay on track.

First, make sure you let the team speak. The daily scrum is for the development team to share their plan and blockers. You as a manager should avoid turning it into a performance check.

Next, try to observe any ongoing or developing patterns. The manager can spot trends. For instance, if a certain issue keeps popping up, they might escalate it or allocate more resources toward solving it.

And try to offer help without dominating the meeting. The moment you sense a roadblock your position can solve—like a missing budget approval—step in. Otherwise, let the team own the meeting.

Frequently Asked Questions

1. How strict is the 15-minute rule?

   Pretty strict if you can help it. If your team is small, you may finish in even less time.

2. Do we need to stand physically?
   Some say it keeps the meeting short. Others aren’t able to stand, or prefer to sit. In my teams, the goal is brevity, so sitting or standing doesn’t matter as much. We also usually have a hybrid stand up where some people are in the office and some aren’t. For this, we all attend virtually.

3. What if we have nothing new to say?
   That’s fine. A quick “No updates, no blockers” is perfectly acceptable. The meeting might take only five minutes. Great—everyone can get back to work sooner.

4. Do we ever skip the daily scrum?
   Some teams do skip if everything is stable. I never do though, because it confirms that no new blockers have emerged. It’s like a brief pulse check. If there’s nothing to share, the meeting won’t last long anyway.

5. Who speaks first?
   Some teams pass a “talking stick” around in a circle. Others follow the order of tasks on the board. I’ve even seen teams do it alphabetically. I also like to mix it up by playing the “nomination game” where the person speaking nominates the next person. The method doesn’t matter, as long as everyone gets a turn. I do like to mix the ordering up though as it keeps the meeting a little “fresh”.

Conclusion

The daily scrum can be one of the most helpful parts of Scrum if it’s done right. It helps with open communication, early detection of blockers, and a sense of shared ownership.

Also, it reminds us what we’re aiming to achieve as a team (the sprint goal), which is easy to forget when everyone’s heads are down coding or testing.

Above all, keep it simple. Focus on yesterday’s progress, today’s plan, and any obstacles in your path.

If you need deeper conversations, schedule them right after the scrum with the people who care most about the topic. That way, you respect everyone else’s time.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

I’ll take you through what user stories are, common pitfalls that I’ve seen with creating user stories, and the frameworks that exist to validate if your user story is “good”.

Here’s what we’ll cover:

• The beginnings of Agile

• What is Agile?

• What is a User Story?

  • Structure of a User Story

  • Example of User Stories

• How to make good User Stories

• Common pitfalls in User Story creation

  • Focusing on the technical aspects

  • Stakeholder Collaboration

  • Vague User Stories

• How to begin with User Stories

• Conclusion

The Beginnings of Agile

Chances are that you’ve heard of Agile Development and User Stories. But if you haven’t, let’s have a brief history lesson:

User Stories are part of a larger concept called Agile methodologies.

Agile methodologies have been around since 2001 when 17 well-respected software engineers met at a Ski resort in Utah and created the now infamous Agile Manifesto.

If names such as Robert Martin, Martin Fowler and Kent Beck don’t mean anything to you, once you’ve finished this article, go and search them out. They have a wealth of knowledge and between them gave the world of software a more fluid way of delivering projects, called Agiile.

What is Agile?

Agile is more of a way of thinking than a prescribed method. Prescribed methods exist, such as Scrum and Kanban, but Agile is a concept.

Agile promotes collaboration, fast feedback, and delivering value often to the user.

The Agile way of thinking encourages flexibility in project planning, which is in stark contrast to its competitor at the time, Waterfall project planning, which was very rigid with what was being delivered and when.

Agile methodologies promote doing “just enough” research at the beginning to get the project started, and then learning, iterating, and changing the design and deliverable as needed throughout the project until the final code is delivered. This “change and learn as you go” approach is called “adaptive planning”.

Agile promotes delivering something of value quickly and often, usually in the form of delivering code to production at the end of every two week “sprint”. This, again, is very different from traditional waterfall planning which would often require months of development before any user-visible change could be delivered to production.

Another key part of Agile is the focus it puts on stakeholders working together closely and often. Product, QA, Engineering, and Sales all have a large input and constant feedback on the project through the project lifecycle.

Now that you know a bit more about how Agile works, let’s dive deeper into how we validate value to the user.

Enter the User Story.

What is a User Story?

A user story is way in plain English to connect the engineer to the end goal of the software.

It’s designed so that a non-techy can read it and understand what is being delivered, and so that an engineer can look at it and see the value and how to validate that you’ve delivered that value.

Structure of a User Story

As a [type of user], when I [perform action], [expected outcome]

At its most basic, that is it.

You are putting the emphasis on the end user and the “value” that you will deliver.

Let’s dig into the inputs:

• Type of user: There is no one size fits all “user”. You have “admin users”, you have “logged-in users”, you have “users with permission X” or “users in role Y”. This is being specific about who is performing the action

• Perform action: What is the user doing? Clicking the “login” button? Deleting a record? Submitting a form?

• Expected outcome: Once your user has performed the action, what should happen? If they’ve clicked “login” with the correct email address and password, where should they be directed? If they’ve clicked “login” with an incorrect email address and password, what should happen?

Example of User Stories

Let’s look at examples of user stories for a login page.

There’s nothing better than examples.

Let’s set the scene. You have a login page with an entry text box for an email address and an entry text box for a password. You have a submit button. That’s it.

What are the different permutations that can happen on this page from the user’s perspective?

As a logged in user, when the page loads, I am redirected to the logged in home page

If I’m already logged in, I don’t want to have to reenter my details, just redirect me to the logged-in home page.

As a non logged in user, when I enter the correct email address but incorrect password and click Login, an error message appears

I’m a user who’s not already logged in, and I entered the incorrect details. I should not be logged in.

As a non logged in user, when I enter an incorrect email address and password and click login, an error message appears.

Again. I’m not a logged-in user. I’ve entered incorrect details, I should not be logged in.

As a non logged in user, when I enter the correct email address and password and click login, I am rediected to the logged in home page.

This time, I’m not already logged in, I enter the correct details and click login. I’m logged in to the system.

Can you see how all of these are focused on the user?

You may notice that some of the “expected behaviour” in the above is not fully defined. We’ll address that later in the acceptance criteria.

How to make good User Stories

There’s a good model called the INVEST model that really simply shows how to know if your user stories are good.

INVEST Model:

• Independent: Can be developed separately.

• Negotiable: Open to discussion and change.

• Valuable: Delivers value to the user.

• Estimable: Can be estimated for effort.

• Small: Fits within a sprint.

• Testable: Has clear acceptance criteria.

Let’s apply this INVEST model to one of the user stories examples from above:

As a non logged in user, when I enter the correct email address and password and click login, I am rediected to the logged in home page.

(I’m going to make some assumptions here, as this is a theoretical code base and theoretical project)

Is this story Independent? I would say so, yes. It’s a small story that involves only a few components that probably already exist. If the database hasn’t been created yet though for the project, that would give us a dependency. This would no longer be independent.

Is it Negotiable? Well again, yes. This story could easily be changed to redirect to the users profile page rather than their home page.

This story is definitely valuable. Once implemented, the user can log in. If the story was:

As a non logged in user, when I enter the correct email address and password and click login, nothing happens

This would not be valuable. The user would get nothing out of this.

Is the story estimable? Again, we have to take some assumptions in this made up scenario, but I would certainly hope that this would be easily estimated. It’s a concise story, involving few components, in a domain that everyone is familiar with and has clear acceptance criteria.

The story is certainly small. There is little ambiguity in what needs to be done, there is one user path only and clear outcomes. Let’s take a look at a story that would be too large:

As a non logged in user, the login page should work as expected.

As discussed further up in this article, there are many ways that the login page can and should work. “Should work as expected” seems to cover all of those permutations. This would be too large to effectively size as a story, and probably too large to be completed in one sprint.

The story is definitely Testable. There are clear user actions to take that has a clear outcome. This user story can be covered by Unit Tests, Integration Tests, and Manual Tests.

It looks like we’ve created a good user story!

If you use the structure I’ve defined above, and the story meets the criteria of the INVEST model, it’s probably a good story.

Common pitfalls in User Story creation

I’ve seen User stories go wrong in the past where people have missed a few crucial aspects to the user story:

Focusing on the technical aspects

As my examples show above, the user story is non-technical.

There should be no reference to a service name, a database name, or validation based on anything that the user can’t see.

As soon as your story is no longer able to be understood by the end user, you’ve gone wrong.

Focus on what the user is going to do, and what the user is going to see.

Let’s look at an example of a technically focused story:

As a non logged in user, when I click the forgotten password link with a correct email address, a record is logged in a database table stating that the password reset link has been sent.

This story can not be verified by a user and non technical users may not understand what it means.

Let’s fix it:

As a non logged in user, when I click the forgotten password link with a correct email address, an email is sent to the email address provided with a forgotten password reset link

Non technical users can understand this and it puts the focus on the user, not the product.

Stakeholder Collaboration

Agile is collaborative.

User stories need input from Product, BA, QA, Engineers, and most importantly, Users.

This is how you will ensure that you are delivering what the user wants. Many hands make light work.

If, for instance, just an engineering team came up with user stories, they may look something like this:

As a logged in user, when the page loads, I am redirected to the logged in home page

As a non logged in user, when I enter the correct email address but incorrect password and click Login, an error message appears

As a non logged in user, when I enter an incorrect email address and password and click login, an error message appears.

And that’s great. But now let’s get QA involved, who are coming from a different perspective as they’ve different experiences with software:

As a non logged in user, when I enter a correct email address in Hebrew and a correct password, I am redirected to the home page

As a non logged in user, when I enter a correct email address and password and repeatedly click login, I am redirected to the home page

Great. We’re getting a more rounded set of user stories now that cover more situations. But what happens if we get Product involved?

As a non logged in user, when the page loads, my password manager should pre-load my username and password, when I click login, I am redirected to the home page

The Product team know the users. They know that people really use password managers. We should make sure that when the user doesn’t actually type anything (as the text is loaded by the password manager), the login still works correctly.

Vague User Stories

The idea behind a good user story is that everyone, regardless of expertise, can understand it.

If you’ve written a User Story that. can be interpreted 10 different ways by 10 different people, you’ve gone a bit wrong.

I mentioned above that I would touch on acceptance criteria, and now is the time to do that.

Let’s re-examine the following User Story:

As a non logged in user, when I enter an incorrect email address and password and click login, an error message appears.

There’s vagueness in there.

What message should appear? When the page reloads after an invalid login attempt, should the username text box be set back to empty, or prepopulated with the previously entered value? What does “incorrect email address” mean? An email address that has never been seen before, or an email address that is not valid at the moment (not paid the subscription, canceled subscription etc.)

So as you can see, details matter.

This User Story is a fairly contrived simple example and I’ve managed to find a lot of questions about it.

Let’s fix the problem:

As a non logged in user, when I enter an email address that it not registered with the system, when I click login, an error message appears

That removed the questions around the user action but has not resolved the issue about the expected error message.

Enter the acceptance criteria.

Within the user story, you need to have a set of acceptance criteria that defines if the implementation of the user story is as expected.

Things like:

• Error message: “Invalid email address or password”

• Email Address and Password text box reset to empty on reload

• User unable to access pages where login is required

• User is presented with a “forgotten password” suggested.

Acceptance criteria states what is expected from the implementation.

How to Begin with User Stories

Start small.

You will not be perfect at refining and creating user stories to start with.

Creating user stories is as much an art as a science. Practice makes perfect.

The creation of User Stories should be done as a group. Often, this is done with the “3 Amigoes” approach, where you will have an engineer, a product person and a QA all sit together and brain storm different permutations that you need to support.

Once you have delivered your project, retrospect. Take a look back and see what gaps you have in your user stories. There will be bugs that the users find, that QA and UAT find, and these are either due to gaps in your user stories or gaps in your testing. Either way, you should learn from them for next time.

Conclusion

Agile is collaborative. Scrum is collaborative. Creating User Stories is collaborative. Remember that.

The more people from different areas of expertise you have brainstorming user story creation, the more likely you are to cover the full set of workflows.

The user is the focus. If you are ever including terminology that your user doesn’t understand, rethink the user story.

You won’t be perfect at this from the start, but as you do more and more, the quicker and more effective you become. Take this from someone who has been doing this for over 10 years. The difference in speed and quality of my User Story creation today vs 10 years ago is a world apart.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

Traditional software development methods often struggled to keep up with changing requirements and market demands. This can lead to delays, cost overruns, and dissatisfied stakeholders.

In response to these challenges, the Agile Software Development approach emerged as a game-changer, revolutionizing the way software projects are executed.

At its core, Agile Software Development is not just a set of methodologies. It represents a fundamental shift in the way teams approach problem-solving and collaboration.

The Agile approach emphasizes iterative and incremental development. It focuses on delivering value to the customer early and often while adapting to feedback and changing requirements throughout the development process.

A key milestone in the history of Agile was the Agile Manifesto. It was formulated in 2001 by a group of experienced software developers who sought to find a better way of developing software.

The manifesto laid out four core values:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.

3. Customer collaboration over contract negotiation.

4. Responding to change over following a plan.

These values provided a guiding light for the creation of various Agile methodologies, with Scrum and Kanban being two of the most widely adopted frameworks.

Scrum, based on the Agile principles, is a well-defined and structured approach to software development.

It provides a clear set of roles, ceremonies, and artifacts that foster efficient teamwork, transparency, and continuous improvement.

On the other hand, Kanban, inspired by lean manufacturing principles, focuses on the continuous flow of work, limiting work in progress, and maximizing the delivery of value.

However, Agile Software Development goes far beyond Scrum and Kanban. There are several other methodologies and practices, such as Extreme Programming (XP), Lean Software Development, and more, each with its unique strengths and applications.

In this handbook, we will delve deep into the world of Agile Software Development, exploring the core principles that underpin its success.

We will take a close look at Scrum and Kanban, understanding their frameworks, benefits, and challenges.

Moreover, we will explore other Agile methodologies that offer alternative approaches to delivering high-quality software products.

Whether you are an experienced software developer, a project manager, or a newcomer to the Agile landscape, this guide is for you. It aims to provide valuable insights into how Agile methodologies work, the benefits they offer, and how to make the most of them to achieve successful software projects.

So, without further ado, let's embark on this journey. Get ready to discover the power of Agile and its potential to transform the way you and your teams approach software development.

Table of Contents

• Introduction

• Agile Software Development Fundamentals‌‌

1. Principles of the Agile Manifesto‌‌

2. Iterative and Incremental Development‌‌

3. Cross-functional Teams and Collaborative Environment

• Scrum: A Comprehensive Approach‌‌

1. Overview of Scrum Framework‌‌

2. Benefits and Advantages of Scrum‌‌

3. Scrum Challenges and How to Overcome Them

• Kanban: Flow-based Development‌‌

1. Introduction to Kanban Methodology‌‌

2. Kanban Principles and Practices‌‌

3. Comparison with Scrum: When to Use Kanban?‌‌

4. Advantages of Kanban

• Extreme Programming (XP): A Development Approach‌‌

1. Overview of Extreme Programming‌‌

2. Core Practices of XP‌‌

3. Pros and Cons of Extreme Programming

• Lean Software Development: Agile with a Focus on Value‌‌

1. Understanding Lean Principles‌‌

2. Application of Lean in Software Development‌‌

3. How Lean Complements Scrum and Kanban

• Agile Project Management Tools and Software‌‌

1. Project Tracking and Collaboration Tools‌‌

2. Benefits of Agile Project Management Tools‌‌

3. Popular Tools for Scrum, Kanban, and Other Agile Methodologies

• How to Choose the Right Agile Approach for Your Team‌‌

1. Factors to Consider When Selecting an Agile Methodology‌‌

2. How to Tailor Agile Practices to Suit Your Organization

• Agile Scaling: Beyond the Team Level‌‌

1. Understanding Agile Scaling‌‌

2. Popular Agile Scaling Frameworks‌‌

3. Benefits of Agile Scaling‌‌

4. Challenges and Considerations

• Agile and DevOps: Integration for Continuous Delivery‌‌

1. Agile and DevOps: A Natural Partnership‌‌

2. The Journey to Continuous Delivery‌‌

3. Benefits of Agile and DevOps Integration‌‌

4. Overcoming Challenges

• Future Trends in Agile Software Development‌‌

1. Agile at Scale‌‌

2. Value Stream Management (VSM)‌‌

3. Agile and AI/ML Integration‌‌

4. Agile for Non-Software Projects‌‌

5. Agile and Remote Work

• Conclusion‌‌

Agile Software Development Fundamentals

Agile Software Development is built upon a strong foundation of core principles and values that prioritize customer collaboration, adaptability, and continuous improvement.

In this section, we will explore the fundamental tenets of Agile and gain a deeper understanding of the principles that guide its implementation.

Principles of the Agile Manifesto

The Agile Manifesto is a set of guiding values and principles for software development that emphasizes flexibility, collaboration, and customer satisfaction.

As stated earlier, it was created by a group of seventeen software developers who met in February 2001.

This group consisted of representatives from various software development methodologies, including Extreme Programming (XP), Scrum, DSDM (Dynamic Systems Development Method), and others.

They came together to find common ground and establish a more people-centric and flexible approach to software development.

The Agile Manifesto consists of four core values and twelve principles that provide a framework for teams to deliver high-quality software in a more adaptive and responsive manner

Four Core Values

Individuals and interactions over processes and tools

Agile emphasizes the importance of people and their interactions as the primary drivers of project success. Effective communication, collaboration, and teamwork are vital in Agile environments, fostering a sense of ownership and responsibility among team members.

Working software over comprehensive documentation

While documentation remains essential, Agile prioritizes the delivery of working software that meets customer needs. Frequent and incremental releases allow stakeholders to see tangible progress and provide valuable feedback throughout the development process.

Customer collaboration over contract negotiation

Agile encourages close collaboration with customers and end-users. This customer-centric approach ensures that the software being developed aligns with their evolving needs, increasing the likelihood of delivering a product that satisfies their requirements.

Responding to change over following a plan

Agile acknowledges that change is inevitable in software development. Rather than rigidly adhering to a fixed plan, Agile teams embrace change and view it as an opportunity for improvement.

Frequent iterations enable teams to adapt to new information and feedback, fostering a more responsive development process. Agile software development thrives on change and adaptability, making flexibility the heartbeat of its success.

Twelve Agile Development Principles:

I've paraphrased the 12 principles from the Agile Manifesto here for you:

1. Prioritize satisfying the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, with a preference for shorter timescales.

4. Collaborate closely between business people and developers throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. Use face-to-face communication whenever possible for effective information sharing.

7. Measure progress primarily through working software.

8. Maintain a sustainable pace of work for the development team. Continuous work is sustainable work.

9. Focus on technical excellence and good design to enhance agility.

10. Keep things simple and maximize the amount of work not done (avoid unnecessary tasks).

11. Allow self-organizing teams to make decisions on how to accomplish their work.

12. Reflect at regular intervals on team effectiveness and adjust behavior accordingly.

Iterative and Incremental Development

At the heart of Agile lies the concept of iterative and incremental development. Unlike traditional "waterfall" methods, where all development occurs sequentially in one large phase, Agile divides the software development process into smaller iterations or time-boxed cycles.

Each iteration results in a potentially shippable increment of the software, with new features or improvements being added in every cycle.

This iterative approach offers several advantages:

• Early Value Delivery: Customers can start using and benefiting from the software early in the development process, gaining tangible value with each iteration.

• Continuous Feedback: Frequent releases allow stakeholders to provide feedback, guiding the development direction and ensuring that the final product aligns with their expectations.

• Risk Mitigation: By breaking the project into smaller chunks, Agile reduces the risk associated with large-scale development, making it easier to adjust and adapt to changes.

• Increased Transparency: Teams and stakeholders have a clear view of progress, making it easier to identify and address potential issues or delays.

Cross-functional Teams and Collaborative Environment

Agile emphasizes the importance of cross-functional teams, where members possess diverse skills and expertise needed to deliver a complete product.

These teams work together in a collaborative environment, promoting shared responsibility, knowledge exchange, and collective ownership of project outcomes.

The cross-functional nature of Agile teams fosters a sense of empowerment. Team members are encouraged to make decisions collectively, take ownership of tasks, and resolve challenges collaboratively. This dynamism enables faster problem-solving, improved creativity, and a more resilient team structure.

Moreover, Agile methodologies often embrace practices like pair programming, where two developers work together on the same piece of code. This leads to higher code quality, knowledge transfer, and reduced knowledge silos within the team.

The fundamentals of Agile Software Development revolve around valuing people and interactions, focusing on delivering working software, collaborating closely with customers, and responding to change in a flexible manner.

By employing iterative and incremental development and fostering a collaborative team environment, Agile lays the groundwork for efficient and customer-focused software development processes.

In the next sections, we will delve into specific Agile methodologies like Scrum and Kanban to see how these principles are put into action.

Scrum: A Comprehensive Approach

Scrum is one of the most widely adopted Agile frameworks in the software development industry. It provides a structured and comprehensive approach to managing projects, enabling teams to deliver high-quality software efficiently.

In this section, we will explore Scrum in detail, understanding its framework, key roles, artifacts, ceremonies, and the benefits it brings to software development teams.

Overview of Scrum Framework

The Scrum framework is built on the foundation of Agile principles and is designed to maximize productivity, foster collaboration, and deliver value to customers.

It consists of three essential elements:

Scrum Roles

Product Owner: The Product Owner is the voice of the customer and stakeholders. They are responsible for defining and prioritizing the product backlog, ensuring that the development team is working on the most valuable features.

The Product Owner collaborates with stakeholders to gather requirements and provide feedback on delivered increments.

Scrum Master: The Scrum Master acts as a facilitator and servant-leader for the development team. Their primary role is to ensure that the Scrum framework is understood and followed correctly.

They remove any impediments that hinder the team's progress, promote a collaborative team environment, and facilitate the various Scrum ceremonies.

Development Team: The Development Team consists of professionals who do the actual work of delivering a potentially shippable product increment in each sprint. They are self-organizing, cross-functional, and collaborate closely to complete the tasks from the sprint backlog.

Scrum Artifacts

Product Backlog: The Product Backlog is a prioritized list of all the work items required to complete the project. These items can include features, enhancements, bug fixes, and technical tasks.

The Product Owner continuously refines and updates the backlog based on feedback and changing requirements.

Sprint Backlog: Before each sprint, the Development Team pulls a set of work items from the Product Backlog and creates the Sprint Backlog.

The Sprint Backlog contains the tasks the team commits to completing during the sprint. It provides transparency and a clear plan for the upcoming iteration.

Increment: The Increment represents the sum of all completed Product Backlog items at the end of each sprint. It is a potentially shippable piece of software that should be in a usable state and adhere to the team's definition of "done."

Scrum Ceremonies

Sprint Planning: At the beginning of each sprint, the Product Owner and Development Team collaborate in the Sprint Planning meeting. They discuss and agree on the sprint goal, select the top items from the Product Backlog, and create the Sprint Backlog with associated tasks.

Daily Standup (Daily Scrum): The Daily Standup is a brief daily meeting where the Development Team synchronizes their work. Each team member shares what they worked on the previous day, what they plan to work on that day, and any impediments they are facing.

Sprint Review: At the end of each sprint, the team holds a Sprint Review meeting to demonstrate the completed Increment to stakeholders. Feedback is gathered, and the Product Backlog is updated based on the stakeholders' input.

Sprint Retrospective: Following the Sprint Review, the team conducts the Sprint Retrospective to reflect on the previous sprint. They identify what went well, what could be improved, and define actionable items to enhance their processes in the upcoming sprints.

Benefits and Advantages of Scrum

Scrum offers a number of benefits that contribute to its popularity and success in Agile software development:

1. Transparency: The use of visible backlogs, frequent progress updates, and regular meetings ensures transparency among team members and stakeholders. This fosters a shared understanding of the project's status.

2. Adaptability: Scrum's iterative nature allows teams to adapt to changing requirements and priorities. This ensures that the delivered product remains aligned with the customer's needs.

3. Continuous Improvement: The Sprint Retrospective encourages continuous improvement by providing a platform for the team to reflect on their practices and identify opportunities for enhancement.

4. Early Value Delivery: The focus on delivering potentially shippable increments at the end of each sprint allows customers to see tangible progress early in the development process.

5. Customer Collaboration: The involvement of the Product Owner and regular Sprint Reviews promote active collaboration with customers, resulting in a product that better meets their expectations.

Scrum Challenges and How to Overcome Them

While Scrum is highly effective, it is not without its challenges. Some common hurdles that teams may encounter include:

1. Overcommitment: Teams might take on too much work in a sprint, leading to incomplete tasks and a compromised Increment. Regularly evaluating capacity and being realistic about commitments can help avoid this pitfall.

2. Lack of Empowerment: If team members are not empowered to make decisions and are overly dependent on the Scrum Master, the efficiency and effectiveness of the team may suffer. Encouraging self-organization and trust within the team can mitigate this challenge.

3. Incomplete Definition of "Done": Ambiguity about what constitutes a "done" user story can lead to misunderstandings and incomplete work. Clearly defining and agreeing upon the team's "definition of done" is crucial for consistent delivery.

4. Product Owner Availability: Insufficient availability of the Product Owner can slow down decision-making and result in unclear requirements. Maintaining constant communication and involvement with the team can help alleviate this issue.

Scrum provides a structured and comprehensive approach to Agile Software Development, offering a well-defined set of roles, artifacts, and ceremonies that facilitate collaboration, transparency, and continuous improvement.

By embracing Scrum's core principles and addressing its challenges proactively, development teams can harness the full potential of this framework to deliver successful software projects.

Kanban: Flow-based Development

Kanban is a highly versatile Agile methodology that emphasizes continuous delivery and flow-based development.

Originally developed in the manufacturing sector, Kanban has found widespread adoption in software development due to its efficiency and adaptability.

In this section, we will explore Kanban in-depth, understanding its principles, practices, and how it complements Scrum and other Agile methodologies.

Introduction to Kanban Methodology

The word "Kanban" translates to "visual signal" or "card" in Japanese.

In the context of software development, Kanban involves visualizing the entire workflow on a board, where work items are represented as cards that move through different stages of development.

The primary goal of Kanban is to optimize the flow of work, reduce waste, and enable teams to deliver value continuously.

Unlike Scrum, which works in fixed time-boxed iterations (sprints), Kanban operates on a continuous flow model.

This flexibility makes Kanban particularly well-suited for teams with unpredictable workloads, frequent changes in priorities, or the need for quick response times.

Kanban Principles and Practices

1. Visualizing Work Items: The Kanban board serves as a central visual management tool. It represents the workflow, with columns representing different stages of the development process. Work items, represented as cards, move across the board from left to right as they progress through each stage.

2. Work in Progress (WIP) Limits: Kanban enforces Work in Progress (WIP) limits for each column on the board. These limits prevent teams from overloading themselves with too many tasks at once, promoting focus and higher-quality output. WIP limits also highlight bottlenecks in the workflow, allowing teams to identify and address inefficiencies.

3. Continuous Delivery and Flow: Kanban aims to maintain a steady flow of work items from inception to delivery. The focus is on completing tasks as they become ready, without waiting for a specific sprint or iteration to end. This continuous delivery approach results in a shorter time to market and more responsive software development.

Comparison with Scrum: When to Use Kanban?

While both Scrum and Kanban are Agile methodologies, they cater to different project environments and team dynamics.

Here are some key points to consider when deciding between Scrum and Kanban:

Predictability vs. Flexibility: Scrum is well-suited for projects with well-defined requirements and predictable workloads. It provides clear sprint boundaries, making it easier to plan and estimate project timelines.

On the other hand, Kanban is more flexible and adapts to changing priorities and frequent interruptions, making it ideal for projects with highly variable workloads.

Time-boxed Iterations vs. Continuous Flow: Scrum's time-boxed iterations provide a rhythm and cadence to development, allowing teams to review progress and gather feedback regularly.

Kanban, with its continuous flow approach, facilitates a smoother and more steady delivery of work items without the need for predefined sprints.

Team Structure: Scrum typically works well with cross-functional teams that commit to delivering a set of user stories in each sprint.

Kanban is more accommodating to specialized teams or environments where resources are shared among multiple projects or priorities.

Learning and Improvement: Both Scrum and Kanban promote continuous improvement, but the approach differs.

Scrum's retrospectives are dedicated events for teams to reflect and adapt. In Kanban, improvement is often embedded in the process, where teams continuously optimize their workflow based on real-time feedback.

Advantages of Kanban

Kanban offers several advantages that make it a powerful methodology in certain situations:

• Increased Flexibility: Kanban's ability to adapt to changing circumstances and priorities makes it suitable for projects with evolving requirements or dynamic environments.

• Smoother Workflow: By limiting work in progress and addressing bottlenecks, Kanban ensures a more predictable and smoother flow of work.

• Quick Response Time: Kanban's continuous delivery model allows teams to respond quickly to new tasks or urgent requests, reducing lead times.

• Focus on Value: Kanban emphasizes delivering value continuously, aligning well with projects that require frequent releases or incremental improvements.

Kanban's flow-based development and continuous delivery approach offer an excellent alternative to Scrum for projects with varying requirements and unpredictable workloads.

By visualizing work, setting WIP limits, and embracing a continuous flow model, Kanban empowers teams to optimize their development processes, enhance collaboration, and achieve a more efficient and responsive software delivery.

Whether used independently or in combination with other Agile methodologies like Scrum, Kanban provides valuable tools and practices for achieving successful software development projects.

Extreme Programming (XP): A Development Approach

Extreme Programming (XP) is an Agile software development approach that embraces a set of best practices and values to deliver high-quality software efficiently.

Created by Kent Beck in the late 1990s, XP challenges traditional development practices by promoting a customer-centric and team-oriented philosophy.

In this section, we will explore the key principles and core practices of Extreme Programming and understand its impact on software development teams.

Overview of Extreme Programming

Extreme Programming is based on a set of values that drive the development process. These values include communication, simplicity, feedback, courage, and respect.

XP encourages open and frequent communication between team members and stakeholders. This simplifies processes and solutions and encourages team members to seek and act upon feedback regularly. Team members are also encouraged to have the courage to make necessary changes and respect the expertise and contributions of all team members.

Core Practices of XP

Test-Driven Development (TDD): Test-Driven Development is a fundamental practice in XP where developers write tests before writing the code.

The process involves creating a test that initially fails, then writing the code to pass the test. TDD ensures that the code is thoroughly tested. This makes it easier to identify and fix issues early in the development process.

Pair Programming: In Pair Programming, two developers work collaboratively at the same workstation. One programmer writes the code while the other reviews it in real-time. This promotes continuous feedback, knowledge sharing, and improved code quality.

This practice enhances team communication and leads to the development of more robust solutions.

Continuous Integration: Continuous Integration involves frequently integrating code changes into a shared repository. This ensures that the software is continuously built and tested as new code is added, reducing integration issues and enabling faster feedback on potential defects.

Collective Code Ownership: XP encourages the concept of collective code ownership, where all team members take responsibility for the entire codebase.

This fosters a sense of ownership and accountability within the team, leading to a collaborative and supportive work environment.

On-Site Customer: In XP, having an on-site customer or a dedicated customer representative is vital for effective communication and quick decision-making.

The on-site customer provides real-time feedback and clarifications, ensuring that the team builds the right features and meets customer expectations.

Pros and Cons of Extreme Programming

Pros:

• High-Quality Code: TDD and Pair Programming lead to better-tested and more maintainable code.

• Fast Feedback: Continuous Integration and frequent releases provide rapid feedback on code changes.

• Customer Collaboration: Involving an on-site customer ensures better alignment with customer needs.

• Adaptability: XP's practices allow teams to adapt to changing requirements and priorities effectively.

Cons:

• Learning Curve: Adopting XP may require a cultural shift and training for team members unfamiliar with its practices.

• Resource Intensive: Pair Programming and on-site customer involvement may require additional resources.

• Initial Overhead: Writing tests before code and maintaining continuous integration can add initial overhead.

Extreme Programming (XP) is a development approach grounded in a customer-focused philosophy and driven by a set of core practices.

By emphasizing test-driven development, pair programming, continuous integration, and collective code ownership, XP aims to deliver high-quality software while promoting effective teamwork and continuous improvement.

Like any methodology, XP has its advantages and challenges, but when applied in the right context with committed team members, it can lead to substantial improvements in software development efficiency and customer satisfaction.

Lean Software Development: Agile with a Focus on Value

Lean Software Development is an Agile approach inspired by the principles of lean manufacturing, which originated from Toyota's production system. It aims to maximize customer value while minimizing waste in the software development process.

Lean principles emphasize efficiency, continuous improvement, and a relentless focus on delivering value to customers.

In this section, we will delve into the core principles of Lean Software Development and explore how it complements Agile methodologies, such as Scrum and Kanban.

Understanding Lean Principles

There are some fundamental principles behind this approach, and they are:

1. Eliminate Waste: Lean Software Development advocates the elimination of non-value-adding activities, often referred to as "waste." This includes avoiding unnecessary bureaucracy, reducing delays, and optimizing resource utilization to ensure that valuable work takes precedence.

2. Amplify Learning: Lean promotes a learning culture, where teams continuously seek feedback and insights from customers and stakeholders. This learning mindset drives continuous improvement, enabling teams to deliver higher-quality products that better align with customer needs.

3. Decide as Late as Possible: Rather than making significant decisions early in the development process when information is limited, Lean encourages postponing decisions until they are necessary. This allows teams to leverage up-to-date information and make informed choices.

4. Deliver as Fast as Possible: Lean Software Development places a premium on rapid value delivery. By shortening the cycle time between idea inception and implementation, teams can respond quickly to changes and deliver customer value sooner.

5. Empower the Team: Lean emphasizes the importance of empowering and trusting team members to make decisions and contribute to the development process. This autonomy fosters a sense of ownership and accountability, driving motivation and creativity.

Application of Lean in Software Development

Lean principles can be applied in various areas of software development to improve efficiency and value delivery:

• Value Stream Mapping: By mapping the entire software development process, teams can identify bottlenecks, inefficiencies, and areas of waste. This helps streamline workflows and optimize the delivery process.

• Minimal Viable Product (MVP): The concept of MVP aligns with Lean principles, where the focus is on delivering the smallest set of features that provides value to customers. This enables faster market validation and feedback gathering.

• Just-In-Time (JIT) Production: Applying JIT principles in software development means delivering work items when they are needed and avoiding stockpiling uncompleted features. This reduces inventory waste and ensures a more responsive development process.

• Kaizen: The principle of Kaizen, or continuous improvement, is central to Lean Software Development. Teams regularly reflect on their processes and practices, seeking ways to optimize and refine their approach.

How Lean Complements Scrum and Kanban

Lean Software Development is highly compatible with other Agile methodologies, such as Scrum and Kanban:

Scrum and Lean

Scrum's iterative and incremental development aligns with Lean's focus on delivering value early and frequently.

By incorporating Lean principles like eliminating waste and amplifying learning, Scrum teams can enhance their effectiveness and responsiveness.

Kanban and Lean

Kanban's emphasis on visualizing work, reducing WIP, and promoting continuous flow aligns seamlessly with Lean's core principles. Kanban's focus on delivering value continuously complements Lean's customer-centric approach.

Lean Software Development enriches the Agile landscape with its value-focused philosophy and waste reduction strategies. By embracing Lean principles, teams can optimize their workflows, foster a culture of continuous improvement, and deliver software products that truly meet customer needs.

Lean's compatibility with other Agile methodologies makes it a powerful complement to approaches like Scrum and Kanban. It provides a holistic and efficient way to drive innovation, reduce waste, and maximize customer value in software development.

Agile Project Management Tools and Software

Agile Project Management tools and software play a pivotal role in streamlining and enhancing the efficiency of Agile development processes. These tools provide teams with a centralized platform to plan, track, and collaborate on projects. They can make it easier to manage tasks, monitor progress, and facilitate seamless communication among team members.

In this section, we will explore some popular Agile Project Management tools and software, along with the benefits they offer to Agile teams.

Project Tracking and Collaboration Tools

Jira was developed by Atlassian, and is one of the most widely used project management tools, particularly in Agile development.

It offers a range of features, including user story and task management, sprint planning, backlog prioritization, and real-time progress tracking.

With customizable workflows and extensive reporting capabilities, Jira provides teams with a comprehensive platform to manage their Agile projects efficiently.

Trello is another offering by Atlassian. It's a visual project management tool that allows teams to organize tasks into boards, lists, and cards. It is simple to use and ideal for small to medium-sized projects.

Trello's intuitive interface and drag-and-drop functionality make it easy to track progress, assign tasks, and collaborate with team members.

Azure DevOps (formerly Visual Studio Team Services) is a comprehensive toolset that includes version control, project planning, continuous integration, and release management capabilities. Its Agile Boards provide flexible backlogs, sprint planning, and real-time task tracking, making it a popular choice for teams following Agile methodologies.

Benefits of Agile Project Management Tools

1. Improved Transparency: Agile Project Management tools provide a centralized view of project progress, tasks, and priorities. This transparency enables stakeholders to have a clear understanding of project status and facilitates open communication among team members.

2. Enhanced Collaboration: These tools promote seamless collaboration among distributed teams by providing a centralized space to share updates, files, and feedback. Features like commenting and tagging team members make it easier to communicate and address issues effectively.

3. Streamlined Workflows: Agile Project Management tools automate repetitive tasks, streamline workflows, and ensure that project tasks flow smoothly from inception to completion. This automation reduces manual overhead and allows teams to focus on delivering value.

4. Real-time Reporting: The real-time reporting and data visualization capabilities of these tools provide insights into team performance, sprint progress, and project trends. Teams can use this data to identify bottlenecks, make data-driven decisions, and continuously improve their processes.

5. Scalability: Agile Project Management tools cater to projects of varying sizes and complexities, from small startups to large enterprises. They can adapt to different team structures, making them versatile and suitable for diverse Agile implementations.

Popular Tools for Scrum, Kanban, and Other Agile Methodologies

Scrum-Specific Tools

• Targetprocess: A comprehensive tool tailored for Scrum and Agile teams with features like sprint planning, release forecasting, and progress tracking.

• Sprintly: A user-friendly tool that focuses on sprint planning, bug tracking, and team collaboration.

Kanban-Specific Tools

• LeanKit: An advanced Kanban tool with customizable boards, analytics, and workflow automation.

• Kanbanize: A feature-rich platform with analytics, time tracking, and integrations for managing Kanban projects.

All-in-One Agile Tools

• VersionOne: An end-to-end Agile management tool that supports Scrum, Kanban, and SAFe frameworks.

• Monday.com: A versatile collaboration platform that can be customized for various Agile workflows and methodologies.

Agile Project Management tools and software provide indispensable support to Agile development teams, promoting transparency, collaboration, and streamlined workflows.

From Scrum-specific tools to all-in-one Agile platforms, these tools offer a wide range of features and customization options to suit the needs of different teams and projects.

By leveraging these tools, Agile teams can enhance their productivity, drive successful project delivery, and embrace the iterative and customer-focused essence of Agile Software Development.

How to Choose the Right Agile Approach for Your Team

As Agile Software Development has become increasingly popular, various Agile methodologies have emerged, each with its unique strengths and applicability.

The key to successful Agile implementation lies in selecting the approach that best aligns with your team's goals, project requirements, and organizational culture.

In this section, we will explore essential factors to consider when choosing the right Agile approach for your team. I'll also provide insights into tailoring Agile practices to suit your organization.

Factors to Consider When Selecting an Agile Methodology

Project Scope and Complexity: Assess the size and complexity of your project.

Scrum is well-suited for projects with a defined scope and set timelines, making it ideal for product development. On the other hand, Kanban's flexibility works best for projects with constantly changing requirements or continuous flow needs.

Team Structure and Expertise: Consider the composition of your team and their experience with Agile methodologies.

Teams with diverse skills and extensive Agile experience may be more inclined to adopt Extreme Programming (XP) with its emphasis on practices like TDD and pair programming. Conversely, teams with less Agile experience might find Scrum's structured framework easier to implement.

Customer Engagement: The level of customer engagement and the need for constant customer feedback are crucial factors.

If you have direct access to customers and require frequent feedback, Scrum's focus on customer collaboration through ceremonies like Sprint Reviews is advantageous.

Development Environment: Evaluate your organization's development environment. If you work in an environment where tasks continuously arise with no fixed iteration timelines, Kanban's continuous flow model can better accommodate these dynamic workflows.

Organizational Culture: Analyze your organization's culture and willingness to embrace Agile practices.

Some Agile methodologies, like Scrum, require significant changes in project management and team dynamics, which may necessitate strong support from management and a cultural shift.

How to Tailor Agile Practices to Suit Your Organization

• Hybrid Approaches: Don't be afraid to adopt a hybrid Agile approach that combines elements from different methodologies. For example, you can use Scrum for project planning and sprint-based development while implementing Kanban's continuous flow model for support and maintenance tasks.

• Iterative Adaptations: Agile is all about continuous improvement and adaptation. Encourage your team to inspect and adapt their Agile processes regularly. This iterative approach allows you to fine-tune your practices to better suit your team's needs and project requirements.

• Training and Coaching: Provide Agile training and coaching to team members, especially if your organization is new to Agile methodologies. Proper education can help teams understand the principles and practices, fostering a smoother adoption process.

• Flexibility in Scaling: As your team grows and takes on more significant projects, consider the scalability of your chosen Agile approach. Some methodologies, like Scrum, have well-defined scaling frameworks like SAFe (Scaled Agile Framework) and LeSS (Large-Scale Scrum), which can be tailored to fit larger teams and complex projects.

Choosing the right Agile approach for your team requires a thoughtful analysis of project requirements, team dynamics, and organizational context.

By considering factors such as project scope, team expertise, customer engagement, and organizational culture, you can make an informed decision on which Agile methodology aligns best with your team's needs.

Remember that Agile is not a one-size-fits-all solution. The key to successful Agile implementation lies in adapting and tailoring Agile practices to suit your unique circumstances and goals.

Agile Scaling: Beyond the Team Level

Agile methodologies have proven to be highly effective at the team level, promoting collaboration, flexibility, and value-driven development.

But as organizations grow and undertake more extensive and complex projects, you'll need to scale Agile practices beyond individual teams.

Agile Scaling addresses the challenges of coordinating multiple teams, aligning strategic goals, and ensuring seamless communication across the organization. In this section, we will explore the concept of Agile Scaling and some popular frameworks that facilitate Agile implementation at the enterprise level.

Understanding Agile Scaling

Agile Scaling involves applying Agile principles and practices across an entire organization to ensure that multiple teams work cohesively towards common goals.

At this level, Agile emphasizes cross-team collaboration, continuous integration, and maintaining a cohesive vision throughout the organization. The objective is to extend the Agile mindset beyond the team level and achieve an Agile culture at the enterprise level.

Popular Agile Scaling Frameworks

Scaled Agile Framework (SAFe)

SAFe is one of the most widely adopted Agile Scaling frameworks. It provides a structured and scalable approach to implementing Agile across large enterprises.

SAFe introduces three primary levels of scaling: team, program, and portfolio. It offers practices, roles, and ceremonies that align teams' efforts, foster cross-team collaboration, and enable organizations to synchronize delivery on a larger scale.

Large-Scale Scrum (LeSS)

LeSS is another Agile Scaling framework that focuses on scaling Scrum principles without introducing additional complexity. It promotes a single product backlog, shared sprint goals, and cross-functional feature teams.

LeSS encourages decentralization, simplicity, and organizational alignment, making it suitable for organizations seeking a lightweight approach to scaling Agile.

Nexus Framework

Nexus is a lightweight Agile Scaling framework developed by Scrum.org. It extends Scrum by providing additional roles, events, and artifacts for scaling across multiple Scrum teams.

Nexus focuses on minimizing dependencies between teams, promoting effective communication, and ensuring a consistent definition of "done" across all teams.

Benefits of Agile Scaling

1. Improved Coordination: Agile Scaling frameworks enable multiple teams to align their efforts and synchronize their activities, reducing duplication of work and enhancing overall productivity.

2. Enhanced Visibility: Agile Scaling provides a comprehensive view of project progress and impediments at the enterprise level. This transparency allows leadership to make data-driven decisions and address organizational challenges proactively.

3. Agile Culture and Values: Scaling Agile beyond the team level reinforces the Agile values and principles throughout the organization, creating a shared mindset of customer value, collaboration, and continuous improvement.

4. Faster Time-to-Market: Agile Scaling fosters more efficient coordination between teams, resulting in quicker time-to-market for complex projects.

Challenges and Considerations

• Cultural Shift: Scaling Agile requires a cultural shift at the organizational level, which can be challenging. Leadership support, training, and consistent messaging are essential to foster an Agile mindset across the entire organization.

• Integration with Existing Processes: Agile Scaling must integrate with existing project management and development processes to ensure a smooth transition and to address any potential conflicts.

• Governance and Decision-Making: Balancing decentralized decision-making with centralized governance can be complex. Organizations need to strike a balance that empowers teams while maintaining strategic alignment.

• Communication and Collaboration: Effective communication and collaboration mechanisms must be established to keep all teams informed and synchronized.

Agile Scaling is crucial for organizations seeking to extend the benefits of Agile beyond individual teams and apply them at the enterprise level.

By adopting popular Agile Scaling frameworks like SAFe, LeSS, or Nexus, organizations can streamline coordination, enhance visibility, and promote a culture of agility across the entire organization.

Agile Scaling does come with its challenges, requiring careful planning, cultural alignment, and a willingness to adapt existing processes. With the right approach and commitment, Agile Scaling can pave the way for improved productivity, customer value, and successful delivery of complex projects at the enterprise level.

Agile and DevOps: Integration for Continuous Delivery

Agile and DevOps are two complementary practices that, when integrated, create a powerful synergy for delivering software at high speed and quality.

Agile focuses on iterative development, customer collaboration, and adaptability, while DevOps emphasizes collaboration between development and operations teams to automate and streamline the software delivery process.

In this section, we will explore the integration of Agile and DevOps, the associated benefits, and how it enables organizations to achieve continuous delivery.

Agile and DevOps: A Natural Partnership

Both Agile and DevOps share common objectives, including faster time-to-market, improved collaboration, and delivering value to customers. By combining their principles and practices, organizations can align their efforts to achieve these shared goals seamlessly.

Additionally, Agile promotes frequent feedback through its iterative development approach, while DevOps encourages continuous feedback by automating testing, monitoring, and deployment processes. Integrating these practices ensures continuous improvement based on real-time feedback.

The Journey to Continuous Delivery

Agile and DevOps collaboration breaks down traditional silos between development and operations teams. Cross-functional teams work together throughout the software development lifecycle, from design and development to testing and deployment.

DevOps automation tools enable continuous integration and deployment, allowing teams to automatically test and deploy code changes. This automated pipeline reduces manual intervention and ensures faster, more reliable releases.

And finally, Agile and DevOps promote early and continuous testing. In Agile, testing is incorporated from the start of development, while DevOps encourages "shift-left" testing to identify and address issues as early as possible in the delivery process.

Benefits of Agile and DevOps Integration

1. Faster Time-to-Market: The combination of Agile's iterative development and DevOps' automation enables organizations to deliver new features and updates to customers rapidly.

2. Higher Quality Software: With automated testing and continuous feedback, the integration of Agile and DevOps reduces the risk of defects and enhances the overall quality of software products.

3. Continuous Improvement: Agile and DevOps foster a culture of continuous improvement, where teams regularly inspect and adapt their processes to drive efficiencies and optimize the delivery pipeline.

4. Enhanced Collaboration: Agile and DevOps integration promotes collaboration and communication between development, operations, and other stakeholders, breaking down traditional barriers and fostering a sense of shared ownership.

Overcoming Challenges

1. Cultural Shift: Integrating Agile and DevOps requires a cultural shift that embraces collaboration, transparency, and a focus on delivering value. Organizations need to promote a culture of continuous learning and improvement.

2. Toolchain Integration: Seamless integration of tools used for Agile and DevOps practices is essential for efficient collaboration and automated workflows. Ensuring compatibility and data exchange between tools is vital for a successful integration.

3. Learning Curve: Teams may face a learning curve when adopting new Agile and DevOps practices. Training and support are crucial to help team members embrace the new approach effectively.

Agile and DevOps integration creates a potent combination for achieving continuous delivery of high-quality software.

By aligning their principles, practices, and goals, organizations can streamline their development and operations processes, delivering value to customers faster and more efficiently.

The cultural shift towards collaboration, the adoption of automation, and the commitment to continuous improvement are vital elements in realizing the full potential of the Agile and DevOps integration. This enables organizations to thrive in the dynamic and fast-paced world of software development.

Future Trends in Agile Software Development

Agile Software Development has continuously evolved since its inception, and it is poised to experience even more transformations in the future.

As technology advances, market demands change, and organizations seek more efficient ways to deliver software, new trends are emerging in the Agile landscape.

In this section, we will explore some of the future trends in Agile Software Development and their potential impact on the industry.

Agile at Scale

The trend of scaling Agile to address the needs of large enterprises and complex projects is expected to gain momentum. Organizations are increasingly adopting Agile Scaling frameworks like SAFe, LeSS, and Nexus to coordinate multiple teams, align strategic initiatives, and achieve seamless collaboration across the enterprise.

Agile Scaling allows organizations to extend Agile practices beyond individual teams and create a more holistic Agile culture at the organizational level. As companies grow and undertake larger projects, Agile at Scale will be a critical enabler of success.

Value Stream Management (VSM)

Value Stream Management is a trend that aims to optimize the end-to-end software development value stream, from ideation to deployment and beyond. VSM involves analyzing and visualizing the entire flow of work, identifying bottlenecks, and continuously improving the process to maximize value delivery.

By leveraging data analytics, AI-driven insights, and automation, VSM empowers organizations to make data-driven decisions and enhance the efficiency and quality of software development. This trend aligns well with Agile's focus on delivering customer value and continuous improvement.

Agile and AI/ML Integration

Artificial Intelligence (AI) and Machine Learning (ML) are rapidly transforming various industries, and their integration with Agile Software Development is becoming increasingly prevalent.

AI-powered tools can assist teams in automating tasks, predicting project risks, and providing data-driven insights for decision-making.

ML algorithms can aid in demand forecasting, resource allocation, and sprint planning. Integrating Agile with AI/ML technologies can significantly boost productivity, optimize resource utilization, and enable teams to make more informed decisions.

Agile for Non-Software Projects

While Agile was initially developed for software development, its principles and practices are increasingly being adapted for non-software projects. Industries such as marketing, HR, and finance are embracing Agile methodologies to improve project management, collaboration, and adaptability.

Agile's iterative approach and customer-centric mindset can be highly valuable in non-software domains, where requirements change frequently, and feedback from stakeholders is crucial.

Agile and Remote Work

The shift towards remote work, accelerated by global events, has prompted a reevaluation of Agile practices to accommodate distributed teams. Future trends in Agile will likely focus on enhancing collaboration and communication in remote settings.

Agile project management tools and virtual collaboration platforms will continue to evolve to facilitate seamless remote team collaboration and maintain the Agile spirit of face-to-face interactions.

The future of Agile Software Development holds exciting possibilities. Agile at Scale will be essential for large organizations seeking to coordinate multiple teams and projects efficiently. The adoption of Value Stream Management will drive continuous improvement and customer value delivery.

Integration with AI/ML technologies will revolutionize how teams plan and execute projects.

Agile's expansion into non-software domains and adaptation to remote work settings will foster Agile principles beyond traditional software development contexts.

As the industry evolves, Agile Software Development will continue to adapt and innovate. This will ensure that organizations remain agile, responsive, and capable of meeting the dynamic demands of the ever-changing digital landscape.

Conclusion

Agile Software Development has revolutionized the way software projects are managed and delivered. It empowers teams to adapt, innovate, and respond to customer needs more effectively than ever before.

In this handbook, we explored Agile methodologies, including Scrum, Kanban, Extreme Programming (XP), and Lean. We have witnessed how Agile principles and practices have reshaped the software development landscape, driving a customer-centric, collaborative, and iterative approach to project management.

While examining Agile's core concepts, we discovered how Scrum provides structure and predictability through sprints, while Kanban offers flexibility and continuous flow. Extreme Programming (XP) encourages high-quality code through test-driven development and pair programming, while Lean focuses on value delivery and waste reduction.

We also explored how these methodologies complement each other, how to choose the right approach for your team, and how Agile can scale beyond individual teams to the enterprise level.

The future of Agile Software Development promises even more exciting possibilities. As Agile at Scale gains traction, organizations will harness the power of Agile principles to coordinate and align efforts across the entire enterprise.

Value Stream Management will enable continuous improvement and data-driven decision-making, enhancing the efficiency and quality of software development. Agile's integration with AI/ML technologies will propel teams to new heights of productivity and insights.

But Agile's adaptability extends beyond the realm of software development, making its mark in various non-software domains where responsiveness and collaboration are critical. The trend of remote work further challenges Agile to evolve and embrace virtual collaboration while preserving the Agile spirit of continuous feedback and self-organizing teams.

As we embrace the future of Agile Software Development, it is essential to remember that Agile is not merely a set of practices, but a mindset and philosophy that values individuals, collaboration, and customer satisfaction.

By fostering a culture of continuous learning, innovation, and adaptability, organizations can fully harness the potential of Agile to stay ahead in an ever-changing, dynamic market.

Ultimately, Agile Software Development has transformed how we approach projects, emphasizing value, collaboration, and continuous improvement. As Agile methodologies continue to evolve and integrate with emerging technologies, the future promises even greater advancements, pushing the boundaries of what is possible in the world of software development.

By embracing Agile's guiding principles and harnessing its potential, organizations can navigate the complexities of the digital age with confidence and drive meaningful, customer-centric outcomes in an ever-evolving and competitive landscape.

Agile is a methodology for approaching software development. It consists of different frameworks such as SCRUM or Kanban that help development teams continuously build, test, and gather feedback on their product.

Agile consists of four core principles:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

I will revisit these principles later and make more sense of them. In order to do so, it’s important to take a step back and understand software development practices that were previously used.

Waterfall

Waterfall development is a very linear approach to building a product. It has little to no room for feedback or iteration until the product is completely built and tested.

Here is how it works: teams spend weeks (and sometimes months) drafting product requirement documents.

Before any code is actually written, product managers, analysts, and designers will put together one massive document that outlines the product requirements in extreme detail.

To say the least, this is a long and laborious process in which, inevitably, some things get missed.

Here is a simple thought experiment. Think about Google search or a client email finder.

Now try to try to picture the requirements document for these products.

Undoubtedly, important things will get missed. One simply can’t conceive the use-case or scale or scope of how these products will evolve over time.

If you have built a product - as a solo builder or as a member of a team - you can likely relate to this assertion.

When everything is agreed upon, the specifications get handed off to the engineering team which then builds the product to spec, leverage qualitative and quantitate data and inputs.

When everything is coded up, testing commences.

If it is a complex product, testing and bug fixing can take weeks or months since the entire product needs to go through rigorous review. When testers and product managers sign off on the test requirements, the product is ready to ship to production.

There are a number of shortcomings to waterfall development, and here are a few.

Lack of built-in feedback mechanisms

What if the development team follows the specifications exactly and it turns out that seeing it come to life just isn’t as compelling as the product team thought it was? Or worse yet, what if there was an error in the specification document?

In Waterfall development, you won’t know the answer to these questions until the product is already built.

Product development can lead to large fixed costs. If the product doesn’t work, these costs might become sunk costs.

Sunk costs are the enemy of the builder because a sunk cost is a cost that has already been incurred and cannot be recovered.

What if the roadmap changes?

This happens all the time. It happens on the computer you are using to read this article, it happens in your company, and it happens at technology firms large and small.

What if the roadmap changes and the team needs to turn their attention to something else? Under Waterfall, you are left with an unusable product. Think: rigidity.

Again, if you can’t turn your fixed costs into something flexible you will be left with a large bill and not much to show for it.

All the dedicated work, stressful deadlines, and late nights will not lead to the outcomes you wanted at the beginning of the project.

The product collects dust until it’s finally shipped

Instead of incremental enhancements being delivered to production over a period of time, the waterfall methodology waits to deliver the whole product until the very end.

While this is a reasonable approach for building a car, this is not a great approach to software.

Software, unlike cars, is flexible in the design inputs.

People can't use half produced cars. But we use half built software all the time.

Enter Agile

Agile helps solve these problems by allowing product development teams to continuously build features that add value. It also allows teams to consistently get feedback on their work and to make changes as necessary.

With the employment of Agile methods, teams consistently and predictably ship small pieces of code to production at a rapid pace.

Once they have completed any sort of feature that will add value, they test and release it to the world. This is an iterative approach to technology building.

Instead of taking months to build a final product and run an end-to-end test, Agile development enables teams to continuously build smaller pieces of the final product and add them to production over time.

This means testing goes faster since you are only testing the compatibility of the latest piece of code. This also means that users and stakeholders are happier because they get to see and utilize the latest product enhancements on a continuous basis.

Consider both approaches to a real word example of remodeling a kitchen. Let’s say it will take six months to do the remodeling job well.

Waterfall would suggest that the contractor and his or her crew rebuild the entire kitchen, then reveal the whole kitchen to the client after the six months are up.

While the job gets done in the same amount of time, the owner is left in the dark. Simple questions like how is it going go largely unanswered. Worst of all, the owners are unable to use any parts of the kitchen until the very end.

With Agile, the contractor would instead figure out what their team could get done every few weeks, and then allow their client to see it and use it while they remodeled the rest of it.

Maybe they can replace the cabinets in the first month, the countertops in the second month, and by the third month they install a new fridge and stove. Not a bad outcome for both parties!

In the second approach, the owner gets the benefit of using parts of the kitchen before everything is complete. Instead of the new stove just sitting there and collecting dust, it’s actually being utilized as soon as it's able to be used.

And maybe the kitchen owner wants to swap out one cabinet for a shelf?

The contractor can now at least plan for that change before the six months are up and let the owner know how it will affect the project timeline.

Seemingly both parties can work together and communicate transparently to ensure the right outcomes and work are done.

These are some of the many benefits of Agile. Both parties are better off.

Try to take this lesson forward as you learn new development skills on freeCodeCamp and apply your skills on projects.

Let’s consider some other examples in the software world

Revisiting the four principles of Agile, we can now start to find examples of Agile's application in the real and digital worlds.

By now I hope you can see how these principles are a direct assault on the waterfall process.

Principle #1: Individuals and interactions over processes and tools

Having a solid process and set of tools is very important in Agile. However, valuing individuals and interactions over tools enables more value creation and output.

Individual team members can innovate.

Instead of forcing people to conform to strict ideation and specifications, you can give them more bandwidth to experiment.

Part of placing individuals over tools is experimentation with new work-flows. One example that is relevant to innovation in Agile software development is codec, a computer program which encodes or decodes a digital data stream or signals.

The H266/VVC codec uses about half the data to stream 4K videos. And it is recognized as the most efficient coding solution for the future 4K and even 4K VR real-time streaming.

How was this discovery made? It was made by people using Agile to solve video compression problems.

Specifically, it was made because individuals were given freedom to build, test, experiment, and innovate over a period of time. They were not told to build the kitchen from scratch and come back in six months.

They took small steps in the right direction. This outcome is instructive.

Here is a second example: when Lastpass was acquired by LogMeIn, LogMeIn was as interested in the technology as they were the culture of design that Lastpass had implemented to build products.

What type of culture was that? One that prioritized Agile.

Agile not only brings products to market faster, but it creates creative and synergistic outcomes that are valuable.

Creating value is embedded in the culture of Agile.

Principle #2: Working software over comprehensive documentation

This one should be obvious by now. Instead of verbose specifications and planning, just write a few lines of code that work.

Test it. Get feedback on it. Ship it.

Then, do it again.

Repeat.

A highly relevant example of this repetition process is found in Forms on Fire.

They created software to make mobile data collection easy. They didn’t write their entire company before launching; they wrote a few lines of code, tested it and shipped it.

As they got momentum, they accelerated their testing and iterative steps.

And they repeated what worked and tossed what didn't. The results speak for themselves.

Principle #3: Customer collaboration over contract negotiation

Agile promotes a quick feedback loop to get customer and stakeholder feedback.

What could be better than working backwards from what real users and customers want?

I have a business mentor who advised that instead of over-analyzing what customers want through endless planning, just keep it simple. "Mitigate distractions," he said.

I have written about the KISS principle in freeCodeCamp and that advice certainly holds true in Agile: build something small and see if your customers like it.

If they do, keep going.

Principle # 4: Responding to change over following a plan

Quick feedback loops beget rapid change and adjustments. This is what makes Agile so great for development teams.

This is why you should embrace it.

Roadmaps always change, this is a known constant. Using Agile methodologies, teams can respond to change by listening to customer feedback and making necessary adjustments.

There are times when responding to change means adjusting your product or changing how you think about users or the competition.

A classic example that students of agile can look at in the e-commerce space is selling on Amazon. How do you rapidly adjust to competition? One way is to build gated communities or try different product launch strategies.

Deploying solutions that are tactical and malleable is advisable.

There is a wonderful proverb: “We can’t change the direction of the wind. We can only adjust our sails.”

When I think of Agile, I think of this saying.

Agile is about learning, Agile is about teaching. Agile is about flexibility.

You can practice Agile in your day to day work or take online courses to develop further.

Some people are smart enough to predict what their customer wants. They know which way the wind is blowing.

But for us mortals, Agile is a methodology for navigating around our deficiencies in understanding what customers want.

It is the system that lets us constantly adjust our sails.

How do you make sure that the developers on your team are aligned with your technical direction? That’s a difficult question.

Every team has its own idiosyncrasies. As a tech lead, I’ve thought a lot about it and ended up with vague ideas like empowerment or shared goals. But these are not very actionable.

However, one ritual has worked really well on the teams I’ve been part of. I want to talk about the dev huddle.

What is a dev huddle?

Developers aligning expectations

There are many names for it: Dev Huddle, Tech Huddle, Dev Meeting. Whatever you call it, it’s a recurring meeting for the developers on a team.

So what does it accomplish? Well, it's a forum to discuss technical topics and make decisions regarding architecture, conventions, or any other technology stack aspect.

"Wow, that’s so innovative!" you might think. Yes, it’s nothing groundbreaking. The devil is in the details, though.

Running an effective dev huddle can be tricky. Nothing will frustrate a group of developers more than having yet another useless meeting. If you’re taking up their time, you'd better make it count.

Why should I do it?

Before focusing on the how, let’s take a look at the why first. What do we expect to accomplish?

Create Alignment

Developers might work closely together (sometimes too literally), yet build software as if they never met before. Do they agree on the coding conventions? What’s the preferred library to parse JSON?

There are tons of small decisions to make. Over time those form a cohesive understanding of building software that is crucial for any high-performing team.

Foster Innovation

You won’t rewrite your application every six months with the trendiest technology, but you want to encourage experiments. Continuous improvements compound over time.

I’ve been part of teams that looked hopeless in the beginning. After a year of many small improvements, we’re doing continuous deployment. That will rarely happen in one big push, though.

Encourage Debate

Some teams practice what I call discussion by tenure, where the most senior people in the team make the technology decisions, and the rest, well, follow them. If they are lucky enough to find out about those decisions, that is.

Your senior folks have the experience and the instincts, but everybody else can contribute as well.

Preparation

I like to structure huddles around a backlog of ideas.

Something as simple as a sticky note on the wall or a list of issues on Github work. Each one can be just a simple headline – they are there to start a conversation.

Some examples:

• Let’s try out strikt, a new assertions library
• Refactor our API calls to use React hooks
• Missing documentation for our newest microservice

Who adds new topics? Everybody!

Find a candidate for refactoring while pairing? Read that dev.to article about that new library?

Just add it to the wall.

In the beginning, you’ll be the only one posting ideas. Over time, the rest of the team will feel more comfortable and chip in. We’ll see how to choose what to talk about in a minute.

Finding a time

Some might say, "Let’s just get together whenever needed. We are agile!"

In my experience, that doesn't work. There is always something urgent, or somebody doesn’t have time right now.

My advice? Pick a fixed slot: same day and hour, every week.

Ideally, whenever is least disruptive. After the daily, just after lunch – doesn’t really matter. People will get used to it and take it into account in their schedule.

Half an hour should be enough to have meaningful conversations.

The flow of the board is a good indicator. If you’re collecting more and more topics that you never talk about, maybe your dev huddles need to be a bit longer. If you’re running out of stuff, perhaps you can finish early, or even switch to bi-weekly huddles.

How to run a dev huddle

Running a dev huddle consists of going through the list of topics, discussing them, reaching a conclusion, and documenting it. Sounds easy, right?

Moderation happening

Not so fast. First of all, there has to be a facilitator.

A good facilitator keeps track of the total time, making sure that no single topic consumes the whole time slot. They also give everybody a chance to speak.

Without this role, you might end up having a pub discussion, just without the beer.

I used to run all the huddles in a previous team. I only realized much later what a mistake that was.

The meetings end up becoming yours when it should belong to the whole team. It’s tough to facilitate and be an active participant at the same time.

Rotate the facilitation instead. Everybody gets practice moderating, and you get to have some of the fun as well!

If you have too many topics, you have to pick which ones to tackle. You can take them in order of creation, or dot vote just before starting.

Some people will bring up more points than others. Try to keep it balanced. A big architectural change requires more than a few minutes, so maybe a follow-up meeting is in order.

And then, discussion ensues.

A huddle won’t fix a broken culture, but it’s a good litmus test. Are you stating opinions or facts? Are you fighting to get a word in? If so, a huddle is the least of your problems.

Here is a sample checklist to help less experienced moderators:

- Are there open points from last time?
- Choose the topics for today
* For every topic

    The owner presents the issue so that everybody is on the same page
    Talk about it (Keep a timebox!)
    Resolution
        What did we decide?
        Assign an owner to take care of the follow-up

- Have we made decisions that need to be reflected in ADRs?
- Finish on time, unless there is something that absolutely can't wait

The outcome

Getting the team to talk to each other is already something. If there is no outcome, though, it’s not really a meeting but a social gathering.

So write down your findings. Typically, it’ll be about things you want to do or things you’ll do from then on.

Technical Stories / Slack items

Don’t listen to the pointy-haired micromanagers who want to record every action ever taken, no matter how inconsequential. For small stuff, keep the accounting to a minimum and rely on slack time.

For bigger things, write technical stories and make sure to integrate them into your regular backlog. There is a lot that can be said about this.

TLDR: Hold a technical story to the same standards as user stories.

Keeping track of decisions

Archiving decisions

Imagine this: everyone is fired up for the huddle. It gets intense, but you reach an agreement on whether to use semicolons or not. Stuff is getting done. But no one writes it down, and you have to start all over next week.

Infuriating, isn't it?

Can I interest you in some lightweight Architecture Decision Records? It may sound formal and un-agile, but it’s really not. You just have a place where you keep track of the decisions you make.

A Markdown file with a title, what you decide, and an explanation of the context is all you need. I’ve seen people write novels to wax poetic about Kafka’s virtues when something simple will work just as well:

Title: Use Kotlin instead of Java for new services

Date: 2018/10

Decision: We'll be using Kotlin whenever we start a new service but leave the existing ones

Context: We think Kotlin will help us create more lightweight services while improving quality thanks to null safety

There are many templates that you can use. The important part is to be disciplined and reflect what you agree upon.

Get huddling!

Looking back, all the teams I’ve been on have significantly benefited from having a place for developers to align. It’s just a small investment of effort and time.

Go ahead and give it a try and find the setup that works best for you.

I thought I knew everything about Scrum theory. But the one thing I didn’t know was that the framework is sufficiently resilient that not even a pandemic can stop it in its tracks.

Let me tell you why. But first, some background.

I am a technical project manager and Scrum master on the data engineering team for Major League Baseball. On a daily basis I eat, drink, and sleep all things Agile methodology, particularly Scrum.

My team works on solving complex problems in baseball stats and analytics. We build data pipelines, databases, data analyzing tools, and visualization tools to answer every question possible about traditional baseball stats (who leads the league in home runs?) and statcast stats (what batter has the highest exit velocity against The Yankees on two strike counts?).

Needless to say, some of the engineering challenges we face are not easy. And with difficult problems to solve, there is a heavy premium placed on excellent communication – it’s one of the key things we look for in hiring talent.

It’s one thing to build an intricate application that calculates home run distance based on on the launch angle and exit velocity of the ball, it’s another to write it all down and explain it to our key stakeholders.

Insert the COVID-19 pandemic into the fold

The season gets temporarily cancelled, our roadmaps get shuffled, and we are all forced to work from home indefinitely.

As the Scrum master for the team, I am all of a sudden thinking about how this will affect our communication, throughput, and quality of work.

Previously, we were all co-located in a small San Francisco office where everyone came to work each day. It was great – imagine one big room with an open floor plan where people just write code, bounce ideas off of each other, and watch baseball games.

But now, we are all communicating over Slack and Zoom, and I’m left wondering if things are going to slip through the cracks.

What did I do? I freaked out and started adding more meetings. This would solve our communication shortage, right? Just throw more meetings on everyone’s calendars!

So that’s what I did.

1. Happy Hour

I added a daily “happy hour” that was optional to attend. The goal was to provide a social outlet where people could talk about work or non-work related items in a casual, albeit still virtual, setting.

That one lasted about a week before people stopped going – but more to come on that later. First I want to go over the rest of the failed meeting attempts.

2. Happy Hour Part Two

The second was yet another Zoom “happy hour” with a slightly larger audience that included some folks from our New York office as well. That lasted even less than a week.

3. Leadership Overhead

The third bright idea: a “leadership” call between myself and the three dev leads where we went over in-flight projects and upcoming roadmap items.

I thought our roadmap would be ever fluid during the pandemic (which it was), so why not talk about it every week?

4. Additional Stakeholder Meetings

And finally, I set up additional touch point meetings with key stakeholders to make sure we were meeting their expectations and getting their feedback on our delivered code fixes and enhancements.

I thought I was taking a proactive approach to solving a problem that no Scrum team has ever gone through: going from a co-located work environment to full remote work while maintaining full productivity levels, strong communication, and high quality of work.

Little did I know, Scrum had this all covered and I freaked out over nothing.

Here’s why.

Scrum provides a framework for how teams can go about building products through iterative cycles of constant feedback and improvement. This framework calls for a variety of different meetings (or as my manager prefers, ceremonies), that facilitate these development principles.

And through these meetings, I came to realize that all of the problems I was trying to solve for, were in fact, already solved by Scrum.

Revisiting my list of additional meetings – let’s walk through why each became obsolete

1 and 2. The Happy Hour Meetings.

It is a best practice in Scrum to hold daily standups. Each developer on the Scrum team goes over what they did yesterday, their plan for today, and if they have any blockers or issues they want to flag.

Early into the working from home life, this daily meeting became a nice touch point to say hi to colleagues and have a bit of social time together. This often took the form of baseball trivia since most of us are big fans of the game.

And while the rules of Scrum say that daily standups should be no longer than 15 minutes, I figured this was well worth going over that. You see, while many Scrum masters are very rigid and treat Scrum as a "science", I am a bit more fluid and treat it more as an "art form".

3. The Leadership Meetings

The leadership meeting was to have a consistent meeting on the books to go over small and large roadmap items. It was to convene and prioritize items based on news about when the baseball season might return.

Again, I thought I was doing my team a service by adding this additional touch point. And again, I was wrong.

It’s another best practice in Scrum to hold a backlog refinement meeting at least once per development sprint. This meeting is used to review the upcoming bugs and features in the backlog and to prioritize them for future development cycles (sprints).

My dev team and I had been consistently holding these refinement meetings before the pandemic, and sure enough, this was the perfect solution for the problem I was trying to solve – it was there all along.

I quickly realized that we were just repeating ourselves in the leadership meeting. It was pointless to have both.

4. The Stakeholder Meetings

Since we were all working remotely, I figured we should communicate more with stakeholders to make sure we were all crystal clear about what they should expect from my dev team. By now, I’m sure you’ve guessed that Scrum also accounts for this in their guidelines.

The Scrum playbook calls for a demo at the end of every sprint where the dev team gives demos to stakeholders and asks for feedback.

We have been doing this remotely now, and it has had the same effect as always – it shows what we’ve been working on and it creates a forum for quick feedback from the people who have an interest in our product enhancements.

What I Learned

Hitting the fast-forward button to today, all of those aforementioned meetings have been cancelled indefinitely and my Scrum team is continuing to deliver consistent results to our stakeholders.

My bias toward taking action with additional meetings, while well-intentioned, only added repetition and clutter. Next time I guess I’ll think twice before trying to reinvent the agile methodology wheel.

There are two important lessons I learned while transitioning to working on a fully remote team during the pandemic that I hope are now obvious to you.

Firstly, it’s that the Scrum framework is resilient and already set up to work in almost any team environment. Its built-in touch points and meeting cadences are the perfect solution that were and still are staring me in the face.

My bias was towards action. But before actioning yet another team meeting, my bias should have been towards the question "why"? This brings me to my second takeaway.

I learned that before adding an additional meeting, you should ask yourself “what is this meeting trying to accomplish? What’s the goal? Is this not already being achieved by some other meeting or other form of communication?”

Surely, this litmus test will catch a lot of repetitive meetings and save a lot of people time on their calendars. Your team will be happier and more effective as a result.

I've been working as a Scrum Master since 2010. The most common questions I hear are:

• What exactly does a Scrum Master do?
• Do you really need the role?
• Is Scrum Master a full time job?

In this article I will answer these questions.

What exactly does a Scrum Master do?

The Scrum Guide describes the roles, events, and artifacts of Scrum.
Everyone who practices Scrum should read the Scrum Guide. It's the normative reference for Scrum. It's only about 20 pages, and it's free to download.

According to the Scrum Guide, the Scrum Master is a Servant Leader. So they're a leader who supports their colleagues in their activities. But not someone who just assigns tasks or bosses other people around.

The Scrum Master supports the Product Owner, the development team, and the rest of the organization.

The Scrum Master's support for the Product Owner

The main task of the Product Owner is to maintain and rank the Product Backlog to maximize the value of the product.

The Scrum Master supports the Product Owner methodically. For example, they help with the documentation of requirements, with prioritization techniques, and in communicating with the rest of the team and organization.

Everyone in the Scrum Team should share a clear vision and understand the direction in which the product will evolve. The team should also have a common understanding of the Product Backlog. The Scrum Master helps with that.

The Scrum Master's support for the Development Team

The Scrum Master supports the development team in delivering high quality products.

For example, they make sure that the team can deliver a working, integrated and automatically tested software at least once a Sprint. So for a 2-week Sprint, that's at least every 2 weeks, or more often.

If the team can't deliver, the Scrum Master has to take action.

In the Sprint Retrospective, the Scrum Master ensures that the team discusses how to improve delivery. Not theoretically, but practically. Step by step, in each Sprint.

If the developers can't remove an impediment, the Scrum Master helps. For example if tools need to be purchased for test automation and continuous integration. Or the team needs training courses for its developers.

Also, the Scrum Master supports the team in self-organization. In Scrum there is nobody who assigns tasks to the developers. Instead, the team members perform the tasks that are their own responsibility.

The Scrum Master supports the developers in making this happen, especially if they are not used to it.

Self-organization also includes dealing with conflicts. The Scrum Master teaches the team decision-making techniques and communication techniques, like non-violent communication.

The Scrum Master also hosts the Scrum Events.

The Scrum Master's support for the organization

The work of a Scrum Master is not limited to the team. They must also teach the organization how to interact with the teams.

For example, let's say that an important stakeholder approaches developers and makes them implement a feature that hasn't been agreed on with the Product Owner. Then the Scrum Master has to talk to the stakeholder and explain the influence of their behavior on the productivity and effectiveness of the whole team.

Furthermore, a Scrum Master helps with spreading Scrum in the organization,
and makes sure that everyone understands how it works.

Scrum is not a process that is just rolled out once and everything's fine. Scrum is about continuous improvement based on continuously observing what is going on.

Is the role necessary? Is it a full-time job?

The short answer is yes. I haven't seen a team that that's able to manage all the above mentioned tasks themselves, while at the same time focusing sufficiently on development.

But my experience is limited. It's quite possible that such teams exist, especially in smaller organizations and start-ups.

My experience as a Scrum Master is that I can usually take care of at most 2 teams. And then it's a full time job. It's not something that a developer does on the side.

In many organizations, this is seen differently. But they likely don't understood that a Scrum Master is a leadership position. And that has an impact on the effectiveness of the teams.

I believe that a lot of frustration that comes from sloppy Scrum implementations could be avoided. And one factor is to have an experienced Scrum Master.

To be a good Scrum Master, it's not enough to attend a certification course that just takes several days. Those courses are fine, but they only teach the basics. The real challenges come with practice.

There's a lot of information out there on how to write user stories and why it's important. And yet, many of us make mistakes that cost us a lot.

There are many who even prefer an alternative method. (Here’s another one.) And it's often because they're frustrated by poorly written user stories.

As much as it's important to know how to write good user stories, it's equally important to know how to NOT write one.

Today, many software teams want to adopt agile processes. They want to put the user in the center of their product development process while building products. And it makes perfect sense. After all, you are building the product for your users, right?

A lot of times when writing user stories we think we are writing from the user’s perspective, but we end up skewing it with our biases and knowledge. And a lot of times, these mistakes are interlinked and only get worse with time.

In this article I will talk about some of the common mistakes teams make when writing user stories.

User stories that are too broad

When user stories are too broad, crucial information regarding the expected action and the need can get missed. If there are a lot of “ands” or “ors” or "thats" in your team’s user stories, it is good indication that it is too broad and you should consider re-writing it.

Also, there’s a very good chance that your too broadly written user story is actually an epic.

An example of a broad user story might look like this:

“As a user, I would like to continue reading the article later when I’m on my way home, without needing to sign up and find the exact spot where I left off.”

In this case you can see the user story is trying to achieve two things — not needing to sign up and not having to find where they stopped reading. Instead of trying to cram everything into a single user story, consider breaking it down into multiple user stories.

Here's how it may look after it is broken down:

"As a user, I would like to continue reading the article later without having to sign up"

"As a user, I want to continue reading from where I left off, so that I don't have to find the last paragraph I finished reading"

User stories that are too fine

When user stories are broken down into too much detail, you begin talking about how you are going to implement it. This removes the focus from the user and leads to poor communication of expectations within the team.

Here's an example of a user story that is defined too fine that it talks about implementation details.

“Define a scalable, relational database structure so that I can use it to implement any possible future use case.”

What business value does a great relational database have if the end user cannot use it? Besides, this user story is written from the business' perspective and not from the user's perspective. When you begin to include the implementation details, user stories no longer are written from the user's perspective.

User stories that aren't negotiable

User stories are not meant to be specific, precise descriptions of a feature. And therefore, they must not be fixed in stone.

Here's an example of a non-negotiable user story: "As a user, I want to have a clear all button in the notifications tab, so I can remove old notifications"

You can clearly see, the user wants to be able to remove old notifications. While having a "clear all" button is one solution, you can still automatically clear the notification after it's read too!

Here’s a classic scenario to help you identify if your user stories are too rigid:

Sometimes a user story may have been written in a particular way, and your team finds it hard to implement because there’s an easier alternative.

In cases like these, the team should be willing to compromise on the approach provided it doesn’t hurt the value a user derives.

User stories that are reiterated in acceptance criteria

Far too many times I notice the acceptance criteria repeating the user story, just in different words.

Here's how it looks:

User story: "As a user, I want to add pop-up forms to my blog, so I can capture the visitor's email id before they leave the site"

Acceptance criteria: "Given a reader visits a blog, when they try to leave, then the pop-up form should come asking them to subscribe to the blog"

Acceptance criteria should communicate the conditions that need to be met for the story to be marked as completed. This ensures that you gather feedback, help the team plan, and track their work. It makes the user story richer, more precise, and more easily testable. And more importantly, it aligns your team on what they're expected to deliver.

Here's a better example:

For the user story: "As a user, I want to receive notifications when others add comments so that I am up-to-date."

Acceptance criteria: "Given I have the app open when I am writing on the doc then the bell icon should update to show unread notifications with count"

User stories that have an undefined user

It can feel silly to mention the user persona in every user story over and over and over. However, it can add a tremendous amount of value in terms of the outcome.

This is particularly important if your product has more than one user persona. There will, of course, be features that’ll get built specific to different personas. If you want your team to be more aligned on the outcome you are expecting out of them, they need to know who the end users are and what benefit they’ll get out of the feature.

If you're looking for an example for this, nearly all examples I provided above are great ones of how not to do. Don't worry, it was intentional so I can talk about this. :)

Every time you write a user story that begins with "As a user..." or "As a visitor..." or "As a reader...", you're leaving room for ambiguity. Clearly defining who that person is will go a long way in giving your team the context they require.

At Zepel, we recommend writing the persona instead of user/visitor/reader. This means, your user story will look like this:

"As a writer, I want to receive notification when others add comments within the Google Docs app, so I don't have to refresh the page every now-and-then"

User stories with poor context

Far too many times, we end up writing user stories just for the sake of it. After a certain point, nearly every user story starts to look the same.

Here's an example: "As a content manager, I want a text editor so that I can edit text."

All this tells your team is that you want them to build a text editor and nothing else. If you’ve been writing down a bunch of user stories for a while, it’s best to take a break and revisit it with a fresh perspective.

Sometimes, even after a break, you might not be able to come up with something more meaningful. This can be a good indicator that you need to talk to your users more and understand their needs better. There’s really no point trying to squeeze it out of your brain.

Conclusion

Although using a user story template can be useful, it is never as simple as completing a fill-in-the-blanks form in your agile tool.

Because one mistake while writing user stories often leads to a series of other mistakes as a by-product. And even if you do manage to write user stories properly, it’s only the beginning. You should still enable your to team to analyze the stories — from a technical point of view — to help them estimate and create the necessary next steps.

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

Scrum and Kanban are the two most popular project management techniques today in business. As a developer, I think it's important to understand these processes as you will likely be heavily involved in them if you are part of a team. By understanding, we can stay focused on solving problems and not be too frightened of some of the buzzwords.

I'm a developer by trade but my last employed role was in product management. I tried both of these methodologies to improve productivity and efficiency in delivering products and services in the best possible way. They also assist in making organizations quick to adapt to changes in demand for their products/services.

What is Scrum?

Scrum is a project management methodology designed for cross-functional teams of less than 10 members working on complex projects. Its primary goal is to use the team member's various skills to create a solution/product for the customer/end-user.

The word Scrum is derived from the game of rugby where players of both teams interlock and try to gain possession of the ball as a functional unit.

Scrum runs on three major pillars, transparency, inspection and adaptation. This methodology is based on the premise that the customer/end-user could change their mind about what they want or there could be changes which a planned approach cannot deal with.

The project is usually started with what information is available. Afterwards, changes or tweaks can be made whenever necessary while tracking the developmental process.

The project is broken down into distinct actions called sprints that have to be completed within a fixed timeframe or iterations. The average duration for sprints is usually two weeks to a month.

Progress is tracked through daily scrums which are 15 minutes fixed stand up meetings. This encourages close interaction and communication between team members rather than the traditional sequential approach.

What is Kanban?

Kanban is a visual project management framework which was created from lean software development process and used in Agile project management. The word Kanban is a Japanese word meaning Billboard and was derived from the lean manufacturing methods pioneered by the vehicle manufacturer Toyota in Japan.

It visualizes the work process and progress through Kanban Boards. It's used for products/solutions that require continuous delivery and aims to balance demand with available capacity (Pull system) rather than push out products to the market (Push system).

The aim of using Kanban is to remove bottlenecks during the production process so that the project can flow smoothly and still be kept within budget. It's usually used in combination with other agile methodologies like Scrum.

History

The Evolution of Scrum

The Scrum methodology was first mentioned in a 1986 Harvard Business Review article 'The New New Product Development Game' by Hirotaka Takeuchi and Ikujiro Nonaka.

The authors described this process they initially called the holistic or rugby approach as a new developmental process that would increase the speed and flexibility with which commercial products were brought to the market. They saw it as "good at bringing about innovation continuously, incrementally and spirally".

1993 saw the initial use of this methodology by Jeff Sutherland along with John Scumniotales and Jeff Mckenna at Easel Corporation. Two years later Sutherland and Ken Schwaber co-presented a paper describing the Scrum methodology at the Object-Oriented Programming, Systems, Languages and Applications '95 (OOPSLA) conference in Austin, Texas.

Schwaber also wrote the first scrum text in 2001 along with Mike Beedle called Agile Software Development with Scrum. That same year saw the two authors along with Sutherland and 14 other experts on Scrum draft the Agile Manifesto in Utah which specified the principles, features and values of this methodology.

The Scrum Alliance was created in 2002 by Schwaber to provide a governing body for the Scrum methodology as well as formal certification through the CSM (Certified ScrumMaster) program. Schwaber later left the alliance in 2009 to set up Scrum.org which is in charge of the Professional Scrum Accreditation Series.

Since 2010, a document called the Scrum Guide has provided guidelines for the Scrum methodology and has been revised regularly, with the latest version released on November 2017.

Evolution of Kanban

Kanban started life as a manufacturing methodology promoted on the factory floors of Toyota by Taiichi Ohno, who is known as the father of the Toyota Production System.

Ohno was looking for a way to increase productivity and reduce inefficiencies during the car manufacturing process while avoiding making products that couldn't get sold and lost money for the company.

In a quest to get a solution, Ohno would stumble on it during a visit to a Tokyo supermarket in 1943. There, he noticed that the products on sale were only restocked when they were almost sold out according to customer demand instead of through regular supplies from the vendor. This ensured that the supermarket had very little excess inventory and ran efficiently.

Ohno would bring this technique to Toyota thought it would take 10 years for it to be fully operational. A big part of this process would be the communication system which made use of visual cards called Kanban that illustrated to the workers in each stage of the vehicle manufacturing process what needed to be done, and the materials needed, in clear terms.

It also adjusted the number of vehicles manufactured to the demand by the public instead of utilizing the full productive capacity. This process was also known as lean manufacturing or 'Just in Time' production.

This helped standardize the production process, removed inefficiencies, and made Toyota nimble and flexible by avoiding the accumulation of excess products that couldn't be sold. This was a problem American auto manufacturers were also having.

This turned Toyota into a global auto giant. After its adoption in the automotive industry, the Kanban philosophy spread all over the world and into different industries.

Kanban would become popular in service/knowledge industries due to the work of David J. Anderson. He was an admirer of the lean manufacturing process who applied a pull system of development influenced by Ohno's Kanban philosophy while working with a Microsoft XIT Sustaining Engineering group in 2004.

The next few years would see Anderson and some other colleagues shape the features and principles of the Kanban methodology. The Kanban methodology spread through management conferences and talks and more companies began to adopt it.

Anderson collated his experiences with Kanban in a book published in 2010 'Successful Evolutionary Change for your Technology Business' which is regarded as the most comprehensive definition of the Kanban methodology for Knowledge workers.

The Scrum Principles/Values

Scrum boards are “Kanban boards” too, confusing eh?

The Scrum project management methodology became part of the Agile development approaches which spread in the late 1990s and early 2000s. These were an effort to find a solution to the high failure rate in software development.

The Waterfall Development approach used primarily before this point in the software industry was rigid and inflexible – product development had to follow rigidly laid down procedures and documentation.

Scrum allowed software developers the flexibility and freedom to respond to changes in development. It also called for the involvement of the customer in the development process rather than being a bystander.

This methodology later spread to other industries. Scrum has become the most used of the agile project management methodologies – research indicates that it is in use in 66% of all projects incorporating agile development methods.

Scrum is easy to understand and follow as it avoids rigid instructions and procedures. With Scrum, organizations can do whatever is needed to get the project done, adapting to circumstances that might suddenly arise. This flexibility is one reason Eric Naiburg, marketing vice president at scrum.org, calls Scrum the opposite of a to-do list.

The breaking down of projects into sprints makes it suited for complex undertakings while the involvement of the customer in the development process enhances transparency.

The Agile Manifesto

The Agile Manifesto set out to address frustrations among software project developers in 2001 and came out with four principles. Today these principles are the bedrock of the Scrum project management philosophy and have spread beyond the software industry. They state that projects should value:

• Individuals and interactions over processes and tools.
• Working products/solutions over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Scrum Best Practices

• There are some best practices which underpin the Scrum methodology.
• We are ensuring Customer Satisfaction through early and continuous product delivery.
• Testing and incorporating product owner feedback daily.
• Welcoming and responding to changing requirements even late in the development process.
• We are working together with the customer on the development process.
• We are providing the support and environment for motivated individuals to get the work done.
• Emphasis on face to face communication within and to the team.
• We are measuring progress through a working solution/product.
• We are promoting development at a sustainable pace.
• We are enhancing agility by devotion to technical excellence and good design.
• Self-organizing teams being the best way to get the best architecture, requirements and designs.
• Having regular reflections on improving effectiveness through sprint reviews and adjusting actions to suit such.
• We are respecting the balance between the team members' professional and private lives to keep stress to a minimum.

Benefits of Scrum

The scrum methodology is the most widely used agile project management methodology for the following reasons.

Freedom of initiative — Professionals who love the freedom to take initiatives are in love with the scrum process due to its self-organizing ethos. This tends to boost team morale.

High-quality products/services — Products and services that are produced using the scrum process tend to be of a high quality due to the various iterations and improvements they have had to go through as well as customer involvement in the development.

Shorter delivery times — This is a result of the incremental development process which shortens the delivery time by 30%-40%. The involvement of the customer in the development is also a factor here.

Better return on investment — This is as a result of the shorter delivery times, better product/service quality and fewer defects as a result of continual feedback and the early testing.

Flexibility— Teams are able to react quickly to sudden changes in the market and reflect them in the product/service development.

Drawbacks of Scrum

Like everything else, the Scrum process does have its limitations. Here are some of them.

Need for expertise — Scrum requires professionals with expertise and training on the scrum methodology. This requires upfront investment by the organization.

Scope creep — The customer could request too many modifications on the product/project, which could turn out to be unnecessary.

Expensive — The need for high expertise during the scrum process as well as the constant events makes the scrum process expensive to operate

The Scrum Process

Scrum Teams

The process starts with the formation of a Scrum team to work on a pre-defined solution/project. These teams are usually self-organizing and cross-functional. According to Scrum principles, self-organizing teams are the best way to ensure optimal performance on a project as they can influence how the work will be accomplished rather than follow external directions.

Cross-functionality refers to the different competencies among the team members which enable the Scrum team to have all it requires to accomplish the project within and does away with the need for external help.

An ideal Scrum team shouldn't have more than 9 members to enhance the team spirit, closeness and effectiveness. It's also important that the team members are in the same physical location or are at least online constantly if they work remotely.

Scrum Teams deliver solutions in increments, incorporating the views of the product owner at each product's iteration. This ensures the constant availability of a functional product. There are 5 values or principles which every Scrum team should abide by in order to be effective.

• Commitment — Working towards the team goals at every sprint.
• Courage — Being able to do the right thing despite conflicts and challenges.
• Focus — Concentrating on the team goals and the sprint backlog exclusively.
• Openness — Being transparent with one another about the job and its challenges.
• Respect — Respecting each and every team member.

Scrum Roles

There are three distinct roles in any Scrum team: the product owner, the Scrum Master, and the Development team.

Product owner — This person represents the customer in the Scrum team and has the responsibility of ensuring the team delivers the project/solution/product according to the customer' s/end user's specifications. They have to communicate the end user's product requirements as well as the customer's feedback at each product's iteration. They also manage the product backlog which identifies the features of the product to be worked on.

Scrum master — This individual ensures that the team follows the Scrum principles and guidelines. They ensure that whatever is needed for the project is made available and take care of any impediments obstructing it. They also facilitate team events and ensure proper communication.

Development team — This comprises the rest of the Scrum team. They have to work together to provide a product/project using their various competencies. They organize themselves and choose their own path in getting the product delivered.

Scrum Events

Communication is vital in the Scrum framework. This is enshrined in the five events or meetings where information about the development process is exchanged regularly.

Backlog refinement — The product owner regularly reviews the product backlog which refers to the list of product features, the work to be done, and the sequence of delivery. They make sure that the backlog is properly prepared in a way that communicates to team members what needs to be done at each sprint.

Sometimes, the order of work has to be modified due to customer feedback or reviews from the development team. The review of the backlog, which is done in between the conclusion of a sprint and before the start of a new one, prioritizes features based on factors like business value, risk and date the features are needed. This review usually delivers the content for the next sprint.

Sprint planning — This is done at the beginning of a sprint to plan what needs to be worked on by the Scrum team. The smaller parts which a project is broken down into are called sprints. They could last from a week to a month.

The sprint meeting, which usually lasts an average of four hours for a 2-week sprint, has the team choosing the backlog items that can be completed during the sprint, how it will be worked on, and the goal for the sprint. These are all included in a sprint backlog.

Daily scrum/stand up — This is a quick daily stand up meeting that lasts a maximum of 15 minutes. The previous day's work is reviewed and challenges are identified by the team as well as individual members.

An individual is tasked with getting solutions to any challenges identified and any uncompleted work from the previous day is highlighted by the Scrum master on the scrum board.

Detailed discussions aren't allowed during scrum meetings. The strategy to be used for the day's work is also agreed upon.

Sprint review — This meeting which is held at the end of the sprint is used to review the performance of the team. If the work for the day is completed, the product's iteration is demonstrated and then presented to the customer/end-user along with the sprint backlog containing the 'done' items for their feedback.

The product owner can also make adjustments to the product backlog at this point.

The recommended duration for the meeting is usually a maximum of four hours.

Sprint retrospective — This is an opportunity for the Scrum team to reflect on how effective they were and what could be improved upon for better productivity the next time.

Scrum Artifacts

This refers to the commonly used tools in the scrum process. These are three of them used to record the progress of the Scrum team as well as details of the project.

Product backlog — Is a list of work that has to be done on the project by the scrum team. It contains the product requirements, features to be worked on and bugs that have to be fixed. It's overseen by the product owner and serves as a guide to the team. It's usually reviewed before it makes it into the Sprint backlog.

Sprint backlog — This list which is overseen by the development team refers to the list of product features from the product backlog that has to be worked on during the present sprint.

Team members sign up to handle tasks they can handle based on their competencies in the spirit of self-organization and commitment.

Sprint backlogs can be modified during a sprint but the end goal remains constant.

Product increments — This is the end result of the work completed during a sprint. It's usually added to the completed work from previous sprints.

This is usually according to what the Scrum Team defines and agrees as 'Done' status. Most times, this means the product is functional at an optimal level and ready to be delivered to the customer/end-user.

The Kanban Principles and Practices

The Kanban Principles

There are four core principles which form the bedrock of a successful implementation of the Kanban methodology.

Start with the present system — Kanban methodology stresses the need to avoid a culture shock by introducing a new system overnight. Instead, it can be brought into an organization and applied alongside the existing techniques.

This makes Kanban easy to implement and non-disruptive. Changes can then be implemented at a speed that everyone is okay with within a long gestation period while information about the current workflow and its inefficiencies are collected and analyzed.

Make changes incrementally — The Kanban methodology emphasizes gradual and small changes to the status quo. This will enable more buy-in from the organizational members that will be affected by the process, reduce uncertainty and unease, and in turn enable the organization to be turned around for the better as the evidence from previous incremental changes is apparent.

Respect the current workflow processes and roles — The existing work process, functions, and those in charge of them are not done away with immediately when the Kanban methodology is implemented.

The team will decide what roles should be modified, what changes should be introduced, and the right time they should be done. This is to ease the organizational transition among the members and make the incremental changes acceptable among them.

Encourage leadership at every level — Kanban recognizes that leadership qualities can emerge from anybody no matter the level they are in an organization. This is why team members are encouraged to act when there is a need for changes or to kick off initiatives instead of waiting for superior or senior management to order them.

This principle fosters trust and continuous self-improvement (Kaizen) among the team members, helping them to reach their optimal performance levels which will boost organizational productivity in the long run.

Kanban Practices

In order for Kanban implementation to be effective, there are six Kanban practices which teams have to put into action.

Visualize the workflow process — This is the first step when using the Kanban methodology. The process used to deliver the products/services by the organization as well as its flow has to be illustrated on a Kanban board which could be physical or electronic.

Each step in the workflow is represented by a column on the board. The different work items are denoted by Kanban cards of different colours. A collection of related work items can be bunched together using Kanban swim lanes.

The main aim of these is for all parties to understand the functioning of the workflow process from the customer request to the final product/service delivery as well as improve communication and collaboration. With this, different areas of the work process can be tracked and analyzed to identify possible impediments which can be worked on.

Limit the work in progress (WIP) — With Kanban, a manageable number of work items should be worked on at a time with a limit placed on the work in progress that can be handled. Work at hand should be completed before moving on to 'pull' in a new task.

Kanban discourages multitasking as it leads to wastage and inefficiencies. WIP limits in the column boards stress the importance of choosing the work the team has to do at the moment carefully as there is a limited capacity which has to be used efficiently.

Focus on the WIP also helps to reduce the cycle times (The duration from the customer request to the final delivery) for a particular product/service.

Manage the workflow — With the Kanban methodology, the various workflow stages and work progress in each of them are highlighted on the Kanban board.

Kanban emphasizes the management of the workflow process instead of the micromanagement of people with the main aim of its implementation being the smooth work process flow at optimal levels.

This enables the team to analyze the workflow process by measuring productivity/efficiency with metrics like cycle time and lead times. This makes it easier to spot any obstructions in the workflow process.

Most times, these obstructions are in the intermediate wait stages where the work has to change hands, but sometimes other factors like worker efficiency have a role to play.

Wherever they are present, adjustments are made in the work process to remove them and make the workflow better. This will enable the cycle times for the product or service to be reduced, ensuring faster turn around and the delivery of better value to the customers.

Communicate the process policies clearly — A big part of Kanban is the communication of policies and process rules on how work is conducted explicitly to all parties concerned so that there is a clear understanding of what is expected of each person. This help provides a standard against which performance can be measured and ensures quality consistency in the product/service delivered.

There have to be work process rules and guidelines for each column like who pulls what, entry and exit criteria for the column, when a task is done etc. which has to be visualized on the Kanban board. This keeps everyone with a visual reference in the organization as they work towards a common goal.

Get feedback regularly and implement it — Feedback is very important to the Kanban methodology. The review and analysis of the workflow stages on the Kanban board during daily stand up meetings are a good opportunity for this. Each of the different aspects of the workflow like delivery and operations should also be reviewed individually to track their progress.

Team members should also comment on their individual observations during the previous day. These daily meetings should be short and be straight to the point. Plans should be set in motion to work on all the feedback received. Getting all this feedback early in the process enables improvements to be made fast so as to improve cycle times and organizational productivity.

Always experiment and improve — The evolutionary change pattern of Kanban enables the use of the scientific investigation method which involves forming a theory, testing it and modifying it to be better.

The workflow process should be evaluated and improved upon continuously. New techniques can be introduced incrementally into the workflow process and observed, and then a decision should be made to keep or remove them depending on how much improvement they bring to the process through evaluating the metrics measurement.

Sometimes, these techniques just need some modification in order to perform optimally. Continuous improvement is the cornerstone of the Kanban methodology.

The Kanban Process

Kanban is a methodology that seeks to improve an organization's efficiency by applying visualization to the work process. It's based on the proven notion that the brain processes pictures more easily than words. With the visualization, areas of inefficiencies become apparent.

Kanban aims to improve the workflow process gradually and incrementally rather than quickly. This reduces the risk to the organization. It also aims to make the work process flow faster.

The Kanban Board

The Kanban board is the main tool for the visual representation of the workflow process. It enables clearer communication among all parties involved with the way information about the project/development process is highlighted through pictures.

Kanban boards can be in physical forms or in a digital/electronic form which is used for teams with remote members. The Kanban board usually comprises of three main columns:

• To do — Tasks that haven't been started are listed here.
• Doing — Tasks that are being worked on are listed here.
• Done — This consists of tasks that have been completed.

Tasks are represented by coloured sticky notes or cards. By representing the workflow process with pictures on the Kanban board, the efficiency of the workflow process can be measured especially with the aid of specialized Kanban software.

Where efficiency is lower than expected, impediments can be traced and then dealt with. This enables higher production efficiency and shorter product cycle times as well as improvements in the product/service quality.

Benefits of Kanban

Kanban is quickly being adopted by organizations in different industries globally. Some of the reasons for this include the following.

• Clear communication and transparency - The workflow visualization on the Kanban boards enables clear communication and lets everybody involved know what is expected of them. It's easy to track work progress which makes it easy to know what action is needed.
• Spot impediments quickly — The overcrowding of some of the columns can easily highlight where the work process is being slowed down, thereby necessitating adjustments.
• Flexibility — The ability to use Kanban in any system or industry and its philosophy of incremental change makes it a darling among many organizations desirous of continuous efficiency improvements. It is usually combined with agile project management techniques to make them more effective.
• Responsive to demand — Kanban enables capacity to be adjusted to match customer demands avoiding unnecessary wastage as well as the ability to respond to changes quickly.
• Focus and collaboration — Limited work in progress forces teams to focus on WIP instead of multi-tasking thereby enhancing productivity. Collaboration is also enhanced as organizational members help each other to remove challenges in discharging their tasks.

Drawbacks of Kanban

The Kanban methodology has its limitations –

• Ill suited for large projects — Kanban can be challenging to operate in a large scale situation.
• Misuse of Kanban board — The misuse or over-complication of the Kanban board can send the wrong signals about the workflow process which might result in costly mistakes.
• Wild demand fluctuations — Irregular product demands could disrupt the Kanban methodology as wrong signals could be sent as a result.
• Quality miscues— Kanban methodology drives down inventory levels to almost zero in a bid to reduce wastage. But when there's a quality issue with the final product or service, it could be difficult for the organization to react quickly as a result of the absence of an inventory buffer.

Similarities and Differences Between Scrum and Kanban

Scrum and Kanban are the most adopted productivity improvement tools globally but they are not really direct alternatives to each other like most people believe. They have some similarities but there are also differences between both of them.

Similarities

Both Scrum and Kanban are tools to improve productivity and efficiency as well as minimize wastage.

They are both based on the agile project management technique which emphasizes flexibility and ability to adapt to changes.

They also work on the 'pull' scheduling technique.

They both see improvements in product or service quality and delivery times are the cornerstone of both techniques.

They are both based on the self-organization ethos with team members taking their own initiatives and actions with every member being equal to each other and no orders coming externally.

Complex tasks are usually broken down into smaller, manageable parts.

Scrumban

In many organizations today, Scrum and Kanban are being used and combined in what is known as Scrumban. This was originally created for teams transitioning from Scrum to Kanban but has become a project management methodology in its own right. Under this methodology, the Scrum process is used but it's viewed through the lens of the Kanban improvement system.

A board similar to a Kanban board with coloured cards is used. Work is broken down into iterations. WIP limits are used here while team members choose the tasks they will work on since they are self-organizing.

On-demand planning is a feature of Scrumban. This is the application of planning techniques when new tasks are available rather than on a daily basis. Prioritization of tasks is done so that team members know what tasks are important.

Differences

There are many differences between Scrum and Kanban. This includes:

Definition — Scrum is a framework with specific rules and techniques while Kanban is a workflow visualization tool used alongside an existing system.

Training and management — Scrum requires a lot of education and training, as well as management and professionals with expertise. Kanban, on the other hand, can be easily understood by everybody which makes it cheaper to run and manage.

Change process — Kanban encourages incremental change and is suited for organizations with good, stable workflow structures while organizations that need wholesome change quickly should go for Scrum.

Usage — Kanban is usually used for smaller projects while Scrum is more beneficial for larger, more complex projects.

Roles — Scrum has three defined roles of scrum master, product owner and development teams. Kanban has no defined roles as every team member can take up available duties.

Duration — The Scrum process lasts for the duration of the project/development and is started again with a new undertaking while Kanban is a continuous effort as it is done with products/services that have to be continually delivered.

Teams — Scrum advocates cross-functional teams while specialized teams are the norm in Kanban.

New tasks/Iterations — In Scrum, new items cannot be added outside the preplanned tasks for the sprint even when the team has the capacity for such additions. In Kanban, new tasks can be worked on as long as the capacity is available.

Ownership — The sprint backlog in the Scrum process is owned by one Scrum team while the Kanban board can be shared by as many teams possible.

Productivity measurement — Kanban measures productivity using a product's/services' cycle time while Scrum measures this using velocity through the sprints.

Team goals — In Scrum, teams focus on collaborating and completing a pre-defined task while Kanban teams are focused on setting goals and reducing the cycle times.

Conclusion

This article doesn't aim to prove which is better between Scrum and Kanban as they are both productivity tools aimed at boosting efficiency. Rather it is aimed at providing an understanding of both tools so that you can make a good decision if choosing between them – or you can decide to go with both.

I personally prefer Kanban. But I think that's because a mentor of mine gave me a copy of 'Kanban: Successful Evolutionary Change for your Technology Business' which really helped me when I started needing to make my teams productive. It's definitely a book that should be in every office.

If you have any feedback or want to get in touch find me on Twitter @nialljoemaher.

References

https://en.wikipedia.org/wiki/Scrum_(software_development)

https://en.wikipedia.org/wiki/Agile_software_development

https://en.wikipedia.org/wiki/Kanban_(development)

https://en.wikipedia.org/wiki/Scrumban

https://searchsoftwarequality.techtarget.com/definition/Scrum

https://kanbanize.com/kanban-resources/getting-started/what-is-kanban/

https://kanbanzone.com/kanban-resources/what-is-kanban/

https://www.planview.com/resources/articles/what-is-kanban/

https://www.digite.com/kanban/what-is-kanban/

https://getnave.com/blog/kanban-history/

https://www.guru99.com/scrum-vs-kanban.htmlhttps://medium.com/@thorbjorn.sigberg/scrum-vs-kanban-c73dc70e8eefhttps://medium.com/ntask/kanban-vs-scrum-which-one-is-the-better-approach-to-use-in-2018-7503ee98dd0chttps://medium.com/@pavel.obod/kanban-vs-scrum-why-and-how-we-switched-from-scrum-to-kanban-8e524b6619bb

https://www.gliffy.com/blog/scrum-what-it-is-and-how-it-works

https://www.visual-paradigm.com/scrum/how-scrum-team-works/

https://skillcrush.com/2017/06/28/what-is-scrum-project-management/

https://stackify.com/what-is-scrum/

https://www.atlassian.com/agile/scrum

https://www.brighthubpm.com/methods-strategies/71133-weighing-the-disadvantages-of-the-kanban-system/

https://smallbusiness.chron.com/advantages-disadvantages-scrum-project-management-methodology-36099.html

https://www.yodiz.com/blog/kanban-vs-scrum-benefits-similarities-pros-and-cons/

https://leankit.com/learn/kanban/kanban-vs-scrum/

https://upraise.io/blog/scrum-kanban-project-management/

https://www.quora.com/How-similar-or-different-are-Scrum-and-Kanban

One of the coolest things I have learned in the last year is how to constantly deliver value into production without causing too much chaos.

In this post, I’ll explain the metrics-driven development approach and how it helped me to achieve that. By the end of the post, you’ll be able to answer the following questions:

• What are metrics and why should I use them
• What are the different types of metrics
• What tools could I use to store and display metrics
• What is a real-world example of metrics-driven development

What are metrics and why should I use them?

Metrics give you the ability to collect information on an actively running system without changing its code.

It allows you to gain valuable data on the behavior of your application while it runs so you can make data-driven decisions based on real customer feedback and usage in production.

What are the types of metrics available to me?

These are the most common metrics used today:

• Counter — Represents a monotonically increasing value.

Counters are really useful for measuring rates!

In this example, a counter metric is used to calculate the rate of events over time, by counting events per second

• Gauge — Represents a single value that can go up or down.

Gauges are really useful for measuring CPU usage!

In this example, a gauge metric is used to monitor the user CPU in percentages

• Histogram — A counting of observations (like request durations or sizes) in configurable buckets.

Histograms are really useful for measuring request duration!

In this example, a histogram metric is used to calculate the 75th and 90th percentiles of an HTTP request duration.

The bits and bytes of the types: counter, histogram, and gauge can be quite confusing. Try reading about it further here.

What tools can I use to store and display metrics?

Most monitoring systems consist of a few parts:

1. Time-series database — A database software that optimizes storing and serving time-series data. Two examples of this kind of database are Whisper and Prometheus.
2. Querying engine (with a querying language) — Two examples of common query engines are: Graphite and PromQL
3. Alerting system — The mechanism that allows you to configure alerts based on graphs created by the querying language. The system can send these alerts to Mail, Slack, PagerDuty. Two examples of common alerting systems are: Grafana and Prometheus.
4. UI — Allows you to view the graphs generated by the incoming data and configure queries and alerts. Two examples of common UI systems are: Graphite and Grafana

The setup we are using today in BigPanda Engineering is

• Telegraf — used as a StatsD server.
• Prometheus — used as our scrapping engine, Time-series database and querying engine.
• Grafana — used for Alerting, and UI

And the constraints we had in mind while choosing this stack were:

• We want scalable and elastic metrics scraping
• We want a performant query engine
• We want the ability to query our metrics using custom tags(such as service names, hosts, etc.)

A real-world example of Metrics-driven development of a Sentiment Analysis service

Let’s develop a new pipeline service that calculates sentiments based on textual inputs and does it in a Metrics Driven Development way!

Let’s say I need to develop this pipeline service:

Sentiment analysis pipeline architecture

And this is my usual development process:

Usual development process - Test, code and deploy. Oh my!

So I write the following implementation:

let senService: SentimentAnalysisService = new SentimentAnalysisService();
while (true) {
    let tweetInformation = kafkaConsumer.consume()
    let deserializedTweet: { msg: string } = deSerialize(tweetInformation)
    let sentimentResult = senService.calculateSentiment(deserializedTweet.msg)
    let serializedSentimentResult = serialize(sentimentResult)
    sentimentStore.store(sentimentResult);
    kafkaProducer.produce(serializedSentimentResult, 'sentiment_topic', 0);
}

The full gist can be found here.

And this method works perfectly fine**.

But what happens when it doesn’t?

The reality is that while working (in an agile development process) we make mistakes. That’s a fact of life.

I believe that the real challenge with making mistakes is not to avoid them, but rather to optimize how fast we detect and repair them. So, we need to gain the ability to quickly discover our mistakes.

It's time for the MDD-way.

The Metrics Driven Development (MDD) way

Behold! The Three Commandments of Production!

The MDD approach is heavily inspired by the Three Commandments of Production (which I had learned about the hard way).

The Three Commandments of Production are:

1. There are mistakes and bugs in the code you write and deploy.
2. The data flowing in production is unpredictable and unique!
3. Perfect your code from real customer feedback and usage in production.

And since we now know the Commandments, it's time to go over the 4 step plan of the Metrics-Driven development process.

The 4-step plan for a successful MDD

Metrics-driven development ?Oh wow!

Develop code 

I write the code, and whenever possible, wrap it with a feature flag that allows me to gradually open it for users.

Metrics

This consists of two parts:

Add metrics on relevant parts

In this part, I ask myself what are the success or failure metrics I can define to make sure my feature works? In this case, does my new pipeline application perform its logic correctly?

Add alerts on top of them so that I’ll be alerted when a bug occurs

In this part, I ask myself What metric could alert me if I forgot something or did not implement it correctly?

Deployment

I deploy the code and immediately monitor it to verify that it’s behaving as I have anticipated.

Iterate this process to perfection

And that's it! Now that we have learned the process, let's tackle an important task inside it.

Metrics to Report — what should we monitor?

One of the toughest questions for me, when I’m doing MDD, is: “what should I monitor”?

That’s a lovely gif. but un-realistic in most cases.

In order to answer the question, lets try to zoom out and look at the big picture.
All the possible information available to monitor can be divided into two parts:

1. Applicative information — Information that has an applicative context and meaning. An example of this will be — “How many tweets did we classify as positive in the last hour”?
2. Operational information — Information that is related to the infrastructure that surrounds our application — Cloud data, CPU and disk utilization, network usage, etc.

Now, since we cannot monitor everything, we need to choose what applicative and operational information we want to monitor.

• The operational part really depends on your ops stack and has built-in solutions for (almost) all your monitoring needs.
• The applicative part is more unique to your needs, and I'll try to explain how I think about it later in this post.

After we do that, we can ask ourselves the question: what alerts do we want to set up on top of the metrics we just defined?

The diagram (of information, metrics, alerts) can be drawn like this:

The world of information, metrics, and alerts.

Applicative metrics

I usually add applicative metrics out of two needs:

To answer questions

A question is something like, “When my service misbehaves, what information would be helpful to know about?”

Some answers to that question can be — latencies of all IO calls, processing rate, throughput, etc…

Most of these questions will be helpful while you are searching for the answer. But once you found it, chances are you will not look at it again (since you already know the answer).

These questions are usually driven by RND and are (usually) used to gather information internally.

To add Alerts

This may sound backward, but I usually add applicative metrics in order to define alerts on top of them. Meaning, we define the list of alerts and then deduce from them what are the applicative metrics to report.

These alerts are derived from the SLA of the product and are usually treated with mission-critical importance.

Common types of alerts

Alerts can be broken down into three parts:

Alerts types to Metrics list

SLA Alerts

SLA alerts in reality

SLA alerts surround the places in our system where an SLA is specified to meet explicit customer or internal requirements (i.e availability, throughput, latency, etc.). SLA breaches involve paging RND and waking people up, so try to keep the alerts in this list to a minimum.

Also, we can define Degradation Alerts in addition to SLA Alerts.
Degradation alerts are defined with lower thresholds then SLA alerts, and are therefore useful in reducing the amount of SLA breaches — by giving you a proper heads-up before they happen.

An example of an SLA alert would be, “All sentiment requests must finish in under 500ms.”

An example of a Degradation Alert will be: “All sentiment requests must finish in under 400ms”.

These are the alerts I defined:

1. Latency — I expect the 90th percentile of a single request duration not to exceed 300ms.
2. Success/Failure ratio of requests — I expect the number of failures per second, success per second, to remain under 0.01.
3. Throughput — I expect that the number of operations per second (ops) that the application handles will be > 200
4. Data Size — I expect the amount of data that we store in a single day should not exceed 2GB.

200 ops 60 bytes(Size of Sentiment Result) 86400 sec in a day = 1GB < 2GB

Baseline Breaching Alerts

These alerts usually involve measuring and defining a baseline and making sure it doesn’t (dramatically) change over time with alerts.

For example, the 99th processing latency for an event must stay relatively the same across time unless we have made dramatic changes to the logic.

These are the alerts I defined:

1. Amount of Positive or Neutral or Negative Sentiment tweets — If for whatever reason, the sum of Positive tweets has increased or decreased dramatically, I might have a bug somewhere in my application.
2. All latency \ Success ratio of requests \ Throughput \ Data size must not increase\decrease dramatically over time.

Runtime Properties Alerts

I’ve given a talk about Property-Based Tests and their insane strength. As it turns out, collecting metrics allows us to run property-based tests on our system in production!

Some properties of our system:

1. Since we consume messages from a Kafka topic, the handled offset must monotonically increase over time.
2. 1 ≥ sentiment score ≥ 0
3. A tweet should classify as either Negative \ Positive \ Neutral.
4. A tweet classification must be unique.

These alerts helped me validate that:

1. We are reading with the same group-id. Changing consumer group ids by mistake in deployment is a common mistake when using Kafka. It causes a lot of mayhem in production.
2. The sentiment score is consistently between 0 and 1.
3. Tweet category length should always be 1.

In order to define these alerts, you need to submit metrics from your application. Go here for the complete metrics list.

Using these metrics, I can create alerts that will “page” me whenever one of these properties do not hold anymore in production.

Processing latency breached configured SLA! Oh my! ?

Let’s take a look at a possible implementation of all these metrics

import SDC = require("statsd-client");
let sdc = new SDC({ host: 'localhost' });
let senService: SentimentAnalysisService; //...
while (true) {
    let tweetInformation = kafkaConsumer.consume()
    sdc.increment('incoming_requests_count')
    let deserializedTweet: { msg: string } = deSerialize(tweetInformation)
    sdc.histogram('request_size_chars', deserializedTweet.msg.length);
    let sentimentResult = senService.calculateSentiment(deserializedTweet.msg)
    if (sentimentResult !== undefined) {
        let serializedSentimentResult = serialize(sentimentResult)
        sdc.histogram('outgoing_event_size_chars', serializedSentimentResult.length);
        sentimentStore.store(sentimentResult)
        kafkaProducer.produce(serializedSentimentResult, 'sentiment_topic', 0);
    }

}

The full code can be found here

A few thoughts on the code example above:

1. There has been a staggering amount of metrics added to this codebase.
2. Metrics add complexity to the codebase, so, like all good things, add them responsibly and in moderation.
3. Choosing correct metric names is hard. Take your time selecting proper names. Here’s an excellent post about this.
4. You still need to collect these metrics and display them in a monitoring system (like Grafana), plus add alerts on top of them, but that’s a topic for a different post.

Did we reach the initial goal of identifying issues and resolving them faster?

YESSSS, it was!

We can now make sure the application latency and throughput do not degrade over time. Also, adding alerts on these metrics allows for a much faster issue discovery and resolution.

Conclusion

Metrics-driven development goes hand in hand with CI\CD, DevOps, and agile development process. If you are using any of the above keywords, then you are in the right place.

When done right, metrics make you feel more confident in your deployment in the same way that seeing passing unit-tests in your build makes you feel confident in the code you write.

Adding metrics allows you to deploy code and feel confident that your production environment is stable and that your application is behaving as expected over time. So I encourage you to try it out!

Some references

1. Here is a link to the code shown in this post, and here is the full metrics list described.
2. If you are eager to try writing some metrics and to connect them to a monitoring system, check out Prometheus, Grafana and possibly this post
3. This guy wrote a delightful post about metrics-driven development. GO read it.

When I decided to teach myself how to code almost four years ago I had never heard of, let alone thought about, the software development life cycle.

As a brand new developer I was focused on learning the technologies that would help me land that coveted first developer job, not the nuances of how those teams operated.

When I did learn of them, I thought they would be useless to me because I considered myself a web developer not a software developer.

I've since learned that this couldn't be further from the truth and these principles/practices play a large role in my day-to-day activities (whether I realize it or not).

I'm fortunate enough to see how the code I write, the features I build, and the bugs I inadvertently introduce (more than I care to admit) affect the end user and their experience. That experience has helped shape how I think about the process of building products and solving problems for my users.

I've had some time to think about the differences (and similarities) each of these approaches offer. At their core, each is focused on delivering high quality software as efficiently and as cost effectively as possible.

Professionally, I've only used one or two of these methodologies. But I still find value in at least a basic understanding of all of them.

All of these methodologies follow a series of phases similar to this diagram:

Requirement Analysis -> Design -> Implementation -> Testing -> Evolution

So, here are the software development life cycle methods (in no particular order):

• Lean
• Agile
• Waterfall
• Iterative
• Spiral
• Dev Ops

Let's dig in to the differences and similarities of each method.

Lean

The Lean methodology relies heavily on and is comprised of seven principles.

In no specific order they are:

1. Eliminate Waste
2. Amplify Learning
3. Decide As Late As Possible
4. Deliver As Fast As Possible
5. Empower The Team
6. Build Integrity
7. See/Optimize The Whole

Each principle has a specific purpose with benefits that compliment each other.

Eliminating waste (extra features, incomplete work, managerial engagements, etc) creates more value for the customer which, in turn, enhances satisfaction.

Amplifying learning allows teams to reinvest in their ability to deliver products to customers.

Deciding as late as possible refers to all major decisions, giving teams an option based or a set based approach. This allows teams to gather facts rather than opinions to help influence decisions when made.

Delivering as fast as possible is self explanatory - build the product as quickly as possible to deliver it to customers for evaluation/iteration.

In a typical scenario, the managers dole out assignments/work to the developers. In the Lean methodology developers "teach" managers how to listen to the "people in the trenches" thus influencing the decisions/choices of management.

This helps teams feel more empowered to speak up about ides and solutions.

Making integrity a rule instead of an exception means that the customer is confident in the system being built. The customer knows the system is being built to withstand the appropriate amount of growth and "stretching" if need be.

I like to think of the integrity part along the same lines as sitting in a chair. When you sit in the chair you believe it was constructed with the best material that will hold you up every time you sit in it for the life of the chair. The customer needs to that same confidence in the product being built.

Lastly, seeing and optimizing the whole refers to the entirety of the system being built. By optimizing for the whole we look at software not as a sum of many components, but as one large entity that is optimized for efficiency.

This means that during development, the product is broken into manageable pieces and that inadvertent bugs are not only discovered but resolved swiftly.

Agile

This is the "fail fast" approach to building software.

It places emphasis on small, incremental releases with on-going release cycles. With each iteration teams strive to identify and address small issues before they become big problems.

This also means that the teams must engage stakeholders (people/organizations that the code can ultimately affect such as managers, technical leads, CTOs, and customers) to get their feedback.

If you're a freelance, your stakeholder(s) would be your customers - ultimately you need to ensure their satisfaction with the work before moving on.

Agile is technically an offshoot of the Lean methodology with some notable differences - mainly it prioritizes customer satisfaction from the outset and allows teams to respond quickly to customer feedback.

Although it is beyond the purview of this article, there is another more complex framework within Agile that is called SCRUM. This methodology is used for large, extremely complex projects and has even been used outside of software development.

Waterfall

The waterfall methodology is, by most accounts, the oldest one in the list. It was never meant to be a model for software development and got its start in the construction and manufacturing worlds.

This approach is simple in its structure - finish all parts of a phase before moving on to the next phase with more momentum building towards the project finish as stages are completed. Each stage's beginning (except for the first) and completion is contingent on the previous stage's completion/transfer of information.

Under the waterfall approach each stage has its own rigid project plan that finishes off with testing for previously completed work. It should be noted that this approach is not recommended for larger/longer lasting projects because of the aforementioned rigidity.

Think about the genesis of this methodology and you'll understand it more. It came from the construction/manufacturing world where it is common to complete one phase at a time. During the building of a house you wouldn't start putting in the plumbing before the frame has been put up.

That's not the way software development works generally. As we all know it sometimes becomes necessary to revisit a phase that was previously thought to be finished.

Iterative

This is known as the "repetitive approach" or the "make it better the next go around" approach because of the different opportunities it provides to improve the product with each cycle iteration.

I'm biased (as we all are :D) but this happens to be my favorite life cycle for development. I believe it works best for my current situation both in my freelance and career path because it allows me to constantly "move forward while making things better."

With the iterative approach, teams implement a solution, test that solution, evaluate its effectiveness/throughput, and then pinpoint further areas for improvement. This happens for each cycle (iteration) of the development process.

With each version released comes another iteration until the final product is completed and ready for rollout to users.

One of the great features of the iterative approach is you and your team get a working version of software early on in the development process. This can be especially useful to show to stakeholders to gauge their response/feedback.

One of the big drawbacks to this approach is it can consume a large amount of resources very quickly. Imagine all of the people, hours, bug fixes and wages that go into each iteration of the development cycle and you'll get a good picture of the resource usage.

Within this approach is a subset of principles developed by Rational Software Corporation (bought by IBM) called the Rational Unified Process (R.U.P.) which consists of 4 phases:

• Inception
• Elaboration
• Construction
• Transition (product release)

This set of principles is meant to be flexible and tailored to the needs of each team using it.

Spiral

The spiral methodology is likely the most flexible out of the six. It's a methodology built on risks - identifying and negating them. Risk (identification & aversion) drives every decision in this model. It is broken into four sub-phases:

• Planning (objectives)
• Risk Analysis (identify possible roadblocks)
• Develop & Test (current & next version)
• Evaluation (review of current phase & plan for next phase)

Each iteration of each phase begins with planning for the next phase. This way potential risks are identified before they are encountered. This also allows for a plan of action when said risks arise.

During phases teams also work to mitigate these risks and their impact on future iterations of the spiral development.

As the development process continues, each of these four sub-phases is repeated in spiral fashion. This allows for multiple rounds of refinement for each sub-phase until completion.

Dev Ops

If you do a quick search, you will find no shortage of information on this development life cycle method. It is the new kid on the block that brings software development and information-technology operations teams into the same fold.

These teams work in conjunction to provide small, but impactful, updates to products that come at a frequent pace. In turn, this creates a continuous feedback and improvement loop that drives development.

This particular methodology is known for automating the manual parts of development as well (think deployment).

The overall goal of this methodology is, like most others, the shorten the development life cycle and provide quality products.

One of the drawbacks to this methodology is the significant mindset and culture changes within an organization. Teams that may have been accustomed to working on many things find their tasks narrowed to only one or two.

For example, a general purpose developer may find they are now being tasked with only the testing portion or the end-user experience portion.

Bringing It All Home

_Photo by [Unsplash](https://unsplash.com/@clever_visuals?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Clever Visuals on <a href="https://unsplash.com/s/photos/bright-idea?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

I hope you can now see the importance and the benefits of each of these methodologies. Each of these possess their own strengths and weaknesses.

They are, at their most basic level, a set of guidelines and principles that seek to deliver high quality, efficient work to stakeholders.

When I first started learning to code I didn't have a mentor. By sharing what I've learned I hope to help those who are learning to code when/where they can.

I want to share as much information and experience as I possibly can with other developers. If you are teaching yourself to code or if you're a seasoned developer I hope this article helps, even if in a small way.

Check out my blog where I frequently post articles about web development.

While you're there why not sign up for my newsletter? You can do that at the top right of the main blog page. I like to send out interesting articles (mine and others), resources, and tools for developers every now and then.

If you have questions about this article or just in general my DMs are open -- come say hi on Twitter or any of my other social media accounts which you can find below the newsletter sign up on the main page or on my profile here :)

Have an awesome day and happy coding, friend!

In Scrum/Agile, the functionality of a product in development is explored by way of stories a user might tell about what they want from a product. A team uses Story Points when they estimate the amount of effort required to deliver a user story.

Notable features of story points are that they:

• represent the contributions of the whole team
• do not equate directly to time the task might take
• are a rough measure for planning purposes - similar to orders of magnitude
• are assigned in a Fibonacci-like sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
• estimate the ‘size’ of stories relative to each other

The concept of story points can be quite elusive if you are new to Agile ways of doing things. You will find many online sources discussing story points in different ways, and it can be hard to get a clear idea of what they are and how they are used.

As you learn about the principles and terminology of practices like Scrum, the reasons for some of these properties will become apparent. The use of story points, especially in ‘ceremonies’ such as planning poker, is much easier to understand by observing or taking part than in a written explanation!

More Information:

• User Stories: freeCodeCamp

Parallel Development

Parallel Development stands for the development process separated into multiple branches, to provide a versatile product with stable releases and new features. In a more common straightforward software development process you have only one branch with bug fixes and improvements, alongside with new features. In parallel development multiple branches can coexist.

Usually parallel development contains a main, “master” branch which is the most stable and contains important fixes for existing code. From the main branch, more branches are created to add new “paths” to the existing code. These branches provide new features, but do not include fixes, applied in the mean time from the master branch. Clients know about these releases and have special equipment, or test machines to be able to test the new features. When QA tests are passed, side branch can be merged with the main branch to introduce new features to the release version.

Burndown Charts and Burnup Charts

Burndown and burnup charts are used to measure progress of a project— usually a development sprint under the Agile methodology. Both charts visually represent work versus time.

Burndown charts show how much work is left to be done versus the amount of time remaining. The Y axis represents work left to be done— usually relating to a time estimate assigned to each task, e.g. story points— and the X axis represents time left. Two lines are used; the first— “Ideal Work Remaining Line”— represents an ideal burndown, where each day an amount of work proportional to the total amount of time is completed, resulting in a straight line. The second “Actual Work Remaining Line” is used to plot actual progress as taks move through development to a done state. An example of a burndown chart is shown below.

Many Scrum Teams use burndown charts in order to see how they are doing during the sprint. Having an even and steady burndown might be an indicator that the stories are small and manageable. If a team notices in the middle of a sprint that the “Actual Work Remaining Line” is above the “Ideal Work Remaining Line” they can make adjustments to the scope: stories can be taken out of the sprint or the scope of stories can be made smaller. Looking at the burndown during the retrospective in the end of the sprint might spark some interesting discussions and result in process improvements.

Burnup charts are very similar, but they show the work that has been completed versus the total amount of work and time remaining. Three lines are used— an ideal line, a completed work line, and a total work line. In this chart, the total work line should be somewhat steady across the top of the chart, and is a good representation of scope change. The completed work line should move steadily up towards the total work line for the amount of time in the project— its ideal trajectory is shown by the ideal line. An example is shown below.

Image courtesy of Effective PMC

Design Patterns

A design pattern is a common design solution to a common design problem. A collection of design patterns for a related field or domain is called a pattern language. Note that there are also patterns at other levels: code, concurrency, architecture, interaction design …

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.

Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm.

The book that popularised the field is Gang of Four’s (GoF) Design Patterns: Elements of Reusable Object-Oriented Software (1994). It present a series (23) of patterns for an conventional (C++) OO language classified in three types:

• Creational (to create objects): abstract factory, builder, factory method, prototype, singleton.
• Structural (to compose objects): adapter, bridge, composite, decorator, facade, flyweight, proxy.
• Behavioral (to communicate between objects): chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method, visitor.

Patterns can be used for multiple objectives (learning, communication, improving your tooling) but in agile they should be refactored from code with technical debt and not just added at the start (emergent design/architecture) as initially you don’t have enough knowledge about the (future) system that is going to evolve. Note that what requires a pattern in a language or tool may not be needed or already be part of another language or tool. A framework is a set of cooperating classes that make up a reusable design for a specific type of software and are typically pattern-heavy.

Task Boards and Kanban

Kanban is an excellent method both for teams doing software development and individuals tracking their personal tasks.

Derived from the Japanese term for “signboard” or “billboard” to represent a signal, the key principal is to limit your work-in-progress (WIP) to a finite number of tasks at a given time. The amount that can be In Progress is determined by the team’s (or individual’s) constrained capacity. As one task is finished, that’s the signal for you to move another task forward into its place.

Your Kanban tasks are displayed on the Task Board in a series of columns that show the state of the tasks. In its simplest form, three columns are used

• To Do
• Doing
• Done

_Image courtesy of Wikipedia_

But many other columns, or states, can be added. A software team may also include Waiting to Test, Complete, or Accepted, for example.

A more complicated example.

Image courtesy of leankit

Integration Hell

Integration Hell is a slang term for when all the members of a development team goes through the process of implementing their code at random times with no way to incorporate the different pieces of code into one seamless string of code. The development team will have to spend several hours or days testing and tweaking the code to get it all to work.

In practice, the longer components are developed in isolation, the more the interfaces tend to diverge from what is expected. When the components are finally integrated at the end of the project, it would take a great deal more time than allocated, often leading to deadline pressures, and difficult integration. This painful integration work at the end of the project is the eponymous hell.

Continuous Integration, the idea that a development team should use specific tools to “continuously integrate” the parts of the code they are working on multiple times a day so that the tools can match the different “chunks” of code together to integrate much more seamlessly than before.

Code Repositories, like Git (and it’s open source interface we all know and love, GitHub) allow development teams to organize their efforts so that more time can be spent coding and less time on worrying if the different parts of the code will all integrate.

Continuous Integration is the Agile antidote to this problem. Integration is still painful, but doing it at least daily keeps interfaces from diverging too much.

User Stories

According to Mountain Goat Software, user stories are:

...part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.

User stories are typically written using the following pattern:

As a [ type of user ], I want [ some goal ] so that [ some reason or need ]

User stories should be written in non-technical terms from the perspective of the user. The story should emphasize the need of the user, and not the how. There should be no solution provided in the user story.

One common mistake that is made when writing user stories is writing from the perspective of the developer or the solution. Be sure to state the goal and the need, and the functional requirements come later.

Sizing a User Story: Epics and Smaller Stories

An is like the headline or placeholder for user stories. Epics are typically serve as big, broad strokes, and are then broken down into several user stories.

By starting with an epic, you can plan out the functionality of the product without committing to exact details. Taking this approach gives you time to learn more about your users and how to address their needs.

When thinking about possible stories, it is also important to consider “mis-user cases” and “unhappy path” stories. How will exceptions be handled by the system? What kind of messaging will you provide back to user? How would a malicious user abuse this application function? These mal-stories can save rework and become useful test cases in QA.

Planning Poker

Introduction

Planning poker is an estimation and planning technique in the Agile development model. It is used to estimate the development effort required for a user story or a feature.

Process

The planning poker is done for one user story at a time.

Each estimator holds an identical set of poker cards consisting of cards with various values. The card values are usually from the Fibonacci Sequence. The unit used for the values can be the number of days, story points, or any other kind of estimation unit agreed on by the team.

The product owner (PO) or stakeholder explains the story that is to be estimated.

The team discusses the story, asking any clarifying questions that they might have. This helps the team get a better understanding on what the PO wants.

At the end of the discussion, each person first selects a card (representing their estimate for the story) without showing it to the others. Then, they reveal their cards at the same time.

If all the cards have the same value, the value becomes the estimate for the story. If there are differences, the team discusses the reasons for the values that they have chosen. It is of high value that the team members who gave the lowest and highest estimates provide justifications for their estimates.

After this discussion, the process of picking a card in private and then revealing it at the same time is repeated. This is done until there is a consensus on the estimate.

Because planning poker is a tool to moderate a joint expert estimation, it leads to a better common understanding and perhaps even refinement of the feature request. It is of high value even when the team is operating in a No-Estimates mode.

A moderator should try to avoid confirmation bias.

Things worth mentioning:

• Estimations are not comparable between teams, as every team has its own scala.
• Estimations should include everything that needs to be done in order for a piece of work to be done: designing, coding, testing, communicating, code reviews (+ all possible risks)
• The value of using planning poker is in the resulting discussions, as they reveal different views on a possible implementation

Behavior Driven Development

Behavior Driven Development (BDD) is a software development process that emerged from Test Driven Development (TDD). Behavior Driven Development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development. It is a software development methodology in which an application is specified and designed by describing how its behavior should appear to an outside observer.

Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.

Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.

BDD focuses on:

• Where to start in the process
• What to test and what not to test
• How much to test in one go
• What to call the tests
• How to understand why a test fails

At the heart of BDD is a rethinking of the approach to the unit testing and acceptance testing that naturally arise with these issues. For example, BDD suggests that unit test names be whole sentences starting with a conditional verb (“should” in English for example) and should be written in order of business value. Acceptance tests should be written using the standard agile framework of a user story: “As a role I want feature so that benefit”. Acceptance criteria should be written in terms of scenarios and implemented as classes: Given initial context, when event occurs, then ensure some outcomes.

Example

Story: Returns go to stock

As a store owner
In order to keep track of stock
I want to add items back to stock when they're returned.

Scenario 1: Refunded items should be returned to stock
Given that a customer previously bought a black sweater from me
And I have three black sweaters in stock.
When he returns the black sweater for a refund
Then I should have four black sweaters in stock.

Scenario 2: Replaced items should be returned to stock
Given that a customer previously bought a blue garment from me
And I have two blue garments in stock
And three black garments in stock.
When he returns the blue garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock.

Along with it are some Benefits:

1. All development work can be traced back directly to business objectives.
2. Software development meets user need. Satisfied users = good business.
3. Efficient prioritization - business-critical features are delivered first.
4. All parties have a shared understanding of the project and can be involved in the communication.
5. A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.
6. Resulting software design that matches existing and supports upcoming business needs.
7. Improved quality code reducing costs of maintenance and minimizing project risk.

Scrum

Scrum is one of the methodologies under the Agile umbrella. The name is derived from a method of resuming play in the sport of rugby, in which the entire team moves together to make ground. Similarly, a scrum in Agile involves all parts of the team working on the same set of goals. In the scrum method, a prioritized list of tasks is presented to the team, and over the course of a “sprint” (usually two weeks), those tasks are completed, in order, by the team. This insures that the highest-priority tasks or deliverables are completed before time or funds run out.

Components of a Scrum

Scrum is one of the methodologies under the Agile umbrella. It originates from ‘scrummage’ which is a term used in rugby to denote players huddling together to get possession of the ball. The practice revolves around

• A set of roles (delivery team, product owner, and scrum master)
• Ceremonies (sprint planning, daily standup, sprint review, sprint retrospective, and backlog grooming)
• Artifacts (product backlog, sprint backlog, product increment, and info radiators and reports).
• The main goal is to keep the team aligned on project progress to facilitate rapid iteration.
• Many organisations have opted for Scrum, because unlike the Waterfall model, it ensures a deliverable at the end of each Sprint.

Artifacts

• Sprint: It is the time duration, mostly in weeks, for which a Team works to achieve or create a deliverable. A deliverable can defined as a piece of code of fragment of the Final Product which the team wants o achieve. Scrum advises to keep the duration of a Sprint between 2-4 weeks.
• Product Backlog: It is the list of tasks a Team is supposed to finish within the current Sprint. It is decided by the Product Owner, in agreement with the Management as well as Delivery Team.

Roles

• Product Owner(PO): The ONLY Accountable person to the Management. PO decides what goes in or out of the Product Backlog.
• Delivery Team: They are required to work in accordance with the tasks set by their PO in the product backlog and deliver the required delivarable at the end of the sprint.
• Scrum Masters: - Scrum Master’s has to strictly adhere to Scrum Guide and make the team understand the need to adhere to Scrum guide when following Scrum. It is a Scrum Master’s job to ensure all Scrum ceremonies being conducted on time and participated by all the required people as per the scrum guide. The SM has to ensure that the Daily Scrum is conducted regularly and actively participated by the team.

Daily Stand-Up and Daily Scrum

The Daily Stand-Up (DSU) or Daily Scrum meeting is one of the integral parts of scrum methodology.

As the name suggests, you hold the meeting daily, at the same time and, for a co-located team, in the same location. The meeting should be brief, finished in less than 15 minutes.

Only members of the Development team are required to attend the Daily Stand-up. Typically, the Scrum Master and Product Owners will also attend, but they are not required.

The standard agenda for each person is:

• What have you done since the last DSU
• What are you doing after this DSU
• What are the major obstacles that are stopping your progress, and where do you need help

Team members are to listen carefully to each other’s contributions and attempt to identify areas where they can assist each other’s progress. The standup meeting will also surface more lengthy topics of discussion that need to take place between different members of the team. These lengthier discussions that arise should then be halted and taken outside of the standup, involving only the relevant participants, and not the entire team.

Example of Stand-up Meeting

https://www.youtube.com/watch?v=_3VIC8u1UV8

Pirate Metrics

Dave McClure identified five high-level metric categories critical to a startup’s success: Acquisition, Activation, Retention, Revenue, Referral.

He coined the term “Pirate Metrics” from the acronym for these five metric categories (AARRR).

In their book Lean Analytics, Croll and Yoskovitz interpret these metrics visually as a funnel:

Lean Analytics, 2013

And with more pointed explanations as a table:

Lean Analytics, 2013

Nonfunctional Requirements

A non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors (a functional requirement). Non-functional requirements are often called “quality attributes”, “constraints” or “non-behavioral requirements”.

Informally, these are sometimes called the “ilities”, from attributes like stability and portability. NFRs can be divided into two main categories:

• Execution qualities, such as safety, security and usability, which are observable during operation (at run time).
• Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system

Usually you can refine a non-functional requirement into a set of functional requirements as a way of detailing and allowing (partial) testing and validation.

Examples:

• The printer should print 5 seconds after the button is pressed
• The code should be written in Java
• The UI should be easily navigable

Feature Based Planning

Feature Based Planning is a planning methodology that can be used to decide when to release software based on the features that will be delivered to the customers, rather than an arbitrary deadline based release.

In this method of release planning, teams decide what feature/features should be prioritised. Based on the scope of these features the team can then predict when the next release can be deployed.

Functional Managers

A functional manager is a person that have management authority over group of people. That authority comes from the formal position of that person in the organization (eg. director of the department, quality department manager, development team manager). Role of functional managers is different then Project Managers or ScrumMasters and is not project based.
In more agile organizations different models exists. Functional manager often are responsible for developing people in their groups, securing budgets and time for people. However there are also some Agile company models where functions usually assigned to functional managers are distributed to other roles within organization (eg. Spotify model with Tribes, Guilds, Chapters, Squads).

Out in the traditional world of work companies organize people into a hierarchy. People with similar work roles are grouped into functional areas and led by a Functional Manager. The functional manager is generally responsible for the guidance and well-being of the employees who report directly to her.

Agile project teams will often work with functional managers who control the resources the team needs to get work done. An example would be working with a functional manager in procurement to assign a person to work with the team to procure software licenses.

Build Measure Learn

The Build-Measure-Learn loop is a method used to build the right product. Coined in the “Lean Startup” book by Eric Reis, the loop enables rapid experimenting, in the sole purpose of achieving market fit. In other words, it is a powerful system to validate assumptions concerning a product you set out to deliver. Breaking down the loop, it consists of the following parts:

Idea

Each loop starts with an idea that will supply business value to some users. Such idea must be consisted of a vision for a product - which will direct you at what to build, and a metric that will point out to whether your assumptions about the business value were correct.

Build

To validate your idea, you set out to build a Minimal Viable Product (MVP), combined with predefined metrics (one is preferred), whose purpose is to validate your theory, and help you decide whether you should preserve or pivot.

Measure

This stage is focused on collecting data & metrics from the MVP.

Learn

Next, using the data collected, a decision has to be made, whether or not your product is used by users and so you should preserve, or whether users are not interested in the product, and as such you must pivot. The learn phase is therefore ending with an idea (either how to expand the product, or how to pivot from the original product), applicable for the next Build Measure Learn loop.

Sprint Planning Meeting

The Sprint Planning is facilitated by the team’s Scrum Master and consists of the Scrum Team: Development Team, Product Owner (PO) and Scrum Master (SM). It aims to plan a subset of Product Backlog items into a Sprint Backlog. The Scrum Sprint is normally started in after the Sprint Planning meeting.

Main part

It is of high value for the team to part the meeting in two parts by asking this two questions:

• What should the team plan for the upcoming Sprint?
• How should the team (roughly) takle the items planned?

What

In What phase the team starts with the top of the ordered Product Backlog. The team at least implicitly estimates the items by forecasting what they could take into Sprint Backlog. If needed they could ask / discuss items with the PO, who has to be in place for this meeting.

How

In How phase the team shortly discusses every picked Sprint Backlog item with the focus on how they will takle it. SM helps the team not to deep dive into discussion and implementation details. It is very likely and good if more questions to the PO are asked or refinements to the items, or backlog is done by the team.

Sprint Goal / Closing

The team should come up with a shared Sprint Goal for the Sprint to keep the focus in the Sprint time box. At the end of the Sprint Planning the team forecasts that they can achieve the Sprint Goal and complete most likely all Sprint Backlog items. The SM should prevent the team to overestimate by providing useful insights or statistics.

Lean Software Development

Introduction

Lean Software Development is the process of building software with the focus on using techniques which minimize extra work and wasted effort. These techniques are borrowed from the Lean manufacturing movement and applied to the context of software development.

Key Concepts

There are seven principles within the methodology which include:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

Metaphors

The act of programming is viewed as an assembly line, where every feature or bug fix is called a “change request”. This assembly line of “change requests” can then be considered as a “value stream” with the goal being to minimize the time that each “change request” is on the line prior to being delivered.

Software which is not yet delivered is considered as “inventory” since it has not yet provided value to the company or the customer. This includes any software which is partially complete. Therefore to maximize throughput it is important to deliver many small complete working pieces of software.

In order to minimize the “inventory” it is important to secede control to the “workers” who would be the software developers, as they would be best equipped to create automated processes to “mistake proof” the various parts of the assembly line.

References

The original source of written documentation on the Lean techniques is the book Lean Software Development, An Agile Toolkit by Mary and Tom Poppendieck.

Additional books by the author(s) include:

• Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck
• Leading Lean Software Development: Results Are not the Point by Mary Poppendieck

Collocation Vs Distributed

• Co-located refers to a team that sits together; same office. Ideally, everyone sitting together in adjacent offices or an open workspace.
• Distributed team members are scattered geographically; different buildings, cities, or even countries. In case of distributed team, infrastructure should facilitate processes in order to resolve time difference and distance between team members, thus providing an efficient way of working altogether.

Continuous Integration

At its most basic, continuous integration (CI) is an agile development methodology in which developers regularly merge their code directly to the main source, usually a remote master branch. In order to ensure that no breaking changes are introduced, a full test suite is run on every potential build to regression test the new code, i.e. test that the new code does not break existing, working features.

This approach requires good test coverage of the code base, meaning that a majority, if not all, of the code has tests which ensure its features are fully functional. Ideally continuous integration would be practiced together with full Test-Driven Development.

Main Steps

The following basic steps are necessary to do the most standard current approach to continuous integration.

1. Maintain a central repo and an active master branch.

There has to be a code repository for everyone to merge into and pull changes from. This can be on Github or any number of code-storage services.

1. Automate the build.

Using NPM scripts or more complex build tools like Yarn, Grunt, Webpack, or Gulp, automate the build so that a single command can build a fully functional version of the product, ready to be deployed in a production environment. Better yet, include deployment as part of the automated build!

1. Make the build run all the tests.

In order to check that nothing in the new code breaks existing functionality, the full test suite needs to be run and the build needs to fail if any tests within it fail.

1. Everyone has to merge changes to master every day.
2. Every merge into master has to be built and fully tested.

Best Practices

There are further best practices that make the best use of what CI has to offer and the challenges it presents, such as:

1. Keep the build fast, so that lots of developer time isn’t wasted waiting for a build.
2. Test the build in a full clone of the production environment.

If you have, for example, an app deployed on something like Heroku or Digital Ocean, have a separate test deployment there that you can deploy test builds to, to make sure they work not just in tests but in a real production environment. This test environment should be functionally identical to the actual production environment, in order to ensure the test is accurate.

1. Make it easy to stay up to date.

Coders should pull regularly from the master branch to keep integrating their code with the changes from their team. The repo should also be made available to stakeholders like product managers, company executives, or sometimes key clients, so that everyone is easily able to see progress.

1. Keep records of builds, so that everyone can see the results of any given build, whether it succeeded or failed, and who or what introduced new changes.
2. Automate deployment.

Keep your app fully up-to-date with any new changes by automating deployment in the production environment as the final stage of the build process, once all tests have passed and the test deployment in the production environment clone has succeeded.

CI Services

Lots of services exists to handle the process of continuous integration for you, which can make it a lot easier to establish a solid CI pipeline, or build process. When evaluating these, take into account factors like budget, build speed, and what kind of project you’re working on. Some services, like Travis CI offer free services for open-source projects, which can make them an easy choice for projects like that, but they might have slower builds than other services, like Circle CI or Codeship, to name just a few.

Acceptance Criteria

The User Story, as an item in your backlog, is a placeholder for a conversation. In this conversation, the Product Owner and the Delivery Team reach an understanding on the desired outcome.

The Acceptance Criteria tells the Delivery Team how the code should behave. Avoid writing the “How” of the User Story; keep to the “What”. If the team is following Test Driven Development (TDD), it may provide the framework for the automated tests. The Acceptance Criteria will be the beginnings of the test plan for the QA team.

Most importantly, if the story does not meet each of the Acceptance Criteria, then the Product Owner should not be accepting the story at the end of the iteration.

Acceptance criteria can be viewed as an instrument to protect the Delivery Team. When the Delivery Team commits to a fixed set of stories in the Sprint planning they commit to fixed set of acceptance criteria as well. This helps to avoid scope creep.

Consider the following situation: when accepting the user story the Product Owner suggests adding something that was not in the scope of the User story. In this case the Delivery team is in the position to reject this request (however small it might be) and ask the Product owner to create a new User story that can be taken care of in another Sprint.

Code Smells

A Code Smell in computer programming is a surface indication that there might be a problem regarding your system and the quality of your code. This problem might require refactoring to be fixed.

It is important to understand that smelly code works, but is not of good quality.

Examples

1. Duplicated code - Blocks of code that have been replicated across the code base. This may indicate that you need to generalize the code into a function and call it in two places, or it may be that the way the code works in one place is completely unrelated to the way it works in another place, despite having been copied.
2. Large classes - Classes having too many lines of code. This may indicate that the class is trying to do too many things, and needs to be broken up into smaller classes.

More info on Agile Development:

• How to make sure your development process is actually Agile
• How to fix tech debt
• Does Agile really mean what you think?