Launching a New Product: #1 Question – Is this a Project or a Product?

Recently, it’s come to my attention that a friend is experiencing nearly insurmountable financial hardship. After initially offering to help out by sharing a few food items, I realized that a few items shared once is not enough. This inspired me to consider the idea of sharing food weekly. I decided to create a regular care package of sorts, until she got back on her feet again.

She agreed to pick up a care package from me weekly. And that’s how this social action initiative was born.

Once I knew I’d be doing this weekly, several logistics had to be sorted out. Where was the food coming from? Where would I store the food between pick-ups? When would it be picked up?

Interestingly, I don’t have enough food in my own cupboards to share with someone weekly. Fortunately, I know many others who are like-minded and highly value supporting and helping others so I began to reach out. Within days I had more than seven bags of food to share and it occurred to me that this would be my goal – 7 bags for 7 days. That should get her through the week.

It didn’t take too long for me to see that if I considered myself as the Product Owner of this product – a weekly food package – that there might be valuable Agile concepts and practices which could easily help support the sustainability of this initiative. 

Is this a Project or a Product?”

 

Immediately, an Agile Coach inspired me to think of this not as a project, but as a product. The main difference, he reminded me, is that a project has a start and an end. A product doesn’t have an end date. It can always improve.

At the beginning, I thought of this as a “project.” You know? A bunch of us getting together with the vision of sharing food weekly. It was our “Food Sharing Project.”

Before long, I realized that was an old way of thinking about work. When I thought about the food package as a product a lot changed. It became easier to see what was needed for this product to be useful to the recipient. The quality of this product became clear.

I also watched this video from Mishkin Berteig which encouraged me to think about the ways in which this package could be run with Scrum. (So far, I am the Product Owner. Now I just need a ScrumMaster and Scrum Team. You never know, maybe this will evolve some day!)

Then I read this article by Mike Caspar which got me thinking about acceptance criteria and the importance of consultation, reflection, learning and planning.

The key learning for me today is that when I think about this service of delivering a weekly care package as a product I see it’s likely it can continue indefinitely, always improving. That really excites me.

It is not a project, but a product and is being organized and delivered using Agile methods.

This is one way that Agile is being used outside of IT with great success.

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

14 Things Every Agilist Should Know About Kanban

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

Week-long Sprints Work for Weekly Newsletters

What I like the most about Agile-thinking is the principle of taking action with very little planning. This philosophy of learn-as-you-go creates space and time for the team to experiment with ideas to create a successful product.

For the past year, I have participated in an agile experiment of sorts. Basically, the goal was to write a weekly newsletter. But more specifically, the intention was to create meaningful content to readers of the newsletter which would empower them to continue to make positive change in their organizations by applying Agile methods.

Six weeks after starting the newsletter, I attended my first Certified ScrumMaster (CSM) training in Toronto, Ontario. At first, I thought I could manage the newsletter content and delivery using Scrum. I quickly realized I couldn’t. Even if I viewed myself as a ScrumMaster, I wasn’t working on a Scrum team. There was no Product Owner. It couldn’t be run using Scrum.

However, I realized something essential that I could glean from Scrum and that is the idea of Sprints. I realized right away that if I viewed the creation and delivery of the newsletter in one-week Sprints I likely could be successful. And indeed, this application of a Scrum method was extremely useful.

Thinking about delivering a newsletter in one-week Sprints helped me to think about the smallest amount of content which could be easily and predictably delivered weekly. As my capacity, and the capacity of the team improved, so could the level of complexity also increase.

As the level of complexity increased, the newsletter itself improved in quality.

I would like to write more about how a newsletter can be created and distributed using Sprints and other Agile methods because doing it this way helped me to stay adaptive & flexible as the newsletter was refined.

5 keys for using Sprints to create & distribute a newsletter

  1. Understand “Done Done!” – Before CSM training, the newsletter was “done” when I pressed ‘send’ on my computer. When I better understood the meaning of “Done Done” in a Sprint I changed my thinking and behaviour. When I sent the first draft to be proof-read, this was “Done” and when it was returned to me edited and when I did final revision then it was ready for scheduling. When I pressed “Schedule” then the newsletter was “Done Done.” I would plan to schedule the newsletter three days before it was expected to be released. That gave me three days of  ‘buffer’ to accommodate last-minute changes, if necessary. I was learning to become more Agile.
  2. Learn to Accommodate Last-Minute Changes – If last minutes changes cannot be easily accommodated, then the product delivery is likely not Agile. When I started creating and distributing a weekly product, with the expectation that things could change at any time then I learned to establish a “bare-minimum” which could be produced even if changes occurred. This gave me the ability to be flexible and adaptive and much more Agile.
  3. Be Agile; Don’t Do Agile – When I went to CSM training, I thought I would learn how to do Agile things on my team. When I completed the training and started applying Sprints to the weekly distribution of a newsletter, then I realized I must “Be” Agile in my approach, in my communications, and in my creation of the product. I learned that Agile is really a state of mind and not a “thing” at all. Agile is about continuous action, reflection and planning with an open-mind and a readiness to always learn and grow and change.
  4. Action, Reflection, Planning – Before using one week Sprints, I didn’t give myself enough time to reflect and plan the next Sprint. I had a backlog with enough items to keep me busy for 6 months. My work-in-progress was a nightmare and unmanageable. I had four weeks worth of drafts saved and often got confused between what content was going out when. Establishing a regular weekly cadence helped me take control of this “mess” by just taking small action steps, reflecting on them weekly, and using the learning to plan the next steps. This revolutionized my work.
  5. Prepare For Growth – When a product is delivered successfully with Sprints, it keeps getting better and better. This leads to goals being met and growth happening on the team. In this case, it lead to increasing numbers of subscribers and the establishment of a collaborative team approach to creating and distributing the newsletter. Without Sprints, without an Agile mindset, I’m absolutely certain the goals would not have been achieved and growth wouldn’t have occurred. But with Sprints, things just keep getting better and better every week. I love it!

******************************************************

If you’d like to subscribe to the weekly newsletter I mentioned here, you can do so at this link.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

5 Links To Engaging Retrospectives

When a team starts implementing Scrum they will soon discover the value and the challenge in retrospectives.

Project Retrospectives: A Handbook for Team Reviews says that “retrospectives offer organizations a formal method for preserving the valuable lessons learned from the successes and failures of every project. These lessons and the changes identified by the community will foster stronger teams and savings on subsequent efforts.”

In other words, retrospectives create a safe place for reflections so that the valuable lessons can be appreciated, understood and applied to new opportunities for growth at hand.

The Retrospective Prime Directive says:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

With these noble principles in mind, there should be no fear from any team member about the learning, discoveries and occasions for progress.

These 5 retrospective techniques may be useful for other teams who are looking for fun ways to reflect and learn and grow.

  1. Success Criteria – The Success Criteria activity helps clarifying intentions, target outcomes, and results for success criteria. It is a futurospective activity for identifying and framing intentions, target outcomes and success criteria.
  2. 360 degrees appreciation – The 360 degrees appreciation is a retrospective activity to foster open appreciation feedback within a team. It is especially useful to increase team moral and improve people relationship.
  3.  Complex Pieces – Complex pieces is a great energizer to get people moving around while fostering a conversation about complex systems and interconnected pieces.
  4. Known Issues – The Known Issues activity is a focused retrospective activity for issues that are already known. It is very useful for situations where the team (1) either knows their issues and want to talk about the solutions, or (2) keep on running out of time to talk about repetitive issues that are not the top voted ones.
  5. Candy Love – Candy love is a great team building activity that gets the participants talking about their life beyond the work activities

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Retrospectives: Sometimes dreaded, sometimes loved but always essential

Among all the components of Scrum, retrospectives are one of my favourites. A properly planned, efficiently executed, and regularly run retrospective can be like the glue that holds a team together.

My first experience in running a retrospective had surprising results.  We were working in a team of five but only two were present in the retrospective. Not only that, but of these two, neither could decide who should be running the retrospective. To be clear, this was not a Scrum team. But it is a team who is using some Agile methods to deliver a product once a week. Retrospectives are one of the methods. So without a clear ScrumMaster to facilitate the retrospective it was, let’s say, a little messy.

Despite all this, there were some positive results. The team had released a product every three weeks with success. The retrospective on the third week revealed challenges & progress, obstacles and opportunities.

The method used was the format of a Talking Stick Circle, where one person holds the floor and shares their reflections while others listen without interrupting and then the next person speaks and so on.

The major learning was that there were decisions to be made about who was doing which task at what time and in the end the direction was clear. Enthusiasm was high and the path forward was laid. The retrospective was a success.

The most remarkable part of the experience was hearing what was meaningful for others. When both people could share what they valued, hoped for and aspired to with the project it was easy to see what could be done next, using the skills, capacities and talents of team members.

For more resources on agile retrospectives, check out this link.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

New Agile Planning Game For Parents & Children

planningpokerdecks

 

Challenge: As children age, they want to have more say in how they spend their time. Sometimes they don’t know how to express what is important to them or they can’t prioritize their time.

Solution: Parents can easily include their children in decision-making by using an Agile playing card method.  Here’s how it works.

TO PLAY THE GAME – 

You will need:

A pack of playing cards

A stack of post-it notes

Enough pens for everyone playing

Steps to play:

SET UP

  1. Distribute post its & pens to each player
  2. Set a timer for 2 minutes
  3. Each person writes things they want to do for the pre-determined time (on a weekend, throughout a week, or in an evening)
  4. There is no limit to how much you can write.

PLAY

  1. Decide who goes first.
  2. Take turns placing one post it on the table
  3. Each person decides the value of that activity (0-8)
  4. When everyone has decided play the cards
  5. Notice what everyone chose.
  6. If someone played a 1 or 0 it’s nice to listen to why they rated it so low
  7. Place the sum of the two numbers on the corner of the post it.
  8. Continue this going back & forth putting the activities in a sequence with the higher numbers at the top

DISCUSS

  1. When all the post it activities have been gone through, then look at the top 5 or 6 items. These will likely be the ones you will have time for.
  2. Discuss if there are any over-laps and shift the list accordingly.
  3. Discuss what makes the most sense and what both would like to do. The chances are good that all of these items are ones that both/all people rated high, that’s what put them on the top of the list.
  4. It should be relatively easy to find a way to do the top 3-5 activities with little effort.

PLAN for the day and ENJOY!!!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Video: Agile Social Action at a Neighbourhood Level

This post marks the beginning of a new Agile experiment supported by BERTEIG.

Quite simply, the idea is to apply Agile methods and principles outlined in the Agile Manifesto to a social action project at a neighbourhood level.

The objective is to use the empowering principles of Agile to help eliminate the extremes between wealth and poverty.

The approach is to pair up one family who has items to share with another family who is in need in order to provide a weekly care package including food and other basic care supplies.

The sharing takes place in the real world with the delivery of a package weekly but also corresponds to an online platform which allows for the sharing to happen at an sustainable cadence.

The initiative was formally launched three weeks ago and this video is the first which addresses some basic structures of the framework. This video is a bit like a one-person retrospective.

One of the principles of BERTEIG is to strive to create unity and to be of service to humanity. This socio-economic Agile experiment is a way in which BERTEIG is reaching out to help others and contributing towards the advancement of a small neighbourhood moving along the continuum from poverty to prosperity, materially and spiritually.

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Leader Responsibilities

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

Are You Getting What You Need From Conferences?

(Originally posted in June 2015 – Updated October 2016)

Photo Credit: BERTEIG’s Valerie Senyk facilitated a group session on “What Do We Mean by Transformation?” in Orlando 2016.

Professional Development opportunities are everywhere and they are easy to find at any price-point on any topic at any location. The hard part is deciding how to spend your time.

It is important to think about why you attend conferences. Most importantly, why do you choose some conferences over others? Do you want to learn from peers in your field? Do you want exposure to the latest industry trends? Are you looking for a new job? Or do you just want to be blown away by great people?

I attended the Agile Coach Camp Canada last weekend in Cornwall, Ontario, and that incredible experience has caused me to reflect on the variety of conferences I have enjoyed in recent years…and why I choose some over others.

Like any great product, successful conferences have clear and focused goals which create specific opportunities for their participants. Conference organizers choose location, venue, date, duration, registration cost, format, theme, etc. The best conference organizers are courageous and willing to make difficult decisions in order to compose their events with utmost respect to the collective vision and goals of the attendees, sponsors, and founders. The organizers of Agile Coach Camp Canada, for example, are dedicated to creating an event in which the agile coaching community can “share in an energizing and supportive environment”. That’s it! A clear and compelling vision. This clarity of vision guides decisions like whether to host the event in a metropolis (which may result in larger numbers and more sponsorship opportunities) or away from large cities (think overnight “camp”) — this is one formative decision of many that make Agile Coach Camp Canada so intense and unique year after year.

Some background: This was the 6th annual Agile Coach Camp Canada and the 2nd time that I have attended; the event generally starts on Friday evening and includes supper followed by lightning talks, Saturday uses Open Space Technology to produce an agenda followed by supper and socializing (late into the night!), then Sunday morning wraps-up with retrospection then everybody leaves in early afternoon; the cost per person is between $300-$500 for the entire weekend including meals, travel, hotel room; the event is often held in small-ish towns like Guelph or Cornwall which are a few hours from a major airport. Having been there twice — both times just blown away by the community, their expertise, their emotional intelligence, their openness — I understand very clearly the responsibility of conference organizers and I have gained new respect for the difficult decisions they must make.

Upon reflection, I know that I attend the Agile Coach Camp Canada because (a) I learn a lot and (b) I have bonded deeply with my colleagues. Those are the two reasons that I will return next year and the next. I do not attend that event with an expectation to develop new business, or attract new leads, or stay on top of industry trends — instead, I will look to other conferences for those opportunities.

What/where/when is your next professional excursion? Do you know what you want to get out of it? Here’s a tip: choose one objective from the list below and find a conference that delivers exactly that!

  • Business development: Find new or reconnect with existing business contacts.
  • Professional development: Find or explore opportunities for career enhancement.
  • Learning: Listen/watch/share with others who practice in your areas of interest.
  • Community building: Connect and communicate with people with interests or qualities that you appreciate.
  • Market exposure: Evangelize a product or service for a captive audience.
  • Other?

Life is short…make it amazing!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: New Leadership Training – First in Canada!

Certified Agile Leadership (CAL 1) Training

Michael Sahota - Profile Picture (2016)Introduction:

Advanced training for leaders, executives and change agents working in Agile environments.


Your success as a leader in an Agile organization requires looking beyond Agile itself. It requires a deep understanding of your organization and your own leadership path. To equip you for this journey, you will gain a strong foundation in understanding organizational culture. From there, you will learn key organization and leadership models that will allow you to understand how your organizational culture really works.

Now you are ready to start the journey! You will learn about organizational growth – how you may foster lasting change in your organization. Key is understanding how it invite change in a complex system. You will also learn about leadership – how you may show up more effectively. And how to help others.


Learning Objective(s):

Though each Certified Agile Leadership course varies depending on the instructor, all Certified Agile Leadership courses intend to create awareness of, and begin the journey toward, Agile Leadership.


Graduates will receive the Certified Agile Leadership (CAL 1) designation.

See Scrum Alliance Website for further details.

Agenda:

Agenda (Training Details)

We create a highly interactive dynamic training environment. Each of you are unique – and so is each training. Although the essentials will be covered in every class, you will be involved in shaping the depth and focus of our time together. Each learning module is treated as a User Story (see photo) and we will co-create a unique learning journey that supports everyone’s needs.

The training will draw from the learning areas identified in the overview diagram.

Organizational Culture

“If you do not manage culture, it manages you, and you may not even be aware of the extent to which this is happening.” – Edgar Schein

  • Why Culture? Clarify why culture is critical for Organizational Success.
  • Laloux Culture Model: Discuss the Laloux culture model that will help us clarify current state and how to understand other organizations/models.
  • Agile Culture: Explore how Agile can be seen as a Culture System.
  • Agile Adoption & Transformation: Highlight differences between Agile Adoption and Transformation.
  • Dimensions of Culture: Look at key aspects of culture from “Reinventing Organizations”. Where are we and where might we go?
  • Culture Case Studies: Organizational Design: Explore how leading companies use innovative options to drive cultural operating systems.

Leadership & Organizational Models

  • Theory X – Theory Y: Models of human behaviour that are implicit in various types of management systems.
  • Management Paradigms: Contrast of Traditional “Modern” Management practices with Knowledge worker paradigm.
  • The Virtuous Cycle: Key drivers of success emergent across different high-performance organizational systems.
  • Engagement (Gallup): Gallup has 12 proven questions linked to employee engagement. How can we move the needle?
  • Advice Process: More effective decision-making using Advice Process. Build leaders. Practice with advice cards.
  • Teal Organizations: Explore what Teal Organizations are like.

Leadership Development

  • Leading Through Culture: How to lead through culture so that innovation and engagement can emerge.
  • VAST – Showing up as Leaders: VAST (Vulnerability, Authentic connection, Safety, & Trust) guides us in showing up as more effective leaders.
  • Temenos Trust Workshop: Build trust and charter your learning journey. Intro version of 2 day retreat.
  • Compassion Workshop: How to Use Compassion to Transform your Effectiveness.
  • Transformational Leadership: See how we may “be the change we want to see” in our organizations.
  • Leading Through Context: How to lead through context so that innovation and engagement can emerge.
  • Leadership in Hierarchy: Hierarchy impedes innovation. Listening and language tips to improve your leadership.

Organizational Growth

  • Working With Culture: Given a Culture Gap. What moves can we make? Work with Culture or Transformation.
  • Complex Systems Thinking: Effective change is possible when we use a Complex Systems model. Cynefin. Attractors. Emergent Change.
  • Healthy “Agile” Initiatives: How to get to a healthy initiative. How to focus on the real goals of Agile and clarify WHY.
  • People-Centric Change: The methods we use to change must be aligned with the culture we hope to foster. How we may change in a way that values people.
  • Transformation Case Study: Walkthrough of how a transformation unfolded with a 100 person internal IT group.

Audience:
There are two main audiences that are addressed by this training: organizational leaders and organizational coaches. The principles and practices of organizational culture and leadership are the same regardless of your role. Organizational leaders include executives, vice presidents, directors, managers and program leads. Organizational coaches include Agile coaches, HR professionals, management consultants and internal change leaders. “The only thing of real substance that leaders do is to create and manage culture.” – Edgar Schein
Facilitator(s):

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Building New Capacity

One concept that is integral to BERTEIG’s vision is for the company to grow organically through systematic capacity-building of its team…Which is one reason why I attended Coach’s Camp in Cornwall, Ontario last June. However, I discovered that my understanding of coaching in an Agile environment was totally out to lunch, a universe away from my previous experiences of being an acting and voice coach.

Doing a simulation exercise in a workshop at Coach’s Camp, I took the role of coach and humiliated myself by suggesting lines of action to a beleaguered Scrum Master. I was offering advice and trying to solve his problems – which is, I learned, a big no-no. But I couldn’t quite grasp, then, what a coach actually does.

Despite that less-than-stellar attempt, I was curious to sign up for Scrum Alliance’s webinar called “First Virtual Coaching Clinic,” September 13, 2016. They had gathered a panel of three Certified Enterprise Coaches (CEC’s): Michael de la Maza, Bob Galen, and Jim York.

The panel’s focus was on two particular themes: 1) how to define and measure coaching impact, and, 2) how to deal with command and control in an organization.

The following are some of the ideas I absorbed, which gave me a clearer understanding of the Agile coaching role.

Often, a client is asking a coach for a prescription, i.e. “Just tell me/ us what to do!” All three panel members spoke about the need for a coach to avoid being prescriptive and instead be situationally aware. A coach must help a customer identify his/her own difficulties and outcomes correctly, and work with them to see that achieved. It’s helpful to share stories with the client that may contain two or three options. Be as broad as possible about what you’ve seen in the past. A team should ultimately come up with their own solutions.

However, if a team is heading for a cliff, it may be necessary to be prescriptive.

Often people want boundaries because Agile practices are so broad. Menlo’s innovations (http://menloinnovations.com/our-method/) was suggested as a way to help leaders and teams play. Providing people with new experiences can lead to answers. What ultimately matters is that teams use inspection and adaptation to find practices that work for them.

A good coach, then, helps a client or team find answers to their own situation. It is essential that a coach not create unhealthy dependancies on herself.

It follows that coaching impact can be measured by the degree of empowerment and courage that a team develops – which should put the coach out of a job. An example mentioned was a case study in 2007 out of Yahoo which suggested metrics such as ROI, as well as asking, “Does the organization have the ability to coach itself?”

Other indicators that can be used for successful coaching have to do with psychological safety, for example: a) on this team it is easy to admit mistakes, and, b) on this team, it is easy to speak about interpersonal issues.

When it comes to ‘command and control’ (often practiced by organizational leaders, but sometimes by a team member), the coaches offered several approaches. Many individuals are not aware of their own behaviors. A coach needs to be a partner to that client, and go where the ‘commander’ is to help him/her identify where they want to get to. Learn with them. Share your own journeys with clients and self-organizing teams.

A coach needs to realize that change is a journey, and there are steps in between one point and another. Avoid binary thinking: be without judgement, without a definition of what is right and wrong.

The idea of Shu Ha Ri was suggested, which is a Japanese martial arts term for the stages of learning to mastery, a way of thinking about how you learn a technique. You can find a full explanation of it on Wikipedia.

Coaching is a delicate process requiring awareness of an entire organization’s ecosystem. It requires patience and time, and its outcome ultimately means independence from the coach.

Have I built capacity as a potential Agile coach? Not in a tactical sense; I won’t be hanging out a shingle anytime soon. But at least I‘ve developed the capacity to recognize some do’s and don’t’s...

That’s right: capacity-building IS about taking those steps…

Watch Mishkin Berteig’s video series “Real Agility for Managers” using this link: https://www.youtube.com/channel/UCBZPCl3-W1xpZ-FVr8wLGgA?feature=em-share_playlist_user


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Scrum Team Assessment – Official Launch

Hi Everyone,  I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve!  This is a fully automated Scrum maturity assessment tool!

The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results.  The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.

The analysis is both statistical and expert-system based.  This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements.  There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.

The Scrum Team Assessment includes a survey of about 100 questions that focus on seven broad categories:

  • The team’s environment
  • The basic Scrum process
  • The Product Backlog
  • Team Membership
  • ScrumMastering
  • Product Ownership
  • and Agile best practices

Every team member fills in the survey to help us generate a valid set of recommendations.

The Scrum Team Assessment is $496/team/use (that’s Canadian dollars).  If you have several teams or wish to obtain an enterprise license, please contact us at sales@berteigconsulting.com or +1-905-868-9995.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Introduction

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

Link: Automation Testing for Agile Development

Many times, participants in Certified ScrumMaster or Certified Scrum Product Owner courses ask about automation testing for agile development.

The article which follows provides an excellent answer to one of the most popular questions. After reading it, please consider leaving a comment below.

Automation Testing For Agile Development

By Agile Zone

Agile automation testing is particularly important in the Agile development lifecycle. Agile software development involves a constant feedback loop among team members. This is in contrast to the Waterfall model of development, where software testing only begins once the development phase has been completed.

In Agile development, software testing activities are conducted from the beginning of the project. Software testing is done incrementally and iteratively. Automation testing is an extremely important part of Agile testing. After each change in the system, it is important to run a battery of automated functional and regression tests to ensure that no new defects have been introduced. Without this automation testing harness, Agile testing can become very time-consuming. This can result in insufficient test coverage. This will, in turn, affect software quality. Automation testing is necessary for the project to maintain agility. As a matter of fact, introducing automation processes such as automation builds and automation smoke tests is important in all aspects of agile development. As budgets shrink, time spent on repeatable automation testing becomes more and more necessary.

Continue reading here. 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail