I lead from the heart, not from the brain.

Which according to a Fastcompany article, which includes some great research conducted by the Institute of HeartMath, is exactly where leadership needs to be headed.

We now know that the heart and the brain are in a constant two-way communication and that the heart sends more information to the brain than vice versa. The signals the heart sends affect the brain centers involved in our decision-making and in our ability to perceive. In other words, each beat reflects our current emotional state. If we’re angry, irritated or frustrated, the heart beats out a very chaotic message. Conversely, more positive emotions create harmony in our nervous system and the heart rhythm pattern we have when we’re in our most optimal state.

Fascinating and yet there is so much logic in this it’s a wonder we haven’t thought about this before.

Coincidentally, a Towers Watson study recently showed that the greatest driver of employee engagement worldwide is whether or not people feel their managers and organizations have genuine concern for their well-being. Heartmath’s corresponding insight: More caring leaders set off the neural machinery that produces optimal workplace performance.

Leading from the heart is a huge pivot in the world of leadership and managing. Yes there has been a slow movement to be more engaging with employee’s and teams but that engagement has historically stopped at the doorstep of the office. It is rare for a leader to become concerned and invested at even a basic level in his or her employees personal life or even just their interests outside of the office.

Now based on this article I’m not advocating that you sit down with your employee’s and ask them how their marriage is, or there relationship with their mother or father. There should be boundaries in place but if you notice an employee who consistently bikes to work, or talks about a favorite sports team, then by all means engage them.

Some of you are probably already discounting your ability to engage or to be relational. Well, even if you find that you are more insulated this doesn’t mean you aren’t relational, it just means that you tend to listen more before acting on those relationship aspects. Which in some cases can be more effective then charging in with hugs, atta-boys, and other “feel-good” methods.

It’s long been believed that a job and a paycheck was sufficient motivation for workers to perform. But pay in all of its manifestations now ranks no higher than fifth in importance globally as the reason why people excel in their jobs.

While the idea of managing people with greater care may strike some as intrinsically wimpy, the Conference Board’s ongoing employee engagement research has proved that workplace leadership cannot succeed without it.

What matters most to people is how they are made to feel by the organizations that employ them, and by the bosses who manage them. So, demonstrate to your employees that they’re authentically valued. Provide them with opportunities to grow and to contribute at a higher level. Appreciate their work. Make people feel they matter. Do all these things and more–knowing it’s rarely an appeal to our minds that inspires any of our greatest achievements.

So how do you lead? Are you following your heart, or your head?

Agile has been all the rage in software development for many years now. Its popularity exists mostly among smaller teams that iterate quickly and release frequently. Agile software development promotes an environment of rapid feedback and continuous improvement. At its core, it helps teams ship fewer high quality features instead of shipping a bunch of features that don’t quite work. In general, agile is highly regarded in the software development word.

But in some larger organizations, agile is often the subject of much criticism and can be found difficult to adopt. After all, how do you get a big, complicated company to adopt a small, simple philosophy? Larger organizations often struggle to make the agile methodology work for a variety of reasons.

Here are some of them:

Agile is a Cultural Shift

Moving away from established rules and procedures can be difficult for large organizations. A big change like this might even require a rigorous change management program. Management needs to get comfortable with their teams organizing their own work. Developers, testers, and designers need to get comfortable working side-by-side rather than simply throwing their work “over the wall.” Everyone needs to share responsibility for the quality of the software.

Communication Breakdowns Across Departments

We’ve all heard of the “silo effect.” In larger organizations where silos exist, failure in communication across those silos leads to an organization that is out of sync. With agile, communication is more important than ever. If your teams are out of sync, your company is out of sync and you’re not functioning as effectively or efficiently as you could be. Focus on communication and you’ll have an easier time implementing agile.

Documentation Gets Left Behind

One of the big principles of agile is less documentation, more work. This can be difficult for large organizations and government organizations as documentation is often required for compliance, legalities, etc. Some teams might employ documentation teams that are responsible for compliance-driven requirements so that the development team can remain truly agile and focus on moving the product forward.

Getting the Customer/Client Onboard

Getting your customer to understand the concept of agile is one thing. Getting them to believe in it and buy-in to the process is another. Some customers see this “new way” of doing things as a risk. As the customer who’s paying you money, they need to feel good about what they are investing in. It’s important to train your customers on agile methodologies – make sure that you set the expectations up front and discuss any concerns to avoid surprises down the road.

Agile is Fragile

Agile is a lean process and therefore it’s prone to breaking down when things don’t go right. Just as your customers need to understand agile, your team needs to believe in agile methodologies. It’s easy to get comfortable with the way things are. It’s easy to avoid change.

With agile, you should always be on the lookout for ways to improve the process, just as you’re always on the look-out for ways to improve the software. Keep your eye out for bottlenecks, weaknesses, and failures. Once you identify them, fix them immediately (e.g. poorly written user stories, flows, tools, team members, etc.).

Closing Thoughts

When implemented properly, agile can truly change the culture of an organization. But it can be difficult for some organizations to adopt due to the reasons I’ve outlined above. Despite the difficulties you may face, try new things and don’t be afraid of change, as hard as change might be. Attempt different “types” of agile, and find the one that works for you and your team.

Regardless, agile is all about experimenting! Go and TRY!

Are you a consultant, agile coach, or employee of a company? Lol. That’s all of you! 

Here’s the hard truth: You are not as effective as you possibly could be.

I know first-hand what it’s like going into a company and not having the faintest clue as to what they are really like. Yes, I got the “brief,” I’ve had the meetings, I even had a few 1-on-1’s, but I really haven’t gotten the whole story. Often, it’s 100% my fault too, as I had not set up the engagement to allow me greater time to sit down and more fully understand the culture…Hey. I’m still human. Oh, and it’s even harder in this remote-work world we live in…

I would venture that you may have experienced something like this as well… You and I both know that it’s really difficult to get a solid pulse on the cultural and team dynamics at play – sometimes we’re simply flying blind. And, you don’t have to be a consultant or coach for this problem to emerge. Anytime you engage with a new team, a new group in your company, a new employee, sometimes we just don’t have the time to get to know people… and that’s the problem. 

I see this happen in startups all the time. They can scale so fast that there simply is NO culture to be had. NO culture that defines them. It’s crazy.  Now, there are lots of ways people define culture. But I’ll give you mine: Culture is what people care about. In companies that scale super fast, nobody knows what anyone else cares about. This creates a culture of transactional behavior. Success doesn’t come from such mechanistic models.

If you never find the time to understand what people care about, you’ll never truly understand how to strengthen the bonds and communication pathways between employees, staff, and management.

Simply put, if you don’t know what your employees care about (or your clients), you do not have a culture, and you cannot know how to nurture people’s growth.

It’s time to build “Agile Culture,” not just an agile method for a team. I recommend, especially in this remote-work world we live in, to set up 15 minute chats with other people in your company. 

Guess what? Those conversations are going to be awkward. That’s good.

Ask questions. Lots of them. Just chat. It’ll be weird, but you both knew that going in.

Spending time at work, only talking about work, with the same people in your company (or same team), day-in-and-day-out, kinda sucks.

The more you get to know others in your company (especially if you’re more than 50 people), allows you to have experiences, now. Potentially fun conversations that last more than 15 minutes… and who knows… maybe you’ll learn a thing or two.

You’re work from home right now, right?

Why the hell not.

I do it with my clients and company. It’s time well spent.

During one of my CSM classes, I was discussing with a student that her company still has office hours and they are “required” to be online at 9AM…

In our new world, why is this still a thing? (Unless you actually have a meeting at 9AM… which changes the context)…

I find it fascinating that in many corporate contexts that: conformity equates to productiveness (in terms of perception).

This is not true.

In Agile, our most powerful evidence of effort is delivery.

Don’t miss this point. Almost nothing else matters.

• Progress
• Status
• Sign Offs
• Productivity metrics
• Performance metrics
• Trends
• Graphs
• Pie charts
• Reports

I could go on and on… but none of that matters.

Ask yourself a powerful question.

Would you rather tell your leadership/CEO/executive/manager that:

“We are working hard.”

OR

“We have delivered something, would you like to review it?”

Delivery is everything. Progress means nothing. Deliver fast. Validate your assumptions fast.

You don’t “manage people.”

You should be (leading) people and (managing) the work.

Or said better, love on people and unblock them.

— Agile Peter

Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

“As organizations (and societies) grow larger and more complex, the people at the top (whether managers or analysts) depend less and less on firsthand experience, more and more on heavily “processed” data. Before reaching them, the raw data – what actually goes on “out there” – have been sampled, screened, condensed, compiled, coded, expressed in statistical form, spun into generalizations and crystallized into recommendations.” – John W. Gardner in Self Renewal: The Individual and the Innovative Society

It is a characteristic of information processing systems that they systematically filter out certain kinds of data so that these nuances of data never reach the ones who depend on the system…

Agile is all about transparency.

I would, and we constantly suggest to our clients, that we do our very utmost to give unfiltered views of how things are going with development, all facets of development.

This way, leadership can make the best informed decisions they can about what is really happening!

Consider what “filtered” information you’re giving to leadership. Consider how that could be doing more harm than good.

Data is only as valuable as it is “real.”

Sprint Planning Meetings for 2-week sprints should take 4 hours or less. However, the first one you ever do will be the worst 10-12 hours of your life up to that point!

— Agile Bob

Join one of our upcoming classes to make your Spring Planning better. Otherwise don’t be surprised when this bites you!

Be exceptionally useful.

I understand specialization, but not at the cost of usefulness.

The most successful people I know are exceptionally useful in a multitude of ways.

Learn how this can help you and your team. Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

Saying “Failing fast is ok” is not helping. People simply don’t want to fail. Instead, say “Learning fast is ok” and see how often people will take risks, even when they end up failing fast!

Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

People who hustle are always to be respected. Whether it’s posted on social or not.

Cheers to the quiet hustlers and the builders in the shade.

Scrum Teams should be respected. Working in sprints is hard. Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

When faced with two different ways to implement something, good programmers will ask themselves “what would the customer want?” Then they will make the wrong choice anyway!

— Agile Bob

And that’s why we need dedicated Product Owners! Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

One of the hardest things to do in life is say “no.”

To invitations, requests, and stuff everyone else is doing.

Even harder is saying no to certain time-consuming emotions: anger, distraction, obsession, lust, busy work.

When you say “yes” you’re committed.

Say “no” more.

ScrumMasters need to help their teams do this. Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

The purpose of adult education is to help them learn, not to teach them all you know and thus stop them from learning.”

-Carl Rogers

Sharon Bowman, the author of the book “Training From the Back of the Room,” has been an enormous influence in my career. She told me very early on, “You don’t want to be the sage on the stage; you want to be the guide on the side.” She helped me recognize the importance of connecting people with the content rather than with the trainer. For me, the most challenging thing she said was, “the one doing the talking is the one doing the learning, so make sure the students talk more than the instructor.”

I read Sharon’s book in late 2009, and it was life-changing. The book was responsible for changing the entire Agile and Scrum training industry. I wrote a blog entry about it, and I spoke about it every chance I got. Other trainers were ready for change, and change happened. Some took longer than others, but now it is not uncommon to see phrases like “No Powerpoint” or “brain-friendly training” in course descriptions. The problem is you can do all of that and still have a lousy class! Making a class genuinely great needs to combine “brain-friendly” with “actionable results.” Some trainers try to overcome this by trying to teach every single thing, and then some! It results in significant cognitive overload, but wow, the experience of drinking from the firehose can be amazing!

I take a different approach. Certainly, I want my classes to be amazing, but I NEED people to leave with actionable results. This means helping them deeply understand the Agile and Scrum mindset and understanding the “why” that makes the “how” work. Once people make this connection, all of Agile and Scrum makes more sense. Having actionable results equals having an impact, and that’s what I’m after every time someone is in my class.

If you are looking for a class, don’t just focus on price, or the buzzwords of “No PowerPoint” and “brain-friendly.” Try to zero in on what the impact of the class will be for you. Look for the trainer’s recommendations and reviews. Everyone can see my LinkedIn, they can also look at our TrustPilot reviews, or the testimonial videos at the bottom of our home page. I like to think we have classes that do it right, even in today’s virtual world!

Perhaps some of you reading this have been in my classes in the past. Put a comment below on whether the class made a difference for you. I’d love to get the feedback!

We are at our most innovative when we exchange ideas with people from diverse backgrounds—even those with whom we vehemently disagree.”

— Survival of the Friendliest: Understanding Our Origins and Rediscovering Our Common Humanity by Brian Hare, Vanessa Woods

There are good reasons why DE&I (Diversity, Equity, and Inclusion) is a hot topic. The awful, terrible truth is the high-tech space lacks all three elements of DE&I. Not all companies are lacking, but most are, and they don’t lack just a little bit! Fewer than 10% of software developers are female. Only 7% of Fortune 500 CEOs are female. You can easily find these statistics, but they only deal with the gender aspect of diversity. I’m using these examples because everyone knows approximately 50% of the population is female, so numbers like 7% and 10% are way out of whack. The problem is worse than the statistics indicate.

The worst kind of group for an organization that wants to be innovative and creative is one in which everyone is alike and gets along too well.

— Margaret A. Neale, The Adams Distinguished Professor of Management, Emerita, Stanford Graduate School of Business

Every research study I can find online shows the same results: Diverse teams have the potential to perform far better than homogenous teams. Notice the phrase “have the potential to,” which is an important qualifier. Just putting a diverse group together is not automatically going to result in the team improving. There is also the potential for catastrophic conflict as cultures and beliefs clash.

Ok, Agile Bob, we get that diversity can be helpful, but how in the world do we protect against conflict tearing the team apart? I’m glad you asked because the answer is in almost every single course I teach! The simple answer is having an effective ScrumMaster or similar role on the team. A common misconception is that a ScrumMaster only facilitates the various Scrum events and removes impediments for the team. A ScrumMaster will at various times be a coach, teacher, mentor, and facilitator, but most people miss how much ground facilitation covers. Facilitation isn’t just about running efficient meetings. It includes conflict resolution, which for my money, is what separates truly great ScrumMasters from the also-rans.

I won’t be able to give you all the ins and outs of conflict resolution in a short article like this one, but I can give you some quick pointers. First, most experts agree with the five conflict resolution strategies derived by Dr. Kenneth W. Thomas and Dr. Ralph H. Kilmann. They have developed something called the Thomas-Killman Conflict Mode Instrument. Once a ScrumMaster understands their default strategy, they can improve or work on moving to a more effective technique. Collaboration is great, except when it isn’t! A great ScrumMaster can use all five strategies at the appropriate times.

Invest in learning how to resolve conflict. It will make it safer for your team to be much more diverse. If your group is already diverse, having good conflict management enables the team to explore boundaries without fear. Exploring boundaries often leads to breakthrough innovation.

When you change the way you think about product development you will change the way you want to do product development. Remember to focus on shared principles and values before worrying about practices. The agile mindset drives the proper focus and better results!

Our courses are specifically designed around this advice. If you understand the “why,” you will do the “how” better! Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

It is always easier to destroy a complex system than to selectively alter it.

— Weinberg on Writing: The Fieldstone Method (page 416) by Gerald M. Weinberg

When I think of software, I immediately think of complexity. The two have been intertwined for me since I wrote my first computer program in 1971. The program I wrote was not complex, nor was the problem related to it. The linkage with complexity was evident when I realized the vastness of problems computers could solve. I remember wondering if a computer could play chess or even checkers? I immediately saw enormous potential for the future of computers, and in some ways, I think I saw my destiny.

A complex system is a system composed of many components which may interact with each other.

— Wikipedia entry for “Complex system”

I didn’t officially become a software developer until more than ten years later, but what I wondered about was already coming true. In fact, in 1996, the IBM computer program named Deep Blue defeated Chess Grandmaster and World Champion Gary Kasparov. The first time a computer had ever won a game against a reigning world champion. Kasparov came back to win the match by a score of 4-2, but in 1997 Deep Blue won the match’s last game to secure a 3.5-2.5 overall victory. Software was undeniably solving complex problems. As a result, the world was changing.

Fast forward to today. We have come a long way since someone wrote the first “Hello world.” program. The phone you carry around may have more than 1,000,000 times more memory than the 64k a good computer had in 1972. We are in the world of big data and high-speed communications, and decision-making. Our computer programs now have many different components which interact with each other. The literal definition of a complex system according to Wikipedia (and hey, it’s on the Internet, so it must be true!).

Our two quotes above seem to say software is a complex system, and it is easier to destroy complex systems than it is to make selective changes. We make selective changes to software all the time, but we don’t destroy it, right? Well, maybe yes, and maybe no. How easy is it to implement changes to the system? For most of you, making changes to an existing system is extremely difficult. You would probably agree with Weinberg that destroying it would be far easier! It is tough to make the right changes and have the changes work correctly. How often have you or your team made changes and weeks later found out that a completely different area of the system was failing because of the changes? It happens every day at companies all over the world. So what can you do about it?

The answer is amazingly simple and diabolically hard at the same time. Use better software engineering practices. The days of big design up front (BDUF) are over. It is time to learn how to create software incrementally with high quality and high value. Yes, I’m talking about Agile/Scrum/Kanban/whatever, but I’m talking about more than that too. Help your team learn about the technical practices that lead to agility, quality, and value, while not increasing technical debt. Our complex systems often have lingering technical debt issues, which make changing the software more difficult. Invest in your team (or just you!) learning about pair programming, test-driven development, behavior-driven development, refactoring, and continuous integration. Click here for an article my friend, Rob Myers, wrote about these practices.

This blog post won’t teach you any of the technical practices you need for future success. My goal is to make you aware of the techniques you need to know! Now, go do some Google searches for “eXtreme Programming,” or “agile technical practices,” and get to work creating better software for the future! It has to be more fun than beating your head against the wall wanting to destroy the software rather than enhance it!

1. Too much to do. This generally causes us to begin multi-tasking, which is an awful way to work. Click here for more on this topic.
2. Changing priorities. When priorities are continually shifting, it is impossible to dig in and feel productive.
3. Unrealistic deadlines. Goals that are impossible cause incredible stress. Stress leads to errors and a feeling of being overwhelmed.

So far, I haven’t told you anything you don’t already know. Life is hard, and it makes us feel out of control. Yup that sounds about right, so how do you fix the issues? Unfortunately, I can’t help you completely fix the problems, but I can help you feel less out of control. My recommendation is to start with how you manage your time. For most people, time management consists of going from one emergency to another, which by definition means you aren’t in control. Let me give you two techniques I use successfully:

1. Pomodoro Technique At its core, the Pomodoro Technique feels a bit like a mini version of agile. You focus on one thing for 25 minutes, then take a 5-minute break to recharge. After 4 increments of 25 minutes, you take a longer 20 or 30-minute break. The key is making sure you focus on only one thing during each 25 minute working period. Most people set a timer so they stop each time period properly. The word “pomodoro” means “tomato” in Italian and the developer of this technique originally used an Italian timer shaped like a tomato!
2. Eisenhower Matrix Rather than describe the Eisenhower Matrix, here’s a recent #AgileDailyDose video on the topic.

I use both of these techniques in different ways. The Pomodoro Technique is very useful as a base technique for getting work done. I use it to just work through my backlog one item at a time.

The Eisenhower Matrix is useful for creating my backlog. I also use it when I am processing email. Do I delete, delegate, defer or do something with each email? This is a constructive way to get through a lot of emails quickly. I use SaneBox for deferring email. I also use it when I respond to email and need to potentially followup at a future time.

You can try these techniques if you want to feel more in control at work. Both give you ways to make choices about what you work on and when you do that work. A Scrum Team can also use the Eisenhower Matrix to evaluate the order of the product backlog.

I’ve written how I use these techniques, but you aren’t limited to using them the same way. Feel free to experiment. The key is to focus on being strategic rather than reactive. Being strategic allows you to be in control. By definition, being reactive will mean you are not in control!

Use the comments to let me know how you use these techniques. You can also ask me questions. I’m happy to engage on this topic!

Knowledge, particularly self-knowledge, is freedom.

Why is this so?

When you know yourself, you can work and live 100% within your wheelhouse in ALL aspects of life. Work, play, rest, de-stress, love, eat, etc.

You’ve optimized.

You’ve gone pro.

ScrumMasters need to deeply understand this and they need to help their teams understand it as well. Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.

Amazing teams are almost always small teams. The quote from the 2016 Scrum Guide makes it clear why team size is so important. There is a tremendous amount of research on this topic. Doing a Google search for “optimal team size” gave “about 333,000,000 results.” Is the Scrum answer of 3-9 people correct? Spending a bit of time combing through the top Google results shows responses of 3-5, 5-6, fewer than 5, and “it depends on the manager” (which is probably my personal favorite because it was in an article from a company that focuses on management!). The most common answer seems to be 5-6 people. When ignoring the most common answer, it is clear that smaller than 3 is too small and larger than 6 is too big, so we can almost certainly narrow it down to the 3-6 range. That’s a smaller range than 3-9!

Why is the optimal team size number so small? Once again, I will use recent videos from our #AgileDailyDose videos to give you some ideas. First, we are going to explore how team size affects overall communication within a team.

The number of communication pathways becomes very difficult to maintain on larger teams. That leads to breakdowns in overall communication, resulting in missed opportunities and lower overall effectiveness. There is a second issue caused by having large teams. On larger teams “social loafing” is possible. We have a video that touches on this topic in a roundabout way.

All of this information makes sense, but how does it help you in the real world when you have massive projects to work on and you need a lot of people to do the work? This is a make or break question for the success of agility in many companies. The traditional mindset about projects says big projects require lots of people on the team to get the work done. An agile mindset says big projects require a lot of breaking down of the project into smaller chunks so smaller teams can attack it successfully. I recognize this isn’t as easy as it seems, but teams of any size need to understand how to break work into small chunks that can be attacked in sprints/iterations. It is a key skill to success with agile.

The problem I see just as often is on the other end of the size spectrum. Many companies have lots of small projects that one or two developers work on until they are done and move to the next project. This situation allows more projects to be worked on simultaneously, which seems reasonable. However, in my experience, it is often better to combine those small teams into a larger team of 5-6 people. Why? Because it allows them to decide how to split that same work across the group. It will enable the team to self-manage how the work gets done, and that will almost always be more effective than externally managing how the work gets done by assigning small teams to the projects. The team may decide to create small subgroups to attack the various pieces of work in the way they had done it before, BUT they have the option not to do it that way. There may be something they can do differently and better when they are part of a larger team with more diverse skills.

In summary, if you want to have the best chance of having an amazing team you should:

1. Make teams that are the right size. No fewer than 3 people on a team, and no more than 6. Based on all the coaching I’ve done with teams over the years, my strong advice is to stay with 5-6 people on software teams.
2. Split up big teams. If your team is larger than 5-6 then consider splitting it into two groups. How difficult this will be, hinges on the cross-functionality of the team. Can two similar cross-functional teams be created from one team? If yes, then the split is easy. If no, then the team’s splitting needs to take into account how the skills on each team can work together to create value every sprint.
3. Combine small teams. Making one team of 5-6 people out of multiple smaller teams will give more options for working effectively. More choices lead to better overall throughput and effectiveness. Empowering teams to self-manage the way they do their work generally leads to benefits beyond just the overall throughput of the work. Morale goes up while turnover goes down. Increased morale leads to more gains in effectiveness. It turns into a very positive upward cycle!

My closing thought for today is this: Always ask, “How can I break the project down so teams of 5-6 people can attack it?” instead of “How many people do I need on a team to do this project?” Thinking about smaller chunks will always end up better. I don’t recall where I read this, maybe a recent Standish Group CHAOS Report, “In any large project, there are dozens of smaller projects dying to get out.” That’s good advice!

Use the comments to let me know your thoughts and experiences on this topic. Feel free to join our Agile Community to ask questions or learn more on this topic. We recently launched the Agile Community, so there isn’t a lot there yet, but it is free to join right now. I hope to see you there soon.

Read part 4 of this series here.

Many people think Scrum is about getting things done faster. It isn’t. You get the right things done in the right order and you leave out anything that doesn’t add value. The net result is you may deliver faster, but it is because you did the right things, at the right time, in the right way.

Scrum Teams, especially the Product Owners, need to deeply understand this. Go to our upcoming courses page to sign up for one of our classes so you can get more wisdom like this!