Category Archives: Agile Management

Unpacking the Fifth Principle of the Agile Manifesto

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

The Agile Manifesto was signed and made public in 2001. It begins with short, pithy statements regarding what should be the priorities of software developers, followed by Twelve Principles. In this article I want to call attention to the fifth principle in the Agile Manifesto, which is:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Although it appears to be a very simple statement, I suggest that it is jam-packed with profitable guidance, and is essential to, and at the heart of, real Agility. Human qualities must be considered.

Motivation

The first part of the principle urges us to build projects around motivated individuals.  What does this imply?

The idea of “building a project” makes it a process, not necessarily a fait accompli. It can change and be altered as one works toward it. There may be a structural roadmap, but many details and aspects can change in the “building.”

The second part of the statement describes motivated individuals. The verb “motivate” is an action word, meaning to actuate, propel, move or incite. Thus, in this line, is the “project” the thing which will “move or incite” those being asked to carry it out?

Or do we understand this to imply that the individuals are already “motivated” in themselves, which is an emotional condition of individuals? Is this motivation already there prior to starting a project?

The topic of motivation is rich. How does motivation occur? Is it the culture and environment of the company, lived and exemplified by it’s leaders, which motivates? Or is motivation an intrinsic quality of the individual? It may be both. (Daniel Pink, author of “Drive,” uses science to demonstrate that the best motivators are autonomy, mastery and purposeful-ness – ideas which are inherent in the Agile Manifesto.)

In any case, the line itself suggests that the project may be a) interesting to pertinent (perhaps already motivated) individuals, b) do-able by those same individuals, and c) contains enough challenges to test the mastery and creativity of the individuals. In other words, it’s going to be a project that the individuals in your company care about for more than one reason.

Environment

The second line from the fifth Principle has two distinct parts to it. The first part, “Give them the environment and support they need” puts a great deal of responsibility on whoever is assigning the project. Let’s look at the idea of environment first.

In a simple way, we can understand environment as the physical place which influences a person or a group. It can be any space or room; it can refer to the lighting, the colours, the furniture, the vegetation, the walls, whether water or coffee is available – physical elements which will certainly affect the actions of people and teams. For example, creating face-to-face collaboration environments is also part of the Agile Manifesto.

But we must remember that environment also entails the non-physical ie, the intellectual, emotional, or even the spiritual. Is the environment friendly or not? Cheerful or not? Encouraging or not? Affirming or not? We can think of many non-physical attributes that make up an environment.

Support

These attributes allude to the second part of what’s to be given by an owner or manager: “…and support they need.” This idea of support pertains not just to helping someone out with tools and responding to needs, but that the environment is supportive in every way – physically, intellectually, emotionally and spiritually. This may be a more holistic way of considering this Agile principle.

The last part of the statement is of great importance as well: and trust them to get the job done.

If you as product owner, or manager have created motivation, environment and support, then the last crucial requirement of trust becomes easier to fulfill. There is nothing more off-putting than being micromanaged, supervised or controlled with excessive attention to small details. Trust means you have confidence in the capacity of your team and its individual members. It also implies that they will communicate with transparency and honesty with you, and you with them, about the project.

Context

The principles of Agile do not exist in a vacuum, because, of course, other principles such as the following, are relevant to this discussion:

The best architectures, requirements, and designs emerge from self-organizing teams.”

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

This fifth principle has application far beyond IT projects. I wanted to reflect on it because it speaks to human qualities, which must be recognized as a key factor in happy work places, and in any high-performance team.

Valerie Senyk is a Customer Service agent and Agile Team Developer with BERTEIG.

For more information please go to http://www.worldmindware.com/AgileTeamDevelopmentWorkshopStage1

Also read about BERTEIG’s RealAgility Program: http://www.berteig.com/real-agility-enterprise-agility/


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Kanban: Real Scaled Agility for Your Enterprise

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

Your business is an ecosystem of interdependent services, a complex adaptive system.

A bunch of organizations I know started their journey of increasing their agility with Scrum. That didn’t solve all of their problems. Kanban enables organizations to evolve their service delivery systems towards mature business agility.

As addressed in How Kanban Saved Agile, pure Scrum is extremely rare. Scrumbut (the disparaging label that spawned from so many organizations reporting that they do Scrum, but…) on the other hand, is extremely common.

In order to not be Scrumbut, you need the following:
  • Cross-functional development team of 7 +/- 2 people—ALL skills needed to ship product is present on the team—there are no dependencies external to the team;
  • One source of demand with no capacity constraints—the Product Owner is the customer AND full-time member of the team;
  • Sprints are one month or less, begin with starting new demand from the Product Owner and end with the delivery of potentially shippable Product Increments, followed by a retrospective about how to do better next Sprint;
  • “Potentially Shippable” means that the decision about whether to actually ship is purely a business decision. All the technical work is done;
  • If all of the technical work required in order to ship isn’t done, then the Sprint is a failed Sprint;
  • The Scrum Master is a servant-leader and Scrum educator to the entire organization.

How many organizations do you know of with Scrum teams that meet all of the requirements above? I don’t know one.

So, what’s the solution? Give up on Scrum? Are we still getting benefits from Scrumbut? Alright, let’s stop it with the Scrumbut already. Let’s acknowledge what’s really going with real teams in the real world and call that Scrum. Let’s refer to the above  checklist as “Ideal Scrum”.

Agile scaling methods have become a popular risk hedging tactic for all the loose ends dangling around the real teams in the real world.

Here are some of the reasons for adding layers of scaling around Agile teams:

  • Teams are not fully cross-functional;
  • Teams have external and opaque depencies;
  • Many of these dependencies are shared services with multiple sources of demand and constrained capacity—often overburdened;
  • External dependencies can be other teams—demand from other teams shows up in their backlogs, prioritized by their own Product Owners;
  • Many dependencies don’t play by the same rules at all—some reside in a different part of the organization, with different structures and political forces;
  • The Product Owners are proxies for multiple stakeholders and customers and the Product Backlogs represent an array of multiple sources of demand, with different service level expectations, strategic origins, degrees of clarity, urgency and political forces pushing them into the deliver organization;
  • The Product Backlogs are made up primarily of solutions defined by stakeholders and translated by the pseudo-Product Owners as pseudo-user stories—how they get there is opaque, the “fuzzy front end”—and somewhere in here a fuzzy delivery commitment was already made;
  • The work of a Sprint includes all of the work that the non-cross-functional teams can get done—then whatever the teams get “done” is “delivered” (handed-off) to a subsequent set of teams or process steps (usually fairly well defined at an organizational level but outside of the teams’ influence);
  • Delivery decisions are made based on constraints imposed by legacy technology, systems and their gatekeepers (for historically good reasons);
  • The teams are “done” at the end of each Sprint, yet much work is still to be done before their “done” work is potentially shippable;
  • The Scrum Master’s are held collectively accountable for the collective deliverables of the teams and their ability to cross-team coordinate and integrate—accountability by committee translates into no one is actually responsible.
  • Middle managers are scrambling to pick up the pieces because they are actually accountable for delivered results.

Generally speaking, the aim of Agile scaling methods is to apply larger Agile wrappers around clusters of Agile teams in order to re-establish some kind of hierarchical structure needed to manage the interdependencies described above. Whether its a Release Train or a Nexus, or whatever else, the idea is that there is an “Agile Team of Teams” managing the interdependencies of multiple, smaller teams. As long as the total number of people doesn’t grow beyond the Dunbar number (~150), the Dunbar-sized group is dedicated and cross-functional, there is a team managing the interdependencies within the Dunbar, there are no dependencies outside of the Dunbar and there is some cadence (1-3 months) of integrated delivery—it’s still “Agile”. All of this scaling out as far as a Dunbar (and only that far) allows the enterprise to still “be Agile”—Scaled Agile.

This is all supposed to be somehow more realistic than Ideal Scrum (with perhaps am overlay of Scrum of Scrums and a Scrum of Scrum of Scrums). It’s not. How many organizations do you know of that can afford to have ~150 people 100% dedicated to a single product? Perhaps today there is enough cash lying around, but soon enough the  economic impact will be untenable, if not unsustainable.

How does Kanban address this problem? Your business is a complex adaptive system. You introduce a Kanban system into it such that it is likely that the complex adaptive system is stimulated to improve. The Systems Thinking Approach to Introducing Kanban—STATIK—is how you can make such a transition more successful (@az1):
  1. Understand the purpose of the system—explicitly identify the services you provide, to whom you provide them and why;
  2. Understand the things about the delivery of the service that people are not happy about today—both those whose needs are addressed by the service and those doing the work of delivering the service;
  3. Define the sources of demand—what your customers care about and why;
  4. Describe the capability of your system to satisfy these demands;
  5. Map the workflow of items of customer-recognizable value (@fer_cuenca), beginning with a known customer need and ending with the need being met through stages of primary knowledge discovery (Scrum teams somewhere in the middle, towards the end)—focus on activities, not looping value streams;
  6. Discover classes of service—there are patterns to how different kinds of work flow through your system (they are not arbitrarily decided by pseudo-Product Owners), what are they? Group them, they are classes of service and knowing them enables powerful risk management;
  7. With all of the above as an input, design the Kanban system for the service;
  8. Learn how to do steps 2-7 and start applying it directly to your own context in a Kanban System Design class;
  9. Socialize and rollout (learn how by participating in a Kanban Coaching Professional Masterclass);
  10. Implement feedback-loop Cadences for continuous evolution—learn the 7 Kanban Cadences and begin applying to your own context in a Kanban Management Professional class;
  11. Repeat with all of the interdependent services in your organization—every “dependency” is a service—Kanban all of them with STATIK and begin implementing the Cadences.

Don’t get hung up on teams, roles, your latest reorg, how people will
respond to another “change”, who’s in, who’s out, etc. These are all part of the service as it is now—your current capability. Initially, no changes are required at this level. The kanban system will operate at a higher level of scale. Through feedback-loop cadences, it will evolve to be fit for the purpose of your customers without a traumatic and expensive reorg.  Who is responsible for this? Identify this person. If you are the one thinking about this problem, there is a good chance that it’s you. Whoever it is, this is the manager of the service; take responsibility, do the work and make life better for everyone.

For more information about LeanKanban University Certified Kanban courses provided by Berteig, please go to www.worldmindware.com/kanban. Some spots are still available for our classes in Toronto, June 12-16.

For Agilists who have read this far and still don’t get it, start here:

14 Things Every Agilist Should Know About Kanban

The story below may be familiar to some:

Our IT group started with Scrum. Scores of people got trained. Most of our Project Managers became “Certified” Scrum Masters. Most of our Business Analysts became “Certified” Product Owners. We purged some people who we knew would never make the transition. We reorganized everyone else into cross-functional teams – mostly developers and testers. But now they are Scrum Developers. We tried to send them for “Certified” Scrum Developer training but hardly anyone of them signed up. So they are Just Scrum Developers. But we still call them developers and testers. Because that’s still how they mostly function—silos within “cross functional teams”, many tales of two cities rather than just one.

After the Scrum teams had been up and running for a while and we were able to establish some metrics to show the business how Agile we were (since they didn’t believe us based on business results), we had a really great dashboard showing us how many Scrum teams we had, how many Kanban teams, how many DevOps, how many people had been trained. We even knew the average story point velocity of each team.

The business didn’t get it. They were worried that Agile wasn’t going to solve their problem of making commitments to customers and looking bad because we still weren’t able to deliver “on time”.

As IT leadership, we were really in the hot seat. We started to talk about why the transformation wasn’t going as it should. We knew better than to bring the Agile coaches into the boardroom. They were part of the problem and needed to be kept at arms length from those of us who were making important decisions. Besides, their Zen talk about “why?” was really getting old fast. Some thought it was because we didn’t have the right technology. Others were convinced it was because we didn’t have the right people. After all, we didn’t go out and higher experienced (above-average) Scrum Masters and Product Owners, instead we just retrained our own people. Clearly that wasn’t working.

We started with improving the Scrum Masters. We went out and hired a few with impressive resumes. We developed some Scrum Master KPIs (HR jumped all over this one). Then one day we had a collective flash of brilliance—since the ScrumMasters are the servant leaders of teams, we will make them responsible for collecting and reporting team metrics and this will tell us how well the teams are doing and how they need to improve. This surely would be the key to improving the performance of IT and get us on a better footing with the business.

But we didn’t get the response we were hoping for. The ScrumMasters soon complained that the metrics of the teams were impacted by dependencies that they had no influence over. When we pushed harder and shamed them publicly for failing to produce meaningful metrics, they tried harder, but they weren’t able to do it. Some began disengage. “This is not the job I signed up for” became their new mantra. This was puzzling. We were empowering them and they were recoiling. Maybe we didn’t get the right Scrum Masters after all. Maybe we needed to go out and find people who could think and act effectively beyond the confines of their own teams. Or…


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leading to Real Agility – Video Series

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

I have recently published all 16 videos for the Leading to Real Agility series on YouTube.  The videos cover leadership topics including:

  • Organizational Change
  • Dealing with Laggards
  • Leadership Responsibilities
  • and many others…

The videos are short (typically 2 or 3 minutes each) and focus on introducing the basics of each topic.  Further depth can be gained through our Leading to Real Agility one-on-one coaching service.

BESTEIG Real Agility logo - Agile Coach development program


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

5 Insights to Help HR Ride the Agile Wave

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

In a recent scan of the e-literature on the reciprocal impact of Agile on HR, I connected some very interesting insights which I’d like to share. A set of insights that looks like ripples across the surface of a pond. Ripples that started when the Agile stone was thrown into the pond in 2001. In its simplest form, Agile is about a different way of working with each other in teams. Teams that are cross-functional, collaborative, co-located and customer-driven in their decision making. The insights provide compelling reasons why HR needs to take an active role in Agile implementations.

Insight #1

“In the most successful Agile transformations, HR is a driver of the change and a key hub that steers other departments’ success.”

(cPrime.com)

HR certainly needs to be ‘a’ driver in the change, but not ‘the’ (sole) driver. Rather they need to partner in the change. Successful Agile transformations will benefit from HR’s expertise in

  • Organizational Effectiveness
  • Learning & Development
  • Workforce Planning & Talent Management
  • Total Rewards

The driver of the change, historically IT, will need HR’s help to manage the impact to people and traditional HR processes/tools. As the change scales and starts to impact other departments in the business, HR can play a large role in ensuring the business overall stays aligned in delivering end-to-end value to customers.

Insight #2

“2016 will be the year of Agile HR… most HR teams have no clue what Agile HR means.”

(HR Trend Institute)

Agile was a hot topic for HR in 2016 as evidenced by the number of times ‘Agile HR’ has made the shortlist of topics being brainstormed for HR conferences and networks.  It was the #1 trend on the 2016 HR Trend Institute list. Its popularity is not cooling off in 2017. And yet most HR teams still don’t have a clue what ‘Agile’ means, never mind what ‘Agile HR’ means.

Insight #3

“As the world becomes more volatile, organizations need to find ways to become highly agile. HR will need to support a world where people may no longer have predefined ‘jobs’ that lock them into doing one activity.”

(HRO Today)

Agile has entered the mainstream. A necessity given the VUCA[1] world we live in.  Agile is no longer the sole domain of IT. The common refrain from all C-suite leaders these days is increased agility and nimbleness across the entire business – not just IT. The impact of capital ‘A’ Agile or small ‘a’ agile will affect HR. People will no longer have predefined jobs – People’s career paths will change. In this VUCA world, standardized career paths are no longer effective. Batch-of-one career paths will become the norm.

Insight #4

“HR’s job is not just to implement controls and standards, and drive execution—but rather to facilitate and improve organizational agility.”

(Josh Bersin)

The HR profession itself has been going through its own transformation. The HR profession has evolved from an administrative and transactional service to a strategic business stakeholder with a seat at the executive table.  The role of HR now includes a focus on organization-wide agility and global optimization of departmental efforts.

Insight #5

“Human capital issues are the #1 challenge for CEOs globally.”

(The Conference Board CEO Challenge 2016)

The Conference Board’s 2016 survey of global CEOs ranked human capital issues as the number one challenge. It has been number one for the last four years in a row. Within that challenge, there are two hot-button issues:

  1. Attracting and retaining top talent
  2. Developing next-generation leaders

The adoption of agile ways of working will change

  • How we recruit and engage
  • How we nurture and grow not only our leaders but our talent in general

In the words of Robert Ployhart, “…employees don’t just implement the strategy – they are the strategy”[2]. CEOs around the world would tend to agree.

The net of these insights is the more HR professionals understand Agile and its implications, the more effective Agile or agile initiatives and people/strategy will be.

I’d like to see HR ride the wave.

 

 

[1] VUCA is an acronym introduced by the US military to describe a state of increased Volatility, Uncertainty, Complexity and Ambiguity

[2] Ulrich, Dave, William A. Schiemann, Libby Sartain, Amy Schabacker Dufain, and Jorge Jauregui Morales. “The Reluctant HR Champion?” The Rise of HR: Wisdom from 73 Thought Leaders. Alexandria, VA: HR Certification Institute, 2015. N. pag. Print.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management

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

The battle of the organizational change management approaches!

Check out the presentation I did last night at Agile Mississauga Meetup.

20170208 Agile Mississauga Meetup – Change Approach Characterization Model

I describe a model for understanding change management approaches and deciding which ones to use for your situation.  I also look briefly at Positive Deviance and Appreciative Inquiry.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

How HR Can Save or Destroy Agile

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

“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”

It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.

“Companies are running 21st century businesses with 20th century workplace practices & programs”

– Willis Towers Watson

It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:

  • “Can we team interview the candidate for attitude and fit?”
  • “I was an IT Development Manager. What’s my role now?”
  • “My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
  • “With no opportunity for promotions in sight, how can I advance my career?”
  • “Why do we recognize individuals when we’re supposed to be focused on team success?”
  • “Charlie’s not working out. Can we as the team fire him?”

As the volume increases, how will HR and HR professionals respond?

“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”

– HR Trend Institute

The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR  sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.

There are three significant change movements gaining momentum:

  1. Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
  2. Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
  3. Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)

All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.

An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.

“How do we get HR started towards their destiny?”

If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.

If you’re an HR professional, here are some suggestions:

  • Learn about Agile
  • Visit with your Agile teams during sprint reviews or daily scrums
  • Talk to your friends and colleagues about their Agile experiences and challenges
  • Review in-progress HR process & tool changes through an Agile lens
  • Partner with IT and other Agile implementation stakeholders to guide the success of Agile

To help HR take the first step, here are some suggested Agile learning resources:

It’s time for HR to get off the sidelines and get in the game.  HR needs to be a “friend” to Agile, not perceived as a “foe”.

Borrowing from a Chinese proverb,

When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.

Build windmills.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

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