BONUS: Ryan Jacoby on the 7 responsibilities of an innovation leader

Innovation is a topic that gets a lot of attention. There are innovation processes, specific creative games for teams to work with to seek innovative ideas. There’s the Lean Startup movement that tries to codify innovation-friendly processes, and there’s also the UX community pushing the argument that we need more innovation in software companies.

You’ve probably heard the same argument at work. We need to be more innovative to be competitive. Great! But how?

In this episode, we explore how leaders can set up their organizations for innovation. Ryan Jacoby helps us explore the how of that critical question: how can we be more innovative?

Ryan has written a book titled Making Progress – The 7 Responsibilities of an Innovation Leader to describe how organizations can focus on enabling innovation in practice.

The first action you, and your organization need to take

Ryan describes an approach that aims to focus on the team and organization on the customer needs. His approach is simple and immediately actionable. First start by jotting down in plain language and from the point-of-view of the user/customer: what problems are you trying to solve for that customer? Select the top 3.

The other dimension of innovation is your organization’s goals. Define what it means to meaningfully grow the impact of the organization over 6 to 18 months. This growth could be in the number of customers, revenue growth, profit, etc.

Now you have the start of a growth strategy that is centered on customer needs and also directly linked to the company’s/organization’s growth. Next, we talk about innovation in practice.

The 7 responsibilities of an innovation leader

When it comes to putting innovation in practice, Ryan argues that there are 7 areas to take into account.

  1. Define progress for your organization, in other words: what is the impact you seek and the growth in that impact factor
  2. Set an innovation agenda by prioritizing the innovation problems to solve, user and customer groups you want to serve, nature type of innovation to pursue.
  3. Create support teams that build the product
  4. Cultivate the ingredients for success for innovation
  5. Giving great feedback to teams: prepare and setup the feedback moments so that teams can learn quickly.
  6. Inspire progress
  7. Reward progress (as defined in #1)

Ryan explains how he came to value these 7 responsibilities of an innovation leader by telling us his own story when he was responsible to help the New York Times grow their impact through innovative solutions.

Ryan’s book: lessons learned about each of the 7 responsibilities of an innovation leader

You can read more about Ryan’s work and find his detailed explanation of the 7 responsibilities of an innovation leader in his book: Making Progress – the 7 responsibilities of an innovation leader.

 

About Ryan Jacoby

Ryan Jacoby, is the founder of MACHINE, a strategy, and innovation company that helps its clients Think Big and Act Small.

MACHINE clients over the years have included people responsible for growth and innovation at The New York Times, Marriott, Viacom, Etsy, Google, Nike, The Washington Post, Feeding America, Fresh Direct, NBC Universal, and The Knight Foundation.

Prior to founding MACHINE, Ryan led teams and relationships at the design and innovation firm IDEO. He was a founding member and location head of the IDEO New York office and built the Business Design discipline at the firm.

Ryan is also the author of the book named “Making Progress” with Sense and Respond press. A book he describes as “a tactical guide for you, the person charged with leading innovation”

You can link with Ryan Jacoby on LinkedIn and connect with Ryan Jacoby on Twitter.

For more on Ryan Jacoby’s work, visit his company’s site at Machine.io.

Making Agile Retrospectives Impactful – A Visualization Tool by Jeff Campbell

This is a guest post by Jeff Campbell, author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook)

Visualizing Continuous Improvement

I am a big believer in continuous improvement, weather that be in the form of Retrospectives, a Kaizen approach, or something else that helps the team reflect regularly. But for the earlier years of my career as a Scrum Master I found myself frustrated by a lack of improvement despite all this reflection (retrospectives that have no impact…).

Often,what I was seeing was that we talked about the problems the team was facing, and then didn’t follow-through with the actions we agreed to take.

When we tried to change our behavior. We might have succeeded for a day or two and then would forget about it. This isn’t continuous improvement this is just continuous discussion!

We need a good way to make sure we are actually making the change we set out to make!

Continue reading Making Agile Retrospectives Impactful – A Visualization Tool by Jeff Campbell

Why Agile frameworks fail and what to do about it: #ToolsOverFrameworks, the context-aware solution

4 minutes read

I have worked at many organizations that were trying to adopt Agile using a framework as the starting point. SAFe, LeSS, or even Scrum were the frameworks of choice.
Scrum, for example, is a very simple framework. It stands to reason that it would be easy to adopt and therefore benefit from the value that Agile brings. Or is it?
If we look deeper, Scrum is a collection of patterns or thinking tools. The daily meeting pattern, the time box pattern, the single owner of the requirements pattern, etc. There are many patterns that were considered when creating Scrum, and together they form what we know as the Scrum framework.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy. The Scrum Theatre many teams play attests to that fact. Using a framework is a problematic approach for Agile adoption because it assumes a prescriptive solution would help us tackle agile adoption. However, Agile adoption is a problem that requires constant evolution and changes.
As the Agile community, the problem we face is that Scrum (and other frameworks) did not make Agile adoption easy.
We need a different approach. One that builds on what we’ve learned from others (books, podcasts, conferences), but also that adapts to our context and the specific reality we live in.

The patterns we’ve seen working before, fail later on

When we work with different teams, we start to get a “feel” for what works, and what doesn’t. We try to apply the same ideas to another team, and then start to understand what consultants mean when they say “it depends…”

When we work with different teams, we start to get a “feel” for what works, and what doesn’t.

For example, the star-fish retrospective may work great for one team, but it just bombs when we use it with another team. That’s ok. Nothing works all of the time. The good thing though, is that there’s always something that works, we just need to know what it is.

The solution is not a process or a framework, it’s a toolbox!

Having worked with many teams, I’ve come to value a few tools that I try to use often. Some retrospective formats are one example of that. But not every retrospective format will work, so I’ve collected over time a large set of “thinking tools” or retrospective formats that I use depending on the context.
As a Product Owner, I’ve successfully used Backlogs. But in some teams Backlogs get abused and create the “slave to the backlog” anti-pattern. With those teams, I’ve been using Impact Mapping and Story Mapping instead. Different situations require different tools. The challenge is collecting a good and large enough toolbox, and the stories to go with it.
Stories, when attached to a tool, help us define where the tool will work, and when it might not. Stories are our “labels” for tools.

Collect tools, not frameworks

No doubt you will be part of teams using different frameworks: Kanban, Scrum, Extreme Programming or Scaled Agile (SAFe), Large Scale Scrum (LeSS), etc.
Don’t fight the framework! Instead, use concrete tools that help you progress and achieve your goals.
As Agile Coaches, Scrum Masters, Product Owners and Team Members, we should be collecting tools, not frameworks. Our goal is to deliver something valuable to our customers/users, not be good at SAFe, Scrum or some other framework.

How we collect tools

We collect tools and stories by sharing our experiences, and listening to those that have solved the problems we are facing now.
For a while I’ve been collecting challenges and tools that product developers use to solve their most important challenges. I’ve collected those in the form of workshops that tackle specific types of problems.
In the #NoEstimates workshops, I share tools and techniques that have helped me and many others deliver on time. Sometimes you can’t fight the deadline. If the product must be out for Christmas, you just deliver. Period. How? That’s what we tackle in the NoEstimates workshop: tools, techniques and thinking models that help deliver on time. These tools are context specific, they come with stories and we practice those in the workshop. Click here to find out more and join the next #NoEstimates workshop.
In the Product Owner Success Toolbox workshop, we review, and practice tools that have helped teams deliver products and services that have a market impact. Impact for the users, customers and also the companies we work with. The biggest waste is that of human potential, with these tools we build our Product Ownership toolbox, and tackle the biggest challenges people have faced when trying to define and deliver products with market impact. Click here to find out more and join the next Product Owner Success Toolbox workshop.
In the Agile Strategy workshop (still in alpha, contact me to know more), we tackle the biggest challenges that companies have faced aligning the teams, and focusing larger number of teams on concrete value for the customers and the organisation. The Agile Strategy workshop collects tools related to funding of work, strategy definition, product strategy, strategy deployment, and progress follow-up at the organizational level. Email me to know more about the Agile Strategy Workshop.

Join the conversation

Have an opinion on the use of Tools vs. Frameworks? Join the conversation on Twitter/LinkedIn with the hashtag #ToolsOverFrameworks

BONUS: Jeff Campbell shares his favorite Actionable Agile Tools for Scrum Masters

Scrum Masters understand the importance of having many tools for different situations. The quality of our work is often related to the quality of the tools we have in our toolbox and the context in which they work.

In this episode, we review some of Jeff’s favorite Actionable Agile Tools, a book that collects 19 tools and is now available on Amazon in black and white as well as full color. Not to mention Kindle!

A short, practical and inspiring book

Continue reading BONUS: Jeff Campbell shares his favorite Actionable Agile Tools for Scrum Masters

BONUS: Tim Herbig on Lateral Leadership a critical skill for Scrum Masters and Product Owners

Tim was faced with a problem. How to be a leader without any formal power. All Scrum Masters and Product Owners who have felt the responsibility, but not any “line authority” have faced the same problem. You need to help move the project along, but you can’t tell people what to do!

In this episode we explore the concept of Lateral Leadership how it can help you as a Scrum Master or Product Owner.

Tim Herbig is the author of Lateral Leadership a recent book published by Sense and Respond Press.

Continue reading BONUS: Tim Herbig on Lateral Leadership a critical skill for Scrum Masters and Product Owners

Product Goal-Setting: How Scrum Masters can onboard a new or beginner Product Owner

Photo by Mohamed Hassan @ Pixabay

Why do we have daily meetings? Why do I need to be involved with the team every day? Why can’t I just give you the requirements document and concentrate on other tasks?

This blog is part of Module 2 of the Coach your Product Onwer v2.0 video course.

The Anti-Patterns When A Product Owner Is New To The Team, The Product And To Scrum

These are just some of the questions that Product Owners that are new to Scrum will ask. But sometimes we need to onboard Product Owners that are new to Scrum, new to the Product and new to the team. That’s not an easy task.

The Product Owner may not have any technical knowledge of the product or the understanding of the business the product supports. When a Product Owner is new to the team, and the collaboration habits have not yet developed. For example, he may be tempted to just go away and write all the User Stories in isolation or with a Business Analyst, and never involve the team. Which later leads to the “tell the team what to do, and disappear” anti-pattern. Continue reading Product Goal-Setting: How Scrum Masters can onboard a new or beginner Product Owner

How to help the PO be involved with the Scrum team, even if the PO does not have time

The Product Owner (PO) is a tough role to fill. Product Owners are torn between users, senior management, team and other stakeholders that they need to attend to.
While the team is working on completing the backlog items, the PO is probably meeting with the Director of Product to agree on a roadmap; with the CEO to hear about the latest ideas he got from visiting a client; trying to meet with the user research group to understand better the customer; reporting status to the head of Project Management; and still needs to visit the Sprint Planning, Backlog Grooming, Demo and the occasional daily meeting to answer questions from the team. And let’s not forget the email backlog!
With all of these tasks one has to ask: do we believe a single person can do this all alone? What I describe here is not even rare! We seem to collectively think that the Product Owner is a super-hero!


Given all of these tasks, it is little wonder that the PO’s end up struggling to even manage the JIRA tickets the teams ask them to review, give feedback on, and prioritize.

The feeling of overwhelm is common in Product Owners. They ask themselves if they are spending their time on the right things. Wouldn’t you, if you got constantly interrupted by questions and requests from others? How do we solve this, increase collaboration between Team and Product Owner, and improve our work place at the same time? Read on for more…
Continue reading How to help the PO be involved with the Scrum team, even if the PO does not have time

20 TOP Agile Blogs for Scrum Masters that you will not (easily) find on google searches (2017 edition)

Before reading the post, I wanted to share with you a great interview about how we, as Scrum Masters are always starting from Scratch (just like new year! 🙂 Here’s a Podcast episode as a new year gift from the Scrum Master Toolbox Podcast archive built over the last 3 years interviewing Scrum Masters from all over the world.

Podcast Topic: We start a new with every team  (interview with Lucian Stroie)

Now for the list! 🙂

Here in the Scrum Master Toolbox Podcast, we share insights and inspiring stories from Scrum Masters every day of the week because we believe we need inspiration and ideas every day. Therefore we also visit sites and blogs for the same reasons. To end the year with a bang, I wanted to create a list of Top blogs / Sites for Scrum Masters. Was I in for a disappointment… read on to know why…

Continue reading 20 TOP Agile Blogs for Scrum Masters that you will not (easily) find on google searches (2017 edition)

5 tools every Scrum Master should be familiar with on coaching, managing conflict and more

Minnesota State Capitol Woodworkers Toolbox Historical SocietyAs Scrum Masters we deal with many dynamics and problems in the organizations we work with. That’s why, here at Oikosofy, we’ve been building a mini-library for you. In this post by Vasco Duarte, we explore 5 tools that every Scrum Master should be familiar with. We cover the following toolboxes:

  • Stakeholder Management
  • Team Motivation
  • Conflict Management
  • Product Owner Collaboration
  • Continuous Improvement

And in today’s live Facebook event for Scrum Masters we will discuss these tools and answer questions on the tools we have described on that post.

If you can’t join us on the Facebook live event for Scrum Masters, don’t worry. We will be making a recording available. Just sign-up below to make sure you get notified when it is available.


Photo credit and copyright: By Minnesota Historical Society [CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

Jason Little on many tools to measure our success as Scrum Masters

There are many tools that can be used to measure our success as Scrum Masters. Jason shares some of the tools he uses as well as his approach to success.

About Jason Little

Jason Little helps organizations discover more effective practices for managing work and people. Sometimes that means plucking tools from the Agile world and sometimes that means using more traditional management practices, such as The Rockefeller Habits. Jason is passionate about the people side of change, and focus on bringing meaningful change into organizations that will improve the lives of people. Jason has recently released a new book called Lean Change Management: Innovative Practices for Managing Organizational Change.
You can connect with Jason Little on Twitter and link with Jason Little on Linkedin.
Jason Little is also a funder of Happy Melly.