Zombie Scrum

Coaches who have not seen an advanced agile shop tend to see the Scrum rules as an end state rather than as a starting point.

A year ago, your organization adopted the Scrum framework. Scrum helped you break down functional silos, improve communication with stakeholders, increase collaboration on your team and across teams, and facilitate cross-disciplinary skill development among staff members.

It was exciting at first. Everyone was engaged and everyone was enthusiastic.

Stable teams were established, and work was allocated to teams as deliverables were completed. People began to spend their days in team spaces designed as collaborative work centers, rather than sequestered in cubicles like so many hermits.

In every Sprint, teams built trust with stakeholders and learned more about the business domain and the technologies in play than they had previously imagined possible. Delivery effectiveness, stakeholder satisfaction, and team morale improved over the next six months.

Laissez le bon temps rouler

Life was good.

And the clock ticked on. And on.

And on.

After learning all there was to know about the types of work their stable teams carried out, people began to wonder when or how they might get the chance to learn something new. Life took the shape of an endless series of User Stories, mostly comprising the same sorts of changes to the same parts of the same codebase over and over again.

And the clock ticked on.

What about collective ownership? Self-organization? Retrospectives?

Yeah, sure. Collective ownership of the same sorts of changes to the same parts of the same codebase over and over again. Self-organization regarding exactly how to carry out the same sorts of changes to the same parts of the codebase over and over again. Retrospectives in which the same issues are raised time and again, and all the remedies lie beyond the team’s purview. As far as anyone on a delivery team can see, the root cause of the issues is Scrum itself, if not life itself.

Everyone is disengaged and everyone is apathetic.

Like zombies.

Management and business stakeholders don’t really see the problem. After all, delivery is steady and predictable, and much more efficient than it was before Scrum was introduced.

Portfolio and Program teams (or their equivalent by any other name) don’t really see the problem. After all, the delivery teams are accepting prioritized User Stories and delivering them on a steady basis.

If there were issues, the teams would report them, wouldn’t they? That’s the model, isn’t it? The only reason a person would hesitate to report an issue is if they didn’t believe any good would come of it. Scrum is good by definition, so that can’t be the case.

But there’s trouble in the trenches. If the technical staff can’t change their organization, they’ll change their organization.

Send in the coaches

It’s a good thing you have agile coaches to help you! What do they have to say about the situation?

They say things like this:

You’re a self-organizing team! You can figure it out!

  • Bring up the issue at the next retrospective. Don’t forget to create an action item!
  • If you can’t solve the problem at the team level, escalate!
  • Agile people are passionate about their work. Look within and find your passion!
  • Stare at this inspirational poster about Scrum until you feel better.

Well, okay, that last one was a little snarky. But only a little. The sad thing is it isn’t too far from the truth. It’s more-or-less the Scrum equivalent of the traditional mantra, “The beatings will continue until morale improves.”

Certification overload

Informally I’ve been told more than 400,000 people have gone through a formal Certified ScrumMaster (CSM) course offered by the Scrum Alliance. On the Scrum.org website, that organization claims over 100,000 people hold Professional Scrum certifications. That’s a lot of certifications.

Why, then, are there so few agile or Scrum coaches who can take it beyond the novice level? It may be a case of “too much of a good thing.”

People who are interested in Scrum but not too sure what it’s all about tend to look for certifications as a form of assurance that they’re listening to the right people. ScrumAlliance and Scrum.org are happy to offer certification programs. Many agile coaches hold the basic certifications from one or both these organizations, and many have experience in getting teams and organizations started with rudimentary Scrum practices. Their career path consists of getting one organization started, then moving on to another organization to get them started, then moving on…well, you see where this is going. Most agile and Scrum coaches have never experienced a situation beyond the initial stages of getting started with agile in general or Scrum in particular. They have not seen the problems that normally occur after a long series of Sprints.

Is something wrong with the certification process? Well, not really. You have to start somewhere. But the base-level certification, Certified ScrumMaster (CSM) is surprisingly easy to obtain. A colleague told us he had his child take the exam, and he passed on the first try. The child had never taken a CSM course, and was only as interested in Things Agile as any other child would be (that is, not very).

The ease with which a person can obtain a CSM credential has led many individuals to take the CSM class who have absolutely no experience in IT. They’ve never written code, tested software, analyzed business problems, managed a project, administered servers or networks, worked with database systems, or worked in operations or production support. When they are coaching a delivery team, they have no way to relate to the practical challenges the team faces. Credit where due: They’re pretty good at sticking things on the walls.

Zombie Scrum is a perfectly normal and predictable stage in an organization’s development. Most coaches don’t know how to advise zombie Scrum teams because they’ve never stayed with the program long enough to see the problem manifest.

And the Scrum literature doesn’t talk about zombie teams. <understatement>It wouldn’t be a very strong selling point.</understatement>

All problems are management problems

Lest you point the finger of blame at underqualified and overcertified Scrum coaches and ScrumMasters, consider the wisdom of the old saying, “All problems are management problems.”

Scrum introduces a few unfamiliar concepts and roles. One of them is the role of ScrumMaster. Managers who have a traditional background often have difficulty with the concept of a ScrumMaster. When we simultaneously introduce the ScrumMaster role and reduce the importance of the traditional Project Manager role, it’s only natural for people to fill in the gaps based on their own experience. They re-title the Project Manager as ScrumMaster.

This mangled ScrumMaster role has two responsibilities, and the two are in direct conflict. One is the responsibility to help the team use Scrum effectively and to support them in their continual improvement efforts. The other is direct responsibility for delivery. The freshly-minted ScrumMasters inherit the latter responsibility from the deprecated Project Manager role, which management still believes is necessary.

Even in the best case, it’s hard to serve two masters. When you have the dual responsibility of delivery and team coaching, the delivery responsibility always prevails. Why? Because it’s often necessary to present challenges to the team to create learning opportunities for them. If you have responsibility for delivery, you can’t do that. You can’t help the team improve. You, yourself, are measured on steady delivery. You have to keep the team running on the treadmill non-stop. You have no choice.

That isn’t a coaching problem, it’s a management problem. Your role is improperly defined.

Can zombies be awakened?

One of the top Scrum trainers and consultants in Europe, Joseph Pelrine, describes a model of team performance he calls the Cooking Model. When you’re cooking, you don’t want the temperature to drop so low that the food congeals into a flavorless mass. At the same time, you don’t want the temperature to rise to high that the food burns. There’s an optimal temperature for cooking. Similarly, there’s an optimal “temperature” for a delivery team. Too much stress, and the team burns out. Too much boredom, and the team members turn into zombies.

Pelrine advises coaches to shake things up when they see the zombie team phenomenon starting to occur. Teams may miss delivery targets when this happens, but it’s all to the good. We want the teams to deliver predictably over the long term. Sometimes, that means allowing short-term variation in delivery performance in the interest of improvement.

Another factor to keep in mind is that most of the guidelines and practices defined in Scrum are meant to be a starting point for teams. As teams progress in agile and lean thinking, they will require progressively less process-management overhead. Coaches who have not seen an “advanced” agile shop tend to see the Scrum “rules” as an end state rather than as a starting point. When teams have outgrown the need for the rules, and they are required to continue following the rules anyway, they check out. Coaches who haven’t seen this won’t know how to help teams overcome the perfectly normal Zombie Scrum stage.

Imagine, if you will

These “starting rules” include some of the holiest-of-the-holy dogma in beginner-level agile coachery. Team collocation. Stable teams. Story sizing. Others.

All these “rules” have a purpose. Remember that Scrum was created in the early 1990s based on work published in the mid-1980s. Recall the state of the corporate IT world at that time. Matrixed organizations. Individuals assigned to multiple projects concurrently. Functional silos. Isolated, solo work. Indirect communication methods.

And the results: Very long lead times. High defect levels. Low customer satisfaction.

Scrum addressed all those issues in a practical way. By following the Scrum “rules,” 1980s-era organizations could break those nasty old habits and start to achieve better outcomes.

Do we really need collocated teams? Well, it’s better than having individuals scattered all over the place, not collaborating, and communicating only indirectly through “tools” and such. But the goal isn’t merely to sit in the same room together. The goal is collaboration. If people are interested in collaboration, they will find a way. We certainly have technologies today that support remote collaborative work. There’s no longer a need to force everyone to sit together physically. That was never really the point, anyway. It was only a means to an end.

Do we really need stable teams? Back in the day when people were measured on individual performance, there was little sense of team membership or shared ownership of results. You had no incentive to collaborate. In fact, you had every incentive to make everyone else look bad, so you wouldn’t be riffed in the next stack-ranked layoff sweep. The cure? Stable teams. People got used to working with each other and began to feel like a real team. What happens when people feel that way throughout the organization? Well, maybe there’s no problem letting people work on different things. They’re accustomed to smooth collaboration and transparency. There’s no more “storming and norming.” Collaborative work is natural for them. So, if someone wants to work on something other than the same sorts of changes to the same parts of the same codebase, it’s no problem.

Is there a point to this?

Well, yes. The point is the Zombie Scrum phenomenon may be a signal that the organization is ready to move beyond beginner-level practices, shed some of the novice-level process-management overhead, and mindfully bend or break some of the “rules.” Shake things up. Restore people’s enthusiasm. Grow.

Just food for thought. Meanwhile, all this typing has made me feel a bit peckish. Please pass the brains.

The post Zombie Scrum appeared first on LeadingAgile.

via LeadingAgile http://ift.tt/2spxiiO

Top-down management doesn’t work with Scrum

Top-down management doesn’t work with Scrum

Scrum Alliance released its 2016 ‘State of Scrum‘ report and the results indicate that businesses are having difficulty adapting to Agility based project management. Scrum is an Agile framework for completing complex projects. The basic idea behind the platform is for workers to share information and remain flexible to client-based design changes.

There are a lot of meetings involved. Workers combine their efforts to continuously advance the entire project — instead of relying on a more linear approach to development. The survey tries to find out how Scrum is working out for companies that implemented it in 2016.

Two-thirds of the survey participants said that tensions rose in the workplace after Scrum was implemented, but 70-percent of those respondents indicated that company management was to blame.

The report discloses that over half the workers surveyed think their business struggled with implementing Scrum. The responses paint the picture of a system that works — 98 percent of those surveyed said they were going to use it again — but also increases worker anxiety.

I reached out to an expert to explain why. The Denovo Group Founder and CEO Lisa Hershman says:

“The challenge is that many corporate leaders think Agile or Scrum is just an IT thing. When talking to those decision makers, we need to put the ideas in business terms that they understand. It’s about providing a better experience for customers and boosting the bottom line.”

Isn’t Scrum just an IT thing though?

Turns out that out of the 2000 survey respondents, seventy-two percent work in industries outside of IT. Lisa Hershman predicts that managers are simply going to have to figure it out. “Top-down doesn’t cut it anymore. As our world continues to change, Agile business structure will not only become invaluable but nonnegotiable.”

That could explain the tension — telling the VIPs that their new Agile platform works best without Top-down management sounds like a job for whoever draws the short-straw.


Why Scrum?
on 2016 State of Scrum Report

Read next:

Windows 10 now has an emoji shortcut (it’s about time)

Tristan Greene is a sailor gleefully writing about living on dry land. He’s been known to brag about his Rockband 2 scores.

via The Next Web http://ift.tt/2rahK24

The Career Path of a Scrum Master

I blogged recently on the question of whether a Scrum team can ever get so good that they no longer need a Scrum Master. In this post, I’ll address a closely related topic: Assuming that the role of Scrum Master does not go away, what is the career path for a Scrum Master?

In my experience, a Scrum Master’s career will usually evolve in one of four directions.

Multiple and More Challenging Teams

A typical career path for a Scrum Master will start with serving one team. After a while that team becomes less time-consuming to work with, as issues are resolved and the team takes on more responsibilities itself.

At that point, a good Scrum Master will seek additional challenges. Often the logical next step is to begin working with multiple teams concurrently or from working with more demanding teams or products.

When developing new Scrum Masters, I prefer to put the person in a position to most likely succeed. That will means working with a team that has neither any difficult personalities nor unrealistic delivery expectations. But, to go from good to great, the Scrum Master will need to learn to work under more complex conditions.

This leads to the philosophy that success is often rewarded with additional challenges.

Mentor

A Scrum Master who has been successful in a variety of different contexts and teams, might choose to move into a role as a mentor to other Scrum Masters. This will especially be true and feasible as the Scrum Master gains skills and experience.

In many organizations, this role would be called an Agile Coach, with the most common job description being that an agile coach coaches Scrum Masters (and their teams).

Personally, I’m partial to such individuals mentoring rather than just coaching. Much of the benefit these experienced individuals provide comes through them offering guidance (“I suggest you do it this way”). Because of this, I think of these individuals as having become agile mentors.

This is an appropriate path for Scrum Masters who have learned that their true passion is the creative act of developing a product–largely independent of whatever the product may be. Some Scrum Masters enjoy the process of enabling creativity among development teams so much that it almost doesn’t matter what the product is.

Think about the radio DJ who just loves being a DJ and doesn’t care if he’s playing classic rock, the current top 40, or classical music.

The Scrum Master who loves the process more than the product is a likely candidate to follow a career path into becoming an agile coach or mentor.

The Scrum Master Becomes a Product Owner

Other Scrum Masters, however, learn that they love what their team is building more than the act of creating it. Those Scrum Masters become good candidates to become product owners.

I don’t want to imply that a product owner role is above the Scrum Master role in an organization. I consider the roles equivalent in a typical organizational hierarchy.

But some Scrum Masters learn that they care deeply about the thing being built rather than the process of building the thing. And from having worked with a team long enough, some of these Scrum Masters learn enough about the product, industry, users and such to become good product owners.

The Scrum Master Becomes a Manager

Scrum Masters are most assuredly not managers themselves. But through their Scrum Masters duties, Scrum Masters often work closely with those who are. And some will find that work intriguing.

Scrum Masters become adept at guiding teams without much authority to say, “Do it because I say so.” Because of this, many can move into management roles where they could demand compliance but because of what they’ve learned from being Scrum Masters, know it usually is best not to.

Especially if a Scrum Master has retained technical proficiency, moving into a role like QA director or development manager can be a fulfilling, logical step.


Scrum Masters often become coaches, mentors, product owners, managers or continue as Scrum Masters in more challenging situations.

A Scrum Master Has Options

There are many paths a Scrum Master may pursue. The skills learned in becoming a great Scrum Master will serve that person well whether they choose to become a mentor, manager, product owner or just work with more challenging teams.

In some ways, asking what is the career path for a Scrum Master is like asking what is the career path of a professional athlete.

Some professional athletes use their former careers as springboards to move into broadcasting. Others use the money they’ve made to start businesses–where I live in Colorado, car dealerships and pizza restaurants seem popular with retired athletes. Some athletes use their fame to enter politics.

Still other professional athletes would find the topic of a career path preposterous. They didn’t become athletes as a path to something else. Becoming a professional athlete was the goal itself.

And so it will be for many Scrum Masters. The role of Scrum Master can be an end itself. Doing it more and better can remain the goal. A professional athlete cannot perfect his or her sport. A Scrum Master cannot perfect that skill either. There is always room to improve. And so, for many Scrum Masters, there may be no career path other than the continuous improvement in themselves that Scrum Masters demand of their teams.

Where Are You Headed?

If you’re currently a Scrum Master, what do you think is next for you? If you were formerly a Scrum Master, what you done since leaving that role? Please share your thoughts in the comments below.

via Mike Cohn’s Blog http://ift.tt/2rmTq8U

Scrum and Kanban Stronger Together

What is your reaction to reading this post’s headline? Do you feel a sense of affirmation because you believe that Scrum and Kanban are compatible? Or do you feel irritated because you fall firmly in either the Scrum or Kanban camp and believe one approach outperforms the other?

I believe that exploring how Scrum and Kanban can complement each other is long overdue. I base this opinion on my experience as a former Accredited Kanban Trainer and Coaching Professional and my current role as a Professional Scrum Trainer and Scrum.org team member. My take is that because Kanban and Scrum practitioners have broken into separate camps, software teams are missing out on practices that would improve their effectiveness.

I’m not alone. Daniel Vacanti makes the same argument. Daniel was on the team that developed the Kanban method, and he was the first manager to apply Kanban within the context of a real-life project. Today, he is the CEO and co-founder of ActionableAgile and author of Actionable Agile Metrics for Predictability. He wants to see greater collaboration between our two communities as well.

Many of us whose role it is to promote Scrum and Kanban have improved our understanding of each approach and recognize that the two have more similarities than differences. Daniel and I agree that rather than wasting energy defending our separate camps, there’s greater value to be gained from working together on our shared goal of helping organizations deliver outstanding value to their customers.

Why This Is the Time to Foster a New Scrum-Kanban Relationship

Scrum recently celebrated its 21st birthday, which in many cultures is the age of adulthood. It’s a significant milestone that is often an occasion for reflection. Scrum has achieved a lot over the past two decades. Ninety percent of teams that use Agile use Scrum with a total of 12-15 million practitioners. What will sustain Scrum’s relevance in the decades to come is our commitment to the Scrum values, which were recently added to the Scrum Guide. One of these values is openness. When we are aware of other effective Agile practices that are complementary to Scrum, we should embrace them. It’s time to recognize the strengths inherent in the practices of Kanban and to explore how our two approaches can connect to produce better outcomes.

From Daniel’s perspective, he is experiencing a renewed spirit of inclusion and collaboration born from a movement within the Kanban community to return to its roots. “For many reasons, the Kanban community has strayed from its founding principles of inclusion, learning, and collaboration,” he explains. “During the process of exploring how we need to regroup, the Kanban community is looking at what makes other communities successful. This has led to a realization that we have much more in common with other groups than we had previously acknowledged.”

Making the Case

Daniel and I are going to explore how together our two approaches can achieve better results. To kick off that exploration, we’re going to start with a blog post series that will cover the basics of Scrum and Kanban and tackle how the various practices can enhance each approach.

We invite you to contribute your thoughts and suggestions. If there are points you would like us to cover or questions you’d like us to answer, let us know in the comments, and we’ll make sure to address them.

Here Are Some of the Topics We Plan to Explore:

All I Really Need to Know I Learned In … (Part I)

A Kanban primer for Scrum Teams

All I Really Need to Know I Learned In … (Part II)

A Scrum primer for Kanban Teams 

Diet of Worms: What Scrum Gets Wrong about Kanban and What Kanban Gets Wrong About Scrum

Dogma and negative rivalry have interfered with real learning. We will dispel the myths on both sides. 

ScrumBan or KanScrum? It’s Neither: How the Two Really Should Work Together

The two set of practices are not mutually exclusive. We’ll examine how they’re complementary.

Hobson’s Choice: Scrum or Kanban?

Must you choose one or the other? Should anyone ever have to make that type of decision?

via DZone Agile Zone http://ift.tt/2qBQLM3

6 Coaching Tips for Scrum Masters

First, let’s define what coaching is. You can find many definitions, but here is how I describe coaching.

Coaching enhances your ability to learn, make changes, and achieve desired goals. Coaching is a thought-provoking and creative process that enables people to make conscious decisions and empowers them to become leaders in their own lives.

via DZone Agile Zone http://ift.tt/2o047Mp

Scrum vs. Kanban

In Agile software development, different methodologies of work are used. Here at Apiumtech, depending on the project we are working on, we usually use one of two frameworks. We either go for the Scrum methodology or for Kanban project management. Sometimes, we like to mix it up and go with Scrumban. 

In this post, you will find more information about Scrum, Kanban, some key terms, and the differences between both. If you are interested in knowing more about Scrum in general, we’ve got a great article explaining Scrum Sprints

via DZone Agile Zone http://ift.tt/2iOq13n

Scientists say your personality can be deconstructed into 5 basic traits

five friendsFlickr/Michael Mooney

Business Insider’s Kevin Loria recently spotlighted a test that can give you a scientifically accurate assessment of your personality.

The test — the International Personality Item Pool, available online in both long and short versions — rates you on five personality traits, known to psychologists as the "Big Five."

You can remember them using the acronym OCEAN: openness to experience, conscientiousness, extroversion, agreeableness, and neuroticism.

Each of the five personality traits breaks down into multiple facets. We consulted some of the original research on the Big Five personality traits, published in the 1980s, and looked at what a psychologist and a social worker have written about the Big Five more recently.

Here’s what the test measures, and a bit about what your score on each trait might say about you:

Openness to experience

A high score means you’re:

  • original
  • imaginative
  • daring
  • you have broad interests
  • you generally prefer variety over fixed routines

One review of studies found that, in business settings, openness is a strong predictor of who will become and succeed as a leader.

Another study found that you can tell how open someone is based on their selfie — specifically based on whether they display positive emotion.

Conscientiousness

A high score means you’re:

  • hardworking
  • ambitious
  • energetic
  • persevering
  • you like planning things in advance

Psychologists say conscientiousness is the best predictor of both personal and professional success. It’s also the strongest predictor of leadership in different contexts, including business, government, and school.

Extroversion

This trait is sometimes called "surgency." A high score means you’re:

  • sociable
  • fun-loving
  • affectionate
  • friendly
  • talkative
  • you derive energy from social activity

Extroversion is another strong predictor of who will become a leader — though psychologists are increasingly discovering that introverts can do just as well in leadership roles.

Agreeableness

A high score means you’re:

  • sympathetic
  • kind
  • affectionate
  • you’re likely to engage in pro-social behavior and volunteerism

Research suggests that agreeable people tend to be happier, possibly because they try to avoid negative experiences. On the other hand, disagreeable people may be more likely to succeed at work because they’re better at getting their ideas heard.

Interestingly, one study found that people who have a looser gait tend to be more agreeable (and less conscientious).

Neuroticism

A high score means:

  • you worry a lot
  • you’re insecure
  • self-conscious
  • temperamental

That same selfie study mentioned above found that neurotic people are more likely to make a duck face. Go figure.

As a reminder, you can take either version of the personality test here.

NOW WATCH: 5 signs you’re going to be extraordinarily successful

See Also:

SEE ALSO: A 15-minute quiz can give you a scientifically accurate assessment of your personality

via Business Insider http://ift.tt/2iBfus3

The Chief Product Owner on Large Agile Projects

The product owner role can be one of the most challenging on a Scrum project.

On all projects, the product owner is torn between competing inward-facing and outward-facing needs. Among the inward-facing tasks are participating in planning meetings, sprint reviews, sprint retrospectives and daily scrums; managing the product backlog; answering questions from the team; and simply being available to the team during the sprint.

A product owner’s outward-facing tasks include talking to users about their needs; creating and interpreting user surveys; traveling to customer sites; attending industry trade shows; managing stakeholder expectations; prioritizing the product backlog; determining product pricing; developing a medium- and long-term product strategy; watching for industry and market trends; performing competitive analysis; and more.

Too Much for One Person to Do

On a project with one team of developers, this can be a vast but achievable amount of work. On a large project with multiple teams, however, the product owner role is too big for one person, so we must find ways of scaling it.

As a project grows to include multiple teams, ideally a new product owner is found for each. If you cannot achieve a one-to-one correspondence between teams and product owners, try to have each product owner responsible for no more than two teams. This is usually the most that one product owner can effectively work with.

At some point, as the overall size of the project grows, it makes sense to introduce a hierarchy of collaborating product owners. The figure below shows such a hierarchy, with a product owner working with each team, two product line owners each working with a cluster of teams and a chief product owner. Naturally, layers can be added or removed as needed for the scale of the project.

Sharing Responsibility, Dividing Functionality

A chief product owner is responsible for having an overall vision of the entire product or product suite. The chief product owner conveys this to the entire team in whole-team meetings, e-mails, team get-togethers and through whatever other means are available.

But the chief product owner is almost certainly too busy to assume hands-on responsibility for working as the actual product owner for one of the five- to nine-person teams building the product. At this level, the external-facing requirements of the role are too great.

A good chief product owner will be very involved with teams—attending daily scrums occasionally, walking through team areas whenever in the office, and offering support and feedback. But the chief product owner will need to rely on the product line owners and product owners to handle the intricate details of their product segments within the overall project vision.

An Example of a Chief Product Owner and Product Line Owner

Suppose, for example, we decide to develop an office productivity suite that will include a word processor, spreadsheet, presentation software and personal database. Competing with Microsoft Office, Google Apps and other products will be daunting, but our chief product owner is fearless.

Because the chief product owner will be focused on strategic issues, competitive positioning and such, product line owners are selected to own the individual products in the suite—the word processor, spreadsheet, presentation program and database.

Each product line owner in turn identifies product owners who will be responsible for feature areas within the product. The product line owner for the word processor, for example, may work with one product owner who is responsible for tables, another responsible for stylesheets and printing, another who is responsible for the spell checker and so on.

Although as previously mentioned, the chief product owner is too busy to be the product owner for one team, it is possible for a chief product owner to act as the product line owner for part of the product.

Continuing with the preceding example, our chief product owner may choose to also be the product line owner responsible for the word processor, perhaps because of being in that role previously.

Similarly, a product line owner will often want to stay involved in a more hands-on manner and will work also as one of the product owners. Perhaps our product line owner for the spreadsheet product also acts as the product owner for the team that will add charts to the spreadsheet product.

Although functionality can be divided along these lines, it is important for all product owners to feel a shared responsibility for the full product. They must also instill this feeling of shared responsibility in the teams they work with.

How Do You Scale Up the Product Owner Role?

How do you handle the product owner role on projects with three or more teams? Please share your thoughts in the comments below.

via Mike Cohn’s Blog http://www.mountaingoatsoftware.com/blog/the-chief-product-owner-on-large-agile-projects#When:15:00:00Z

7 mental models you should know for smarter decision making

Every one of us make dozens, if not hundreds of small to big decisions on a daily basis.

Some don’t impact our lives at all, while some can change the outcome of our entire lives.

All Killer, No Filler

We’re bringing Momentum to New York: our newest event, showcasing only the best speakers and startups.

Whether it’s trying to figure out which job you should take, deciding to quit your job to start a business, move to a new city — these decisions are never easy.

Yet there are people who we can learn from who make highly impactful decisions on a regular basis, and they’ve developed mental models to help them make smarter decisions.

We’ve curated our 7 favorite mental models for you to enjoy.

1. 10/10/10 Rule

Short term vs Long term

After reaching the top pinnacle of the publishing industry, one of the mental models that Suzy Welch adopted to help her navigate through tough personal and professional times is called the 10/10/10 Rule.

Most of us have been guilty of making decisions without thinking about the long term consequences, and the 10/10/10/ rule can used to reflect on the long-term by asking yourself:

  • How will we feel about it 10 minutes from now?
  • How about 10 months from now?
  • How about 10 years from now?

big-picture-thinking-4-638

It’s easy to make short-term decisions that may be beneficial 10 minutes or 10 months from now, but these types of decisions usually don’t benefit us in the long-term. What’s harder is to make decisions that may not appear attractive or impactful in the short-term, but over time can have a positive impact in your life.

Whenever you’re struggling to go to the gym, resist temptations to eat junk food, or overcoming the difficulties of learning a new skill, use the 10/10/10/ Rule to think not only about how you’ll feel about it later today, but also years from today.

2. True Fans

Relationships

“A True Fan is defined as someone who will purchase anything and everything you produce. They will drive 200 miles to see you sing. They will buy the super deluxe re-issued hi-res box set of your stuff even though they have the low-res version. They have a Google Alert set for your name. They are true fans.”
Kevin Kelly, Founder of Wired Magazine

Kevin Kelly is world famous for being a futurist, technologist, and the Executive Editor of Wired Magazine.

Amongst the many revolutionary school of thoughts that Kevin incepted, the 1,000 True Fans is definitely one of the most notable. The accessibility and distribution of information today empowers any artist, creative, or entrepreneur to make a real impact in their life and career by forming true fans (whether it’s 100, 1,000 or 10,000).

The point here is that instead of trying to please the mass, most of us will be far better off by making a few love us. While this mental model may be targeted at artists or entrepreneurs, it can be applied to pretty much anything that involves relationships.

Applying the model of True Fans to your current personal and professional relationships will help you rethink and optimize how you’re approaching these relationships effectively. Having the right person love you is often far more beneficial than having a hundred who’ve just heard about you.

1000-fans

3. Pareto’s Law

Being effective, not just efficient

“Focus on being productive instead of busy.”
-Tim Ferriss, New York Times Bestselling Author of The Four Hour Workweek

In anything we do, there’s always ~20% of activities that will deliver 80% of our desired results.

The origin of Pareto’s Law came from an Italian Economist, Vilfredo Pareto, who noticed that 80% of wealth and land were controlled by only 20% of the people. Today, this concept has been applied to business, health, expenditures, etc.

For example:

  • 80% of our expenditures come from 20% of sources (i.e. rent, mortgage, transportation)
  • 80% of our profits come from 20% of customers
  • 80% of our happiness come from 20% of people in our lives

pareto_principle

It’s easy to be wrapped up in ‘busy’ work without ever getting anything done. Pareto’s Law is a useful mental model to be more effective, rather than just be efficient.

4. Regret Minimization Framework

Thinking long-term

When Jeff Bezos, the CEO of Amazon.com, was facing the dilemma of leaving his steady job at a Hedge fund to start Amazon, he applied what he now calls the “Regret Minimization Framework.”

Here’s his explanation of the mental model:

“If you can project yourself out to age 80 and sort of think, ‘What will I think at that time?’ it gets you away from some of the daily pieces of confusion. That’s the kind of thing that in the short-term can confuse you, but if you think about the long-term then you can really make good life decisions that you won’t regret later.”
-Jeff Bezos, CEO of Amazon

While Suzy’s ’10/10/10 Rule’ focuses more on day to day short-term vs. long-term decisions, Bezo’s ‘Regret Minimization Framework’ is applicable for anyone making big jumps in their personal and professional life.

It could be leaving a job to start a company like Bezo’s, deciding to go live in another country, or even committing your life to someone else.

5. Eisenhower Matrix

Time allocation

“What is important is seldom urgent and what is urgent is seldom important.”
-Dwight Eisenhower

Dwight Eisenhower lived one of the most productive lives you can imagine.

Serving as the 34th President of the United States, he launched programs that directly led to the development of the Interstate Highway System in the United States, the launch of the internet (DARPA), the exploration of space (NASA), and the peaceful use of alternative energy sources (Atomic Energy Act).

It’s no wonder why his methods for time management, decision making, and increasing productivity has been studied by many people.

Out of the mental models Eisenhower used for smarter decision making, his most productive one was the Eisenhower Matrix.

The way it works is simple.

Whenever he was faced with a decision, activity, or task, he categorized it into one of four categories:

  1. Urgent and important (tasks you will do immediately).
  2. Important, but not urgent (tasks you will schedule to do later).
  3. Urgent, but not important (tasks you will delegate to someone else).
  4. Neither urgent nor important (tasks that you will eliminate).

eisenhower-matrix

According to Stephen Covey, the bestselling author of 7 Habits of Highly Effective People, we should be spending a majority of our time in #2: Important, But Not Urgent.

The most important activities that truly move the needle rarely involve putting out fires. Rather, it’s activities or decisions that involve strategic planning for the future — personally or professionally.

It’s just a matter of making time for it in our schedule, and the most effective way to make time for it is to Delegate (#3) or Eliminate (#4) the non-essential tasks.

6. Parkinson’s Law

Saving time

“Work expands so as to fill the time available for its completion.”

Willpower is finite. Some of us may have more than others, but it will always plateau over time.

This is Parkinson’s law.

Parkinson_s_Law_ee7455ec-1fc1-49f1-a3b9-56323078714c_large

If we’re given three hours to complete a task that normally would take an hour, we’ll find a way to fill those three hours. However, when we’re down to the final thirty minutes, we’re suddenly feeling the pressure to get things done.

This is a mental model that only you can apply yourself. It’s unlikely that your boss or organization will ask you to work less hours, which means you need to place artificial time limitations when you’re working.

Instead of giving yourself a week to complete a project, break it into smaller activities, and set multiple deadlines during the week to finish them.

Using restriction to your advantage will actually create more freedom for yourself, not less.

7. Circle of Competence

Doubling down on your strengths

“I’m no genius. I’m smart in spots—but I stay around those spots.”
— Tom Watson Sr., Founder of IBM

Throughout our lives, we’ve been told to fix our weaknesses instead of focusing on our strengths.

But when you study the most successful athletes, business leaders, and influencers, there’s a consistent mantra that’s preached — stick to your circle of competency.

“You have to figure out what your own aptitudes are. If you play games where other people have the aptitudes and you don’t, you’re going to lose. And that’s as close to certain as any prediction that you can make. You have to figure out where you’ve got an edge. And you’ve got to play within your own circle of competence.” -Warren Buffett

coc

It’s unlikely that you’re going to be the best tennis player in the world, as well as being an Oscar-winning actor. Success in anything takes an immense amount of discipline, sacrifice, and most importantly, time.
We can work to expand our circle of competence over time, but become self-aware enough to know where you stand today, and never be afraid to say “I don’t know.”

What are your mental models?

The more mental models we can refer to, the more likelihood of us making smarter decisions when it matters. We’ve given you our top 6, and we’d love for you to share any mental models that you’ve used to make better decisions.


This post originally appeared on Rype blog

via The Next Web http://ift.tt/2aXYIkf