Category Archives: Agile Management

Top 10 Secrets of Agile Transformation with Michael Sahota

Learn more about transforming people, process and culture with the Real Agility Program

I dutifully watch Scrum Alliance’s webinars whenever they offer something I want to learn about, so I recently attended Michael Sahota’s “Top Ten Secrets of Agile Transformation.”

Sahota is a bit of an Agile guru, and well-respected in the community. He founded the Toronto Agile Community, and can be seen at Scrum Alliance gatherings everywhere. He also facilitates a Certified Agile Leadership course. You can learn more about Sahota by going to his website www.agilitrix.com.

The webinar he conducted was fascinating, because by the time he went from #1 to #10, I realized his “secrets” were very simple, and that one could start with #10 and work backwards to #1 and learn the same things.

By simple I mean his points were clearly articulated and comprehensive.

Before enunciating his secrets Sahota started with the idea that “Culture is the #1 Challenge with Agile.” He asked, “What are we (agilists) doing to create resistance to a change of culture in an organization?” Mindset, he averred, is more important than the practice of Agile – by which he referenced creating safe and trusting relationships, engaging with others, promoting continuous learning, innovation and so on. On a continuum line with “practices” on one end and “mindset/culture” on the other, he urged practitioners to find a balance between the two.

And now for the count-up:

Secret #1 – Clarify the purpose of bringing in an Agile coach by asking “why?” Usually the answers have to do with improving the quality of a product and encouraging more collaboration.

Secret #2 – Focus on organizational goals (and drop the word “Agile”). If the goals are clear, as those articulated above, one can drop the Agile initiative and try another. Agile is not the goal, but focussing on doing and being Agile can set up the wrong expectations. You may say, “Of course we will likely use Agile to help us achieve the organization’s goals,” but remember that Agile cannot be the goal!

Secret #3 – Focus on growth (and drop “transformation”). The idea of transformation is that it is a painful process. It also implies an end point: one is transformed. The idea of growth is more natural, and transformation is really about creating healthy change and growth. It is ongoing.

Secret #4 – Increase awareness of the global context. Global trends mean that an organization must be growing to survive. A lot of organizations do not know how to read their engagement surveys, or don’t even have them. People’s talents are wasted when engagement is low, which leads to massive financial waste. Millennials demand change – will not seek to work in an organization that’s regressive or stagnant. An agile enterprise is resilient and anti-fragile. How well is an organization set up to thrive in the future?

Secret #5 – Increase awareness of organizational context – what’s happening in an organization? However, resist telling leaders that their organization is broken. Start with humility and compassion, and then show leaders that there is a lack of engagement by their members by reading the survey. It’s not about blame – have the leaders acknowledge this and say what they want to do about it. What difficult conversations are needed here? The coach must stand in the truth of what’s happening, listen and understand. Be real.

Secret #6 – Clarify the focus of the initiative. Is more time spent on tactical initiatives (as in, how do we work?), in strategic initiatives (what do we want to achieve?), or in cultural concerns (who do we want to be?)? Discuss what percentage of time is needed to spend on culture in order to have a bright future.

Secret #7 – Build a shared understanding of what culture is. Culture has to do with both consciousness (or energetic property) and structures. Consciousness includes identity, values, beliefs, and the unwritten rules and norms in an organization. It includes values such as safety, trust, people being valued… Structure (practices) and consciousness (culture) co-exist together and are inter-dependent.  Refer to the Agile Manifesto: people over process. – focus on structures without consciousness cannot succeed.

Secret #8 – Clarify the leaders’ role in growing. The consciousness of the leadership is most important. New organizational behavior requires new leadership behavior. Growth requires leaders go first! How do we invite them to go first?

Secret #9 – Honour the leaders’ freedom to choose. Do they wish to work on something tactical? Cultural? A coach must let go of what he or she wants. We cannot coerce people into believing what we believe.

Secret #10 – Growth can happen anywhere.You, as an individual, are the limit for growth.

Sahota suggests creating a culture-bubble in which consciousness and safety can be grown. In this last point he quotes Gandhi: “Be the change that you want to see in the world.”

I am aware that in the 45 minutes of the webinar, Sahota went through each point relatively quickly. Each one in itself provides room for reflection. For me, the fact that the tenth “secret”

puts the onus on each individual to grow is telling; if we change, we can help those around us in their transformation. But that requires extra-consciousness, I think, and humility. Overall, Sahota points to values and culture within and without as the key.

Michael Sahota is offering his Certified Agile Leadership class in the new year through BERTEIG – you can find dates at this site: http://www.worldmindware.com/Certified_Agile_Leadership#schedule


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

CLEAR Servant Leadership

Learn more about transforming people, process and culture with the Real Agility Program

Sun rising over field - servant leadership

I facilitated this workshop today for a senior leadership team. I mostly employ famous quotations familiar to many to provide a brief overview of Servant Leadership as well as a learning framework for systematically building capacity in others while improving the systems in which they work. The folks in the workshop seemed to really connect with Scott’s CLEAR model (not so famous but ingenious in its deceptive simplicity). I offer it as a guide for designing CLEAR acts of leadership.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

9 Common Mistakes in Hiring an Agile Coach

Learn more about transforming people, process and culture with the Real Agility Program

Nearly everyone is hanging out the “Agile Coach” shingle.  Agile has reached the point where many large organizations are adopting Agile practices.  As a result, consultants and consulting companies are trying to jump on the bandwagon to take advantage of this fad.  Unfortunately, we at BERTEIG are often being called in to clean up after other Agile coaches have made a mess of things.

Here are the most common mistakes that organizations make when hiring Agile coaches.

1. Not Measuring the Results of Your Agile Coach

Agile coaches should be able to measure their results as they work with your teams and your organization. Important measures include performance, cost, quality, time to market, customer satisfaction and others.  If you aren’t measuring results, you can’t possibly know if the money you are investing into your Agile coach is worth it.  Of course, some qualitative measures such as staff satisfaction with the coach are useful too, but quantitative measures are also essential.

2. Not Benchmarking before an Agile Coach Starts

You need to be able to know if an agile coach is making a difference. Knowing where you are starting is necessary.  Having benchmark measurements of important KPI’s will help you to make sure that your agile coach is successful.  Benchmarking is something that your agile coach should be able to help you with, but make sure that you are involved directly!

3. The Agile Coach is Lacking Advanced Certifications

Agile coaches need to have proven their knowledge and experience by obtaining advanced certifications. A “Certified Scrum Master” designation is just not sufficient. At a bare minimum a Certified Scrum Professional (CSP) or Kanban Management Professional (KMP) certification are critical. However more advanced certification’s such as Certified Enterprise Coach (CEC), Kanban Coaching Professional (KCP), or even non-Agile coaching certifications such as Leadership Circle Profile are important to see in a candidate.

4. Lack of Diversity of Agile Experience

An Agile coach must be able to prove having worked with at least Scrum and Kanban methods on more than one team in more than one organization.  However, there are many other Agile methods and techniques, and it is critical to explore the depth of your candidate’s knowledge and experience with those techniques.  Do they know how to do the Agile engineering practices?  Have they used many different retrospective techniques?  What about Innovation Games?  Estimation and planning tools?  If your coach has less than five years of experience with Agile techniques, chances are they don’t have the depth to deal with the complexity of your situation.

5. No Huge Agile Coaching Failures

An Agile coach needs to be able to explain how they have failed to achieve results in at least one case, ideally getting fired as a result. Failure and learning from failure are critical parts of the Agile framework. If an Agile coach can not share with you a significant failure then you cannot trust that they are able to learn from their mistakes.

6. No Systematic Agile Coaching Approach

Helping teams, groups and organizations become more Agile requires systems thinking and systematic approaches.  Organizations are complex (and sometimes chaotic!) – if an Agile Coach does not know how to deal with this complexity, and cannot describe to you their systematic approach, then they probably aren’t going to be consistent in their results.  And if the approach they describe doesn’t seem to make sense to you, you are probably right to give that coach a pass.

7. Missing Clear Agile Coaching Goals

This mistake is a little less common, but it is important enough that it still needs to be mentioned: your organization absolutely must have clear goals for the Agile coaching.  Those goals should be related to both Agility and business results.  Agile techniques are a means to an end.  Lacking clear goals often results in an organization spending far more than it needs to on Agile coaching.

8. Hiring an Agile Coach to do Training

(Or the other way around.)  Coaching and training are two completely separate disciplines!  It is rare to find an individual who is able to do both well.  The systems and techniques of coaching are different than those of training.  Becoming excellent at one, takes many years of focused work.  Becoming excellent at both, takes deep commitment and opportunity.  If you hire an Agile Coach who has good experience, don’t just assume that they can do training just because they have delivered a few talks or made up a slide deck.  Put the same discipline into hiring an Agile trainer that you would put into hiring an Agile coach.

9. Not Letting Leaders and the Agile Coach Work Together

This is probably one of the biggest mistakes of all!  An Agile coach must work with your organization’s leaders to have any hope of helping you with lasting change.  No matter how large your organization, the culture is set by leadership, Agile has a huge cultural impact, and your Agile coach needs to be able to link the two together (leaders and Agile culture).  Even if the Agile coach is “just” working at the team level, a lack of contact with leaders will make the coaching work inefficient, frustrating, and unsustainable.


Your organization deserves the best chance it can have.  Consider contacting us at BERTEIG to help you make sure your Agile coach (or Agile coach candidate) is up to the challenge.   We have a systematic program to develop Agile coaches.

BESTEIG Real Agility logo - Agile Coach development program


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Doc Norton introduces Host Leadership at 8th Annual Toronto Agile Confernce

Learn more about transforming people, process and culture with the Real Agility Program

“Sometimes we get so caught up in what should be that we miss the beauty of what is.” – Doc Norton

At the 8th Annual  Agile Conference, held in Toronto, Ontario last week, the keynote speaker Doc Norton presented some insightful ideas on Host Leadership, about the roles people take when initiating, launching and facilitating new ideas. The basic premise of having a Host Leader mindset is to be fluid with the needs of the environment. While there is a time and place for authoritative decision-making, otherwise called gate-keeping in Host Leadership lingo, there is also a need for a humble approach to supporting an idea from conception to fruition without clinging to hard-and-fast expectations about what must happen.

In his example of applying these principles, he shared how his family decided to host a Euchre game to create an opportunity to meet new neighbours. When something different than expected emerged, he experienced the value detaching from “what he wanted it to be” and accepting “what was becoming.”

In brief, here are the 6 key aspects of Host Leadership.

  1. Initiator – The person that provides the initial spark. A new idea.
  2. Inviter – Extends the invitation to people who may be interested in the idea. Who to invite and who not to invite.
  3. Space Creator – Those who create the physical and emotional space for those in attendance to feel safe, to learn, and to engage in the opportunity.
  4. Gate Keeper – Defines and protects the space which is created. Lets people in and out as necessary or appropriate. People who enforce the rules, doing interviews and hiring.  Note: there is a right balance for this where there is not too much gate-keeping but just enough to create the right boundaries.
  5. Connector – Brings people together. They are conduits for information. They are typically the ones who know how things get done.
  6. Co-participator – Team leads participating in a retrospective as equals.

Sometimes the Host Leader sets and reinforces rules, but sometimes they serve others. This depends on the moment and context. 

Doc Norton laughed at his own story when he revealed that even though he and his wife put lengthy effort into creating “Euchre Night” he discovered that in the basement a large group of guests started playing poker. Rather than becoming disgruntled about the change, he adapted and became a co-participator. As a result of letting what was becoming just be, the neighbours found themselves carrying out Poker nights monthly for a decade.

Host Leadership is about creating space for great things to emerge and surrendering the inclination to control the outcome.

These six items are aspects of roles of everyone on a team and shouldn’t be thought of as one person per role per team. Instead, when people on a team ebb and flow around these roles the thought-processes and discoveries can be shared with the team, and the growth on the team supports the initiatives for team members.

What were his concluding words of wisdom to the audience?

He said, “Consider your leadership role at work. Regardless of your title, think about what you are initiating. How do you extend invitations? What space are you creating and maintaining? When are you gate-keeping? How are you connecting with others? How are you joining what is emerging even if it is different than what you expected?”

 The take away from this inspiring opening address was the optimistic message that what is becoming may be better than anything anyone could have hoped for. 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Communicate the Vision for Change

Learn more about transforming people, process and culture with the Real Agility Program

Leading an organization to Real Agility requires that you communicate the vision for change throughout your organization.  This video introduces the four key concepts of communicating this vision for change as you and your executive team lead your organization to Real Agility.

The video presents four core concepts:

  1. Continuous communication at every opportunity: every meeting, every phone call, every email, every presentation!
  2. Simplicity of the message: short, jargon-free, concrete.
  3. An emotional component that encourages a change in behaviour.
  4. And urgency!  (A window of opportunity, a competitive threat or an internal problem that needs to be addressed now.)

Leading to Real Agility References

Here are some additional references about how leaders can help their organizations move towards Real Agility by communicating the vision for change:

Please subscribe to our YouTube channel to receive notifications when each new video is published! (There are 15 more videos coming in this series, and more beyond that on other topics!)  You can also find the summary article that helps you find all the videos and additional references here: Leading to Real Agility – Introduction.

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BERTEIG Real Agility logo - leading to Real Agility


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Communicate The Vision

Learn more about transforming people, process and culture with the Real Agility Program

This video, newly released on BERTEIG’s YouTube Channel, reminds leaders of their responsibility to communicate the vision to their organization. Check out the 2-minute video for valuable insight into the process.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

14 Things Every Agilist Should Know About Kanban

Learn more about transforming people, process and culture with the Real Agility Program

untitled

So you are embarking on an Agile transformation. One important thing you need to figure out (and hopefully you have some consultants helping you) is how many Scrum Teams you will need for product development and how many Kanban teams you will need for operations, deployment, support, maintenance, keeping the lights on, etc. Because when you create a bunch of cross-functional teams they will have gaps in their Agile engineering practices and their definition of “done” will have to be limited by several organizational factors. The teams won’t have access to many of the environments and there won’t be enough specialized resources to assign to each team. Plus, the nature of the work coming into the ops and support teams are much more finely grained and varied than user stories in a Sprint Backlog and it’s important that the Scrum teams focus on their products and are not disrupted by every little change request from the business. So you need Kanban teams to do the work that the Scrum Teams can’t do yet as well as the stuff that you don’t want your Scrum Teams to be distracted by.

That’s more or less the popular consensus on the role of Kanban in the Agile community. Some acclaimed thought leaders have even written popular books and blog posts about it. But if one digs a little deeper, one finds that there is much more to Kanban than meets the common agilist’s eye (although clearly this is changing, evidenced by the existence of this piece of writing). So here are the 14 things that I can think of off the top of my head:

  1. The Kanban Method is not about transformation. At least not the radical, deep Satir J-Curve brand of transformation that has been attempted in many organizations. All too often with the radical approach, there is enough resistance to change and enough ensuing chaos for the leaders of the organization to lose patience with the change initiative before the system has a chance to recover.
  2. Moreover (and dangerously), many so-called champions of change are not aware that Satir was a psychotherapist and that her J-Curve method was employed to change the identity of her clients, breaking them down and building them up again. What’s important here is that Satir was a psychology professional working with willing clients to help them transform into the people they wanted to be. This is not the case with most professional knowledge workers. Knowledge workers tend to not be seeking this kind of service from managers and coaches. A more brutal version of this technique has been employed to transform teenagers into deadly soldiers.
  3. Instead of deep J-Curve transformation, the Kanban Method proposes small, rapid J-Curve experiments. This approach to change provokes less resistance, avoids extended periods of thrashing in chaos and the severe testing of leadership patience. Well-designed small J-Curve experiments produce just enough organizational stress to stimulate change without drop-kicking people into deep chaos and despair and forcing the regression of an organization to lower levels of trust and maturity.
  4. The Kanban Method is a management system for the design and evolution of the interdependent services of an organization. Such services are often composed of several Scrum Teams, shared services, managers, senior staff and specialists and are often themselves served by other services. Every service is delivered via a system of stages of knowledge discovery (rather than hand-offs). See more on this here.
  5. The design of a system determines the fitness for purpose, flow of value and quality of the service (as demonstrated by Deming’s Red Bead Experiment). It’s not about high-performance teams. It’s about the performance of the system.
  6. Transparency of the system empowers knowledge workers to self-organize around the work because they understand the system and are trusted to know what to do in order to deliver the service.
  7. Kanban managers are systems managers, not people managers and not coaches.
  8. Team-level Kanban is actually a form of proto-Kanban—still Kanban, but in an immature state, an incomplete rendering of a service delivery system.
  9. A Kanban system is a pull system. The capacity of the system is calibrated for optimum flow. New work enters the system when there is sufficient capacity to absorb the new work without overburdening the system and disrupting flow. Demand is balanced against capacity.
  10. All demand is potentially refutable. When there is capacity in the system to start new work, sources of demand collaborate to determine what is the most important work to start next and the system is replenished.
  11. Deciding what to start next is based on economics—transparent and rational risk assessment.
  12. Once the system is replenished and there is a commitment to deliver the newly-started work, risks are managed with explicit policies such as classes of service, work-in-process limits, pull-readiness criteria, feedback loops and relevant metrics (i.e. not team velocity).
  13. Average lead time from project or feature commitment to completion is a basic metric. Improving the system results in a reduction in both lead time and lead time variability. Delivery forecasts are based on historical lead time data. Deadlines are also managed with lead time data (i.e. deciding when to start something).
  14. All of the above is the responsibility of management. This should leave little management capacity for monitoring individual performance and story point velocity of teams (white bead count). A sign of a mature Kanban system is that managers have improved their behaviour and are focused on improving the system and that knowledge workers are free to self organize around the work as skilled, adult professionals.

If you are interested in the history of the Kanban Method, start here.

Best starter book: Essential Kanban.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Leader Responsibilities

Learn more about transforming people, process and culture with the Real Agility Program

Leading an organization to Real Agility is a complex and difficult task.  However, the core responsibilities of leaders attempting this are simple to describe.  This video introduces the three core responsibilities of the senior leadership team as they lead their organization to Real Agility.

The video presents three core responsibilities:

  1. Communicating the vision for change
  2. Leading by example
  3. Changing the organization

Future videos in the series will elaborate on these three core responsibilities.

Real Agility References

Here are some additional references about how leaders can help their organizations move towards Real Agility:

Please subscribe to our YouTube channel to receive notifications when each new video is published! (There are 15 more videos coming in this series, and more beyond that on other topics!)  You can also find the summary article that helps you find all the videos and additional references here: Leading to Real Agility – Introduction.

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BESTEIG Real Agility logo

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Introduction

Learn more about transforming people, process and culture with the Real Agility Program

Leading an organization to Real Agility is a complex and difficult task.

Leading to Real Agility is about how leaders including executives and senior managers help their organization achieve great business results and a great corporate culture. This video introduces the topics of our next series of videos.

This is the first video in a series on Leading to Real Agility.

Leading to Real Agility

The following topics will be covered in the video series.  A new video will be posted every two weeks.

  1. Leadership Responsibilities – what must leaders do to inspire change.
  2. Communicate the Vision for Change – how leaders can craft a compelling vision for change.
  3. Lead by Example – the actions of leaders matter.
  4. Change the Organization – the primary work of leaders.
  5. Environment for Change – hindering and helping change.
  6. Real Agility Practices – how do leaders and their staff work?
  7. Choosing a Change Approach – options for changing your enterprise.
  8. Leadership and Culture – what do you need to know to change culture?
  9. Change Adoption Curve – when do people adopt change?
  10. Leadership Time Allocation – a major benefit of improvement.
  11. Handling Resistance and Laggards – leading sometimes means pushing.
  12. Choosing a Pilot Project – some projects are better than others when you’re starting out.
  13. Real Agility at Scale – if you have a big organization.
  14. Organizational Agility – having wholeness and integrity throughout.
  15. Individual Leadership Development – a leader’s personal journey.
  16. Assessing Your Organization – where are you right now?

Please subscribe to our YouTube channel to receive notifications when each new video is published!

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BESTEIG Real Agility logo

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Product Owner Training: Reflecting on Agile in Community Settings

Learn more about transforming people, process and culture with the Real Agility Program

 

rachelheadshotThe Certified Product Owner training I attended recently has me reflecting on when I first heard about Agile.

My introduction was in 2012 on one of those really cold, dark wintery nights in the now-famous Fort McMurray, Alberta.

Garry Bertieg had invited me to consult about a challenge we were facing in a community development initiative. I remember it being so cold and dark I didn’t want to leave the house. But I was curious about what innovative team-building technique he wanted to share so I went to check it out.

We weren’t dealing with a business issue. And it wasn’t tech-related. But it was complex and it dealt with many groups, many individuals, and many Institutions. He felt Agile methods could help.

He presented some basic concepts from OpenAgile. He had a large poster board, sticky-notes and Kanban-style columns showing how items can move across the board while in progress on the way to        “done”.Learning Circle - cropped He also presented the Learning Circle Model. I just made so much sense to me instantly. He remarked that he was surprised to see me so receptive to the material so quickly. It just made so much sense. This Learning Circle has formed the foundation of how I work ever since.

It was as though it combined the best of everything I had experienced in teacher’s college, in community development and in serving in community-level leadership roles for a decade.

I started applying what I learned from that 3-hour session immediately and I saw the results instantly.

 

At the time, I was operating independently, so I didn’t have a manager to run anything through, and I was running a neighbourhood children’s class, responsible for supporting more than a dozen volunteers, teachers, and other coordinators. The OpenAgile model was a perfect fit and I attribute a lot of the success of that neighbourhood class to the framework within OpenAgile.

At the time, I knew nothing of Scrum, Kanban or even the way Agile first evolved from IT software development. I didn’t know any of that. But I started working with Agile methods then and continued until now.

Certified Product Owner Training Took My Understanding To a New Level

Last week I had another agile-style life-changing experience in the Certified Scrum Product Owner training lead by Mishkin Berteig & Jerry Doucett.

I entered the class with an open mind, willing to learn, and eager to apply the learning in whatever ways are applicable in my current circumstances.

At a very foundational level I gained a new understanding and appreciation for the role of the Product Owner in creating the product backlog. I understand that is key.

I also enjoyed the simulation exercise of creating a product. The team I worked with at the table was excellent and worked so well together. At one point, we made this Product Box which demonstrated our vision for our product.Product Owner Simulation - Product Box Example

It was extremely valuable to also understand the way the Product Owner collaborates with  the Scrum Master for the best possible results.

Since I am not currently working with a Scrum team, there are some parts of this learning which are not immediately applicable.

However, the training was exceptional and I came away with a much more thorough understanding of the Product Owner’s role as a whole.

It was a phenomenal experience with an excellent facilitator team.

I’m enjoying the opportunity to learn more and more about positive ways organizations are changing every day, both inside and outside of corporate environments.

 

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: The Mythical Product Owner

Learn more about transforming people, process and culture with the Real Agility Program

“When product managers weren’t looking, developers went agile.”

This quote from Barbara Nelson gave me a chuckle. I found it when reading The Mythical Product Owner, by Andre Kaminsky and discovered that this article gives excellent insight into the role of the product owner.

Andre speaks to the change happening in an organization when they adopt agile and breaks it down into bite-sized bits which really helps conceptualize the shifting happening across the industry.

He describes two key levels of change, mainly that:

Change must happen on two levels across the organization:

  • Technical – Roles and responsibilities must be understood, accepted, and adopted.
  • Cultural – Attitudes, expectations, political ambitions, and how we collaborate must change.

He writes that agile should not come in with a “big bang” approach but by introducing it in a gradual manner, allowing confidence and capacity to build, then the results can be more profound and long-lasting.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Scrum Alliance newsletter lists Mishkin’s article

Learn more about transforming people, process and culture with the Real Agility Program

In a recent newsletter from the Scrum Alliance, Mishkin’s article about enterprise leadership is listed as a resource.

Search all posts for:

 

View all (37) posts »

REAL AGILITY – SELF-ORGANIZING TEAM CREATION EVENT FOR LARGE-SCALE AGILE ENTERPRISES

Posted By Meghan Robinson, Tuesday, August 16, 2016

 AUTHOR: MISHKIN BERTEIG

In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams.  It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment.  The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective.  They were functional teams (e.g. a team of testers).  But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration.  So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team.  Everyone was involved – all the people who would be on the teams were in the room.  Those teams stayed together with the same membership long after that meeting.

The rest of the article can be read here.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quotable Quote: The Right Attitude

Learn more about transforming people, process and culture with the Real Agility Program

Jerry Doucett 201601 white background - head - 275 square Mutual respect and caring are the cornerstone to the team’s success and it needs to be integral to their culture and beliefs.  Not just saying but living the belief there are no heroes or scapegoats.  Everyone, including the business, executives, team members and leadership must collaborate and share in celebrating the successes as well as accepting responsibility for setbacks and failures.

Everyone must have the right attitude and commit to not only DOING as needed by attending the ceremonies or following the process and practices but truly wanting to BE part of the solution by willingly changing the way they think, work and collaborate. (Senior Agile Coach Jerry Doucett)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quotable Quote: Whole teams should receive common education experience

Learn more about transforming people, process and culture with the Real Agility Program

Jerry Doucett 201601 white background - head - 275 squareTo ensure consistency and a shared understanding, whole teams (including the business, IT, and their leadership of executives and managers) should receive a common skills development and education experience in proper Agile Thinking, the Scrum Framework, aligned practices and mindset training.  Coaching should then reinforce this new knowledge and encourage appropriate behaviours to turn these new practices into habits.  Indeed, learning should be a continuous cycle and endless journey towards excellence, and Scrum leverages this through frequent retrospection and continuous improvement.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Advice: Start Executing With Little Planning

Learn more about transforming people, process and culture with the Real Agility Program

Agile Planning

“Start executing and worry less about planning.” QA Consultant

This statement appeared on a recent feedback form after a BERTEIG learning event. It summarized a Quality Assurance Consultant’s learning from the CSM training they attended.

This statement so accurately summarizes one of the key principles of agile methodology which is to do minimal planning and review often. It doesn’t mean “No Planning” it just means different kinds of planning and the willingness to jump quickly into action.

Mishkin published an article on this topic in 2015  and it is re-posted here now because it is still so relevant today.

 

Agile Planning in a Nutshell

Mishkin Berteig 201504 white background - 640w

 

 

 

By Mishkin Berteig

Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

Agile Planning Process

The steps to do this are actually very simple:

  1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
  2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning PokerThe Bucket SystemDot VotingT-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
    1. Estimating relative business value.  Usually done with the business people including customers and users.
    2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
    3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
  3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

  1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
  2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
  3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimation and planning.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail