So many people have asked, so I wrote an article about dealing with bugs in production without losing your agile process for SitePoint:

In a perfect world, every time we rolled out code at the end of a sprint, it would work perfectly in production. There would never be any bugs, and there would never be any issues that forced us to roll back code that has already been deployed.

Of course, we don’t live in a perfect world. That’s one of the reasons why we have agile in the first place. Agile isn’t about pretending that your world is perfect. It’s about adapting to reality, and iterating to improve your processes and your flexibility so that when problems arise you’re able to deal with them.

One of the problems that comes up frequently for teams is the discovery of a new bug in production right in the middle of a sprint. Your team has finished deploying, all the tests passed, and everything has been pushed out to production so customers can start using it.

But maybe an edge case that wasn’t considered comes up. Maybe some aspect of the code that wasn’t fully tested comes to the surface, and starts causing problems for users. How’s your agile team supposed to respond to that?

Read the rest of “4 Agile Ways to Handle Bugs in Production” on SitePoint.

A friend of mine was asking me the other day about the choice he’s facing between going to college straight out of high school, or going right into an entrepreneurial venture. It’s a choice a lot of kids have to make these days, and it doesn’t mean the same thing it meant when I was making it some decades ago. These days there’s a very clear and respectable path directly into the work world regardless of your education (and no matter what your parents tell you).

Materialism and Waterfall

One of the most interesting parts of our conversation had to do with Epicurean Materialism. He brought up the topic (Did I mention he’s a very bright guy?) and explained it to me from his perspective, and told me his life had been directed since he was a child by the philosophy that one should focus on an objective, get on the path to that objective, and ignore distractions until that objective has been met.

As an agile practitioner, I recognized that immediately as pretty similar to waterfall, which involves setting a sequential planning into motion with a clear objective at the end and a detailed plan for how to get there. In a waterfall context, you adjust reality to meet the expectations of the plan, not the other way around.

Real Life is Messy

What he anticipated was that he could reasonably expect that so many years of school at some highly-ranked institution with such-and-such grades would lead cleanly to a particular job with a particular title in a particular organization. And because this is what he had seen his family do for generations, and what his friends were doing alongside him, he had come to believe that it would work that way.

For him the objective of getting a particular degree from a particular college was the path he had been working toward since he started high school. It wasn’t an easy path by any mans, but on the advice of advisors, family, and counselors, he was choosing to treat the challenges as distractions and press forward toward his one objective.

I think the reason he came to talk to me was because he knew I would listen to him with a perspective that wasn’t tied up in family or professional bias. Despite the clarity and all-encompassing nature of his focus, my friend told me he was starting to believe that the distractions he was facing might actually be red flags. It seemed likely to me that he was noticing the turbulence of the economy and the shifting of geopolitical power, and projecting quite reasonably that things may not remain as stable as they may have appeared for the luckiest members of earlier recent generations.

Some Agile Benefits of College

Just having the luxury of being able to choose whether or not to pursue an education is something valuable. As with everything else in life, it helps if you’re privileged with a gender, race, orientation, financial status, physical constitution, etc. that don’t put you at a significant disadvantage for what you want to do in the society where you live. When discussing how much preparation you need before you can compete and thrive in the professional world, it’s never fair to assume everything else is equal. Matters such as these always need to be considered in the context of privilege.

Being a friend, I didn’t think it was my place to encourage or discourage him about his education. But I thought it was important for him to take a step back and consider what his own objectives were before plunging headfirst into that path. In some cases, what he was looking for matched exactly what you get from a good college education. The thing that struck me was that many of these weren’t the benefits that he expected to get from college.

Like a lot of prospective college students, my friend was being sold the idea of an education as the opportunity to get a degree and use it to get a job, at the cost of several years of his youth. But in my experience as a lifelong student, a good education is not about the piece of paper they hand you at the end. That may be the prize they offer you to get you in the door, but if you approach college with an agile learning mind, you can come out with so much more.

Quick and targeted feedback

College provides a rare opportunity to get constant and critical feedback on the work you’re doing while you’re doing it, without horrendous consequences. Yes, bad grades and humiliation in front of a classroom full of your peers may seem like horrendous consequences, but they are nothing compared to losing your health insurance, seeing your family go hungry, or getting kicked out of your home.

One of the principles of agile is the importance of getting quick feedback and using it to make adjustments to your process.

I’ve heard people say that the advantage of having somebody qualified who is there just to hold your hand and tell you honestly what they think of your work is worth the cost of tuition alone. In the real world, you often have to struggle to figure out whether or not what people are telling you is based on a different agenda than the one that may be obvious. In college, the people judging you and giving you feedback usually don’t have agendas that go too far beyond the scope of the syllabus. That opportunity to get quick feedback and adapt to it since you up to grow quickly.

Networking opportunities

No matter where you go, you’re sure to meet other people who can help you, and who can benefit from your help. Helping each other is one of the most valuable ways to grow and learn. At along the way, if you become a valuable resource to other people, they will see the benefits of doing the same resource for you.

A core principle of agile is prioritizing face-to-face conversation over dry abstract documentation, and that means knowing how to interact comfortably with a wide network of real human beings.

College exposes you to a broad selection of people looking to make a change in their skills and their status. These are people who have signed on and accepted the challenge. Where they go next in life builds naturally upon the way that they approach their studies, and as a fellow student you get a front row seat to watch their progress and apply the lessons they are learning to your life.

Being a student gives you the opportunity to meet tomorrow’s professionals today, before they’ve funneled themselves into a career. As fellow students, you are peers today, regardless of where your work takes you in the future. You have a perfect excuse to meet and make friendships with other people who are also on a growth path. College is a great time to connect with the people you will be doing business with for the rest of your life.

Learning how to learn

The nature of being a student is having an open mind and learning new things. We spend our childhoods being taught traditional subjects such as math, science, languages, and social skills, but the meta-lesson is how to walk into a new subject without any experience or knowledge, and walk out with a skill.

Agile teaches us not to take our process for granted, and to revisit what we’ve learned regularly to make sure the lessons still apply as our context changes.

It takes courage, and a willingness to try something, fail, try again, notice what changed, and adjust. No matter how high we may think the stakes are when faced with the prospect of bad grades, the protected environment of college is a beautiful place to let oneself fail at something large and complex, and notice what happens.

It’s not an either/or choice

The most important point to keep in mind is that it’s your life. You can always go back and change your mind if the situation calls for it. None of us knows how long we have. Life is about adaptive capacity; the ability to make a choice, try it out for a few years, and if it doesn’t work out you try something else. Some choices do require postponing the reward you desire in order to put in the time necessary to explore an idea, get educated, and develop skills. And sometimes you decide along the way that other opportunities are more appealing, and let go of old dreams.

Time is the one resource none of us can replenish. Unless you have an urgent and pressing need that removes your choices for you, it’s always worth taking a step back before you start down a new path to consider whether the distant goal you’re working toward is worth the investment of these precious years of irreplaceable time. And for a young mind maturing in an uncertain world, it’s unreasonable to expect that the plans made for the child will still be appropriate after graduation without and adjustments.

Prototyping can be an important part of any development cycle. Project managers often rely on feedback from prototypes in order to validate concepts before writing up user stories.

If you’re developing a prototype that you plan to show the client, you probably need feedback from them about how that prototype is behaving. You certainly don’t want to create any unrealistic expectations about the state of development based on the state of the prototype.

Where the Confusion Starts

Tell me if you’ve been in this situation before: you’ve been working with the designers to mock up a prototype of the user interface for the web or mobile application you’ve been asked to build, and as soon as you present it to the clients, they start asking how close it is to being done. After all, the prototype looks great and it’s fully functional, so it can’t be that long before the product is ready, right?

In the mind of the client, it make sense. They’re not experts on development, they just want something done. The reason they hired you was because you understand all the stuff that goes on behind the user interface. As far as the client is concerned, that user interface is the actual product. How can they be expected to know that the prototype you’re presenting doesn’t have all the security features and performance optimizations necessary to make the product complete, or how much additional work that’s going to take?

There are a few things you can do to help make it clear to the customer when showing them the prototype that that’s exactly what it is; a prototype. A lot of it comes down to managing expectations effectively, rather than trying to explain the differences. You don’t want to sound as if you’re making excuses. But if you haven’t communicated how different a prototype is from the finished product, you can’t expect the customer to understand.

Five Useful Tips, Plus a Bonus Anti-Pattern

So here are five tips you might want to keep in mind when you’re about to show a prototype to a client:

1. Hold off on the visual design

One of the reasons your clients may be confused by prototypes is that they don’t understand the difference between a prototype and a finished product. All they see is the surface, and that’s going to distract them from being able to provide you with the feedback you need. The closer your prototype looks to the finished product, the more likely they are to focus on the alignment of the borders and the color of the shadows than on the fundamental behavior. To avoid that, keep the artwork as basic looking as possible. As long as the prototype doesn’t have clean and refined visual design components, there’s no way the client can confuse it with the finished product. Using rough, sketchy styles for the fonts and iconography will help you keep the focus of the prototype review on the way to protect behaves, rather than on the color of the submit button.

2. Present a paper mockup

It’s easy to forget these days how much you can get accomplished with just paper and pens. By representing your product or service using index cards or sheets of paper, indicating on each piece what actions the user can take and what happens next, you can present an interactive demonstration without any code at all. You’ll also avoid wasting any engineering time on mocking up prototype code. The important thing is to show the client what’s in development, and get their feedback in a way that lets them participate without any confusion about the state of the product itself. (Unless of course you promised them a stack of paper as the final product, in which case all bets are off.)

3. Go with a slideshow presentation

We’re all fond of our slideshows for giving presentations, but the power of these tools also lets you go pretty far toward prototyping the behavior of many basic web and mobile products. Depending on your slideshow skills and what you’re developing, you may be able to do everything the final product needs to do visually using just slides, media, and transitions. And it will be easier to communicate the idea that these are just slides and transitions, rather than actual working code.

4. Use an interactive prototyping tool

If your prototype is more complicated than something you can put together using slideshow tools, there are visual interactive prototyping tools such as InVision, Adobe Comp, or Origami. There are plenty of them out there, and most are pretty easy to learn. These tools give you access all of the interactive power of mobile devices or web browsers, and allow you to create interactive walk-throughs that are very clearly not finish products because of the flat or simple nature of their visual design. Some of these services also let you give clients remote access to play with the demonstrations directly, although it’s important not to give them access to make changes. Keep the information pipeline under your control, and don’t let random input alter the client’s expectations or your engineering team may suffer the consequences.

5. Use ridiculous colors and patterns

Most prototyping tools use simple grays blacks and whites, avoiding any color at all, to make their output look different from a finished product. However there are clients who like that look. What’s considered ridiculous will vary from one client to another. Figure out what aesthetic your client prefers, and use colors that violate those standards. For web component prototyping, I’ve been known to create a CSS class named “.fpo” (a reference to “for-placement-only” graphics used in print publication). I add this class to any element on a prototype webpage that is clearly not complete, so the client won’t have any confusion. For example, once I created a .fpo class that added garish pink and purple diagonal stripes to any element that was on the page just for placement purposes. The client’s website aesthetic used a lot of soft shadows, pastel colors, and muted grays. There was no confusion.

Bonus anti-pattern: Don’t use silly, embarrassing, or copyrighted imagery and text

While I do recommend using inappropriate colors that stand out, I don’t recommend going much further than that. It can be dangerous to include prototype text and graphics that may be amusing to your developers, but may get the client into trouble if they’re missed in the handoff and end up somehow appearing in the final products. You don’t want Beyoncé’s lawyers calling you up because you forgot to remove her likeness from one of the screens of your app. It’s amazing how easy it is for temporary elements in the prototype to become part of the production release. Consider yourself warned.

The Struggle Never Ends

No matter how careful you’ve been to set reasonable and realistic expectations during initial negotiations, the client is always going to try to push for faster delivery. After all, they can’t start making the money that they need to pay you until they have the products that you’re building for them.

Keep control of the situation by holding off on the visual design. Use paper mockups when you can, or use slideshows or prototyping tools when you need something more sophisticated. Don’t forget to distinguish the prototype with colors and patterns that will stand out from the client’s visual design aesthetic. But be careful not to use elements that could get the client into trouble if they ended up in the final product because somebody missed them.

Be realistic and reasonable, and never let them think that the prototype that they’re evaluating is anything more than a feedback mechanism.

I just found out yesterday that my publisher has made my new book, Scrum, Novice to Ninja, available for preorder. It should be shipping in February.

Very excited!

When dealing with a client, you may find yourself trying to reconcile the bugs a client wants you to fix against the fact that agile doesn’t assign points to bugs. How can your team do the work of fixing bugs for the client when those bugs seem to have no impact on velocity? It’s real work, and the team has to do it, so how should it be tracked?

A Bug Is Not Always A Bug

The issue here is not really about tracking work on bugs. The problem is that it’s impossible to reconcile the client’s desire for bug fixes against the team’s agile agreement to complete a specified slice of functionality each sprint.

Agile doesn’t care about the contract with the client.

Product Owners and Client Requirements

One of the reasons an agile scrum team always has a designated Product Owner is to insulate the team from the issues that come up when dealing with the client. It’s irrelevant to the agile process how the contract was written, or what the client calls a bug. Agile is about determining what the team can sustainably deliver, breaking requirements down into deliverable slices of functionality, and helping the team get better at estimating those stories.

The client doesn’t get to decide what is a bug; only what is acceptable. Under no circumstances should the customer have any part in defining “done” for the team. And under no circumstances should the agile process have an opinion about what the client is paying for or what is acceptable.

The Product Owner represents the interest of the client, and works with the team to create stories that add up to the number of points the team is historically capable of delivering during a sprint according to the team’s velocity. Whether a story is treated as a bug, and not assigned points, should only be based on the state of the product at the beginning of a sprint, not on the client’s arbitrary definition.

Why Some “Bug” Stories Get Points

If a story involves taking the state of the product at the beginning of a sprint and changing it in a way that is visible to the end user, that story is feature development and gets estimated with points.

On the other hand, if a story is delivered during a sprint but not accepted as done because it does not meet the acceptance criteria, fixing the code so the story can be accepted is bug work. No points should be counted for bug fixes, regardless of whether the work is done in this sprint or the next.

Bugs in agile reduce velocity because the team was unable to deliver working functionality, not because the client calls the product’s behavior buggy.

Agile is Opinionated About Bugs, Not Contracts

Agile can help the team realize what they are capable of in a sustainable manner. It’s up to the people who write the contracts whether it makes more sense to go with a fixed price for a fixed scope, or structure the deal around some sort of warranty. The team can only deliver what it can deliver, regardless of the contract.

If you’ve found yourself wrestling with this issue, check again and make sure whether you’re talking about agile bugs or what a user might consider buggy behavior in a product. They’re different beasts, and they need to be treated differently. I’d be interested to hear your experiences with bug definitions, and how you communicated them to your team.

Have you ever gotten to the end of a sprint only to watch your poor frustrated QA engineers struggle to make tests pass in time for a demo? Meanwhile, have your team’s developers moved on to the next story, without knowing whether the last story had passed its inspection?

Is it possible to keep your developers productive once they’re finished with the development work for a story, and avoid stressing out your QA engineers at the same time?

Done Means Tested

The definition of done must include testing if your company is at all concerned about quality, so the story produces a slice of complete functionality for the product at the end of the sprint. And the team must committed to delivering what they agreed to deliver, even if it means working outside of their discipline.

Ideally, a team won’t be limited by job titles and roles, and will be willing to work together on both development and testing to complete stories. If the developers are getting so far ahead of QA that they are working on the next story before the current story is done, then they are missing the point of working together as part of a scrum team.

Isolation is a Luxury

Keeping QA isolated comes at too high a cost. The fact that all members of a team may not be coloated shouldn’t prevent the team from working together as a unit. There are so many excellent remote collaboration tools such as Screenhero or Google Hangouts, or even BitBucket and Github for asynchronous coordination. that there’s no excuse anymore to let geography prevent teams from working together across disciplines.

It is to the benefit of the developers to work closely with QA to establish the standards by which the development work will be evaluated. And it is a growth opportunity for QA to work closely with the developers, both to learn the skills of development, and to make sure the requirements QA will be testing for are considered.

Done is Everyone’s Responsibility

A team that does speculative development on new stories before previous stories are tested is not getting more done; they are just building up a backlog of untested code that cannot be shipped. It is not to anyone’s advantage to work on a new story until the previous story is actually finished.

Do not allow the developers to get ahead of QA with untested code. A story isn’t done until it is done. It is everyone’s responsibility to make sure every story meets the definition of done before moving forward.

If you’ve been looking for jobs as a scrum master, you’re probably frustrated by the lack of enthusiasm in the hiring community. It isn’t as if there weren’t a real need for scrum masters out there. You know how effective agile can be, and you know that companies could really benefit from the skills you have to offer. But finding a job description and an open headcount seems like an uphill battle.

You’re not alone, and the problem isn’t you. Getting a job as a scrum master is not impossible, but it’s also not always a direct path. There are a few tricks to keep in mind, and knowing them will take you further than hours of scrubbing through job boards or making friends with recruiters and HR managers.

Here are some important points about the way companies get competent scrum masters, and how you can secure a position that will benefit you and your next employer.

Many Scrum Masters Are Grown, Not Hired

The position of scrum master is often one that gets filled by members of an existing team as they transition from a less agile process. Scrum doesn’t magically appear in an organization. It usually is birthed from the pain and suffering of a team that realizes it can’t get anything done without a significant shift in their process. That realization may come in the form of a natural servant-leader who heads the charge toward agile, and slides gracefully into the role of scrum master.

If you are looking to work for companies that are just transitioning to agile, you may have a tough time finding open listings for jobs as a scrum master. For many of these companies, the role of scrum master will be filled from within the ranks, and may have to prove its value before it gets funded to the point of hiring trained outside professionals.

The Job Title May Not Match the Role

Jobs are usually brought into existence by the managers who see a need on their teams, and who can justify the expense of hiring someone new. However, the actual job descriptions and titles are often dictated by Human Resources, where titles such as “Scrum Master” may not have an official designation that can be added to the database.

You may need to look for jobs with titles that sound more like traditional project management (or even product management). But scan the descriptions for hints that the company is actually looking for someone familiar with agile and scrum. Don’t let the fact that the title doesn’t match your idea of what you want to do stop you from applying. Once you talk with the company, you will get a sense of whether you are a good match for what they need.

You May Need to Introduce an Agile Process

Is there a particular company you want to work for, but you know that they are not currently following and agile process? Or are you currently working at a company where scrum could make a difference? Don’t let the status quo stop you if you have good reason to believe that the company you want to work for would be open to a change.

The question to ask yourself is whether you truly believe that shifting that company’s approach to be more agile is possible given what they are doing, and in the best interests of the team and the organization as a whole. If your research gives you the confidence to say that with convition, don’t hesitate to schedule an informational interview with a potential hiring manager, regardless of whether they currently have an open job listing for a scrum master.

Approaching a company that isn’t currently using scrum can be a bit of a gamble. Proposing a major change at a company you are already working for can also be challenging. But showing up to an informational interview with a full portfolio of tested processes and procedures, and offering your expertise, might just open doors for you.

Scrum Master May Not Be a Full Time Role

Once a company has a working agile process in place, the team and the organization can often support scrum with a single scrum master for multiple teams, or with a part-time scrum master who also holds other part-time roles. The good news can be that companies like this have already committed to scrum and the team is already well trained.

It’s fine to take on responsibility for more than one scrum team, as long as you have the opportunity to talk with the teams and see that their processes aren’t broken. If you interview for a role that is only part-time scrum master, and you get a sense that the company is just trying to cut corners with a low committment to scrum, you might want to keep looking.

Interview Companies While They’re Interviewing You

If you keep these issues in mind, your job search may be much more flexible. You must remember that you are interviewing your future employer just as much as they are interviewing you. Make sure you are in a place where scrum can survive and flourish. Without that, you might just be working against your own best interests and those of the people around you by trying to support an agile process.

I want to hear how your job search is going, and what obstacles and opportunities you’re finding at the companies you explore. The job market is constantly shifting. It’s invaluable to stay informed, and let your network know what you’re finding.

Stay in touch! Sign up below for the Agile That Works mailing list to be connected to the community and get the latest lessons as soon as they are released.

One of the most familiar and regular rituals in an agile process is the daily standup. This is the opportunity for everyone on the team to say what they’ve been working on, what they plan to work on next, and what problems they may be having.

Sometimes the question comes up about who should be invited to attend standups. Some teams feel uncomfortable when people unfamiliar with their process attend. For example, I recently came across this comment from a concerned scrum team member discussing his team’s feelings about visitors at standup:

“When someone from outside the team wanted to join in, especially any Manager/Sr. Manager, the team wasn’t really happy.”

One thing that impressed me about the comment was that it was about how the team feels, rather than trying to determine the “right” or “wrong” way to manage standups. This is always the bottom line when it comes to a question like this. And the place to get those concerns voiced is, of course, during a retrospective.

Most of the teams I’ve been scrum master for have appreciated any outside interest in what they were doing. It’s validating, it exposes the team to the broader organization, and it supports their career development within the company. As long as the observers are polite guests and don’t try to interfere, it usually adds a lot of value. (And as scrum master, it’s important not to be shy about enforcing the rules of the standup in a gentle but firm way.)

I’ve even gone so far as to campaign for people from all parts of the organization to come and observe our Scrum process in action. Afterward, I often solicit feedback from attendees. It’s a great way to find out what they noticed from an outsider’s perspective, and gather learnings for future improvements.

The standup is for team members, but by tradition a standup meeting is intended to be open to anyone who wants to attend. Only team members should participate, with everyone else observing and holding any comments or questions until the entire team has had a chance. This is part of the transparency of scrum, and if it makes anyone feel uncomfortable, that is a signal to look for other deeper issues.

I’m curious how you approach this issue in your own scrum teams. Let me know. And if you want to read more about issues like this, feel free to sign up below and get new lessons and insights about agile that works for free as soon as they’re released.

What reports should you provide to executives after each sprint?

Transparency is one of the key advantages of using an agile process, but what do you do about transparency for people who aren’t part of the team? What happens when the executives drop by, look at the burndown chart or the scrum board on the wall, and start asking team members questions? What information can you provide people outside the team to let them know what the team is working on without disrupting the team, without inviting micromanagement, and without interrupting your sprint?

Executive Interest is Good

First of all, congratulations on having people outside the team interested in with the team is doing. That’s a big win for any technical organization. Now that you have their attention, one of the great things about agile is that it provides you with a number of artifacts that can be used to explain exactly what the team is working on to anybody, regardless of their background.

Here’s a quick and easy cheat sheet of artifact you can assemble after each sprint, and explanations you could give to people outside the team, to help them understand what you’re working on. (And the best part is, if you’re following your scrum procedures consistently, you should already have everything on hand ready to go.)

Executive Report Cheat Sheet

At minimum, providing these three key pieces of information at the end of every sprint will go a long way toward helping everyone outside the team understand what the team is working on:

1. Working Software

If your team is building complete slices with working software at the end of each sprint, showing the executives exactly what the state of the product is at the end of the sprint is one of the best ways of demonstrating what you’re working on. Even if your company doesn’t release the product after each sprint, working software with new customer-facing features is tangible evidence of what you’ve been producing.

2. Burndown Chart

A properly updated burndown chart shows the progress of all the stories in the last sprint. One of the advantages of the burndown chart is that it goes from top left to bottom right, unlike many business charts that are expected to go from the bottom left to the top right. Once you’ve explained to non-team members how to interpret the chart, it will provide them with a quick overview of the effort the team put in, and what was accomplished.

3. Retrospective Highlights

The detailed notes from a Sprint respective are usually for the team members only, but issues can come up at the sprint retrospective that are worth sharing outside the team. At the end of the sprint, go over your retrospective notes, and collect interesting data points that are worth sharing with the executives. For example, you might want to make a list of the blockers that came up this Sprint, Along with some of the biggest wins, and the greatest learnings from the sprint.

Bonus: Ask What They’re Looking For

The most important thing is to find out what people outside the team are looking for. You may not want to present the exact same information to everybody, but you want to make sure that everybody who relies on the team understands what’s relevant to their area, so they can provide the support the team needs going forward.

Make it a regular practice to compile this information, and provide it directly to the executives and other key players around the company who are most important to the functioning of your team. if you do this on a regular basis, everybody will know what your team is really doing, and they won’t need to interrupt the flow of the working developers in order to find out.

Again, congratulations on having people outside the team interested in what your team is doing! If you found this technique useful in your work, please let me know about your success, and sign up below to be the first to learn the latest agile techniques I publish.

I was asked to write about “Should Our Agile Team Use Scrum or Kanban?” for SitePoint. Here’s an excerpt:

There can be a strong impulse toward choosing the approach that offers the fewest differences from what hasn’t really been working so far.

For some companies, “getting agile” means sprinkling a few new titles and terms around without really changing how the work gets done, and calling it agile. It’s worth giving your team a chance to follow a legitimate agile workflow first, all the while paying attention to what works and for whom.

Two of the most popular approaches to agile workflow are Scrum and Kanban. Since they are both agile, there are many similarities between the processes and tools you use when implementing either. But Scrum and Kanban provide a different set of advantages that are optimized for different applications.

Read the rest of my article about Should Our Agile Team Use Scrum or Kanban? on SitePoint.