Tag Archives: change

Miscellaneous, Uncategorized

Selling Organizational Transformation – Part II

Leave a comment

In Part I, I highlighted the basic importance of proper preparation in anticipation of an impromptu CxO meeting. The aim, of course, is to move up the organizational structure to the decision-makers who are most likely to require a greater portfolio of my services. My background is rooted in helping organizations achieve business agility so that they can better provide services that their customers desire.

If we pick up from the end of Part I, let’s assume I’ve piqued Sarah’s interest. There is a very strong possibility now that CEO Sarah will have an unscheduled, casual ‘elevator’ discussion with Christine about her efforts and perhaps even the work she’s contracting me for.

VP’s, like other Executives, hate surprises. Not knowing their relationship, there is a high probability that things will go south at this point, largely because I’ve potentially introduced risk to Christine and her career. The probability that something is going slightly ‘wrong’ in her portfolio is likely high. And she’s now on the CEO’s radar.

Next steps are obvious – it is imperative for me to speak with Christine, preferably face-to-face. Positioning the conversation is key now. In my experience, this is a “build trust” or “destroy trust” conversation. Prior to that face-to-face, I need to prioritize my talking points, which should be as follows:

  • Confirm the positive impact my team is having with respect to the organizational goals “to drive effectiveness and efficiencies”. Collect the “Yes”.
  • Determine the relationship, if any, she has with her CEO and determine the hierarchy between her and the CEO and, if possible, determine the alignment of their efforts to the CEO’s mandate (there is always a ‘black sheep’ in that mix and it could be Christine’s SVP, or even Christine herself, for instance)
  • Reduce the perceived risk by specifically reiterating the connection between my efforts, Christine’s efforts, and the corporate strategy. Collect the “Yes”.
  • Then, and only then, discuss the brief, impromptu elevator discussion I had with her CEO – and this takes tact and professionalism, and must be delivered with maturity.

My approach and the questions I’d propose, likely would take the following direction:

  • “Christine, what’s your overall ‘take’ on my teams efforts to….? [reiterate the mandate]”.
  • “Does your SVP share those thoughts, and is your leadership in the corporate strategy recognized?”
  • “And are your successes recognized outside of this channel?” [collect the “Yes”]
  • “Christine, you understand the corporate structure here, is there any risk that this project can be derailed, and is it important enough to thrive? Because, I am speaking in hypotheticals right now, but it has to look good for you, correct?” [collect the “Yes”]
  • [This is the tricky part] “Christine, you know part of my role is to champion you, your team and your efforts [insert mandate]. I wanted to meet today because I had the unplanned opportunity to speak briefly with Sarah about this particular project and she was quite keen about the positive work you are doing here. And specifically how it is in-step with the corporate mandate and her strategy. She was fully supportive of such efforts and I wanted to put this on your radar, should the conversation come back to you [pause].
  • “The other part of my job, of course, is to look for additional ways that we can help this organization. If I can help you, help your SVP and help Sarah in this process, then I’d like the opportunity to take a greater role and do so [stop].

I’m not going to walk away with a multi-million dollar contract today, but hopefully I achieved my objectives: clear the potential minefield of risk with Christine, deepen our relationship, gain further understanding of the organizational structure, continue to build trust, show that I am indeed talking with her peers and that I have the best intentions in doing so with her in mind, and I asked for further business.

In sales, we are always looking for that “inside champion” to help our deal move forward. In addition to this, I believe that in building better business relationships, the road goes both ways. I try to equally be that champion for my client. Because it serves so many purposes to do so, and it is the right thing to do as it aligns to the deeper principles I believe in, which are:

To create unity in diversity, and to help people orient their work lives towards service. To engage with people, and customer-focused organizations that seek to continually learn and grow. To work in the spirit of truthfulness, teamwork, and transparency, as this is the foundation of improvement.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching

Six Rules for CHANGE – Notes from a Talk by Esther Derby

1 Comment

Hired to help change and grow a business? These ideas are a guide for agile coaches and consultants, when you’ve been asked by a company to make them “agile.”

Esther Derby began by noting that traditional ideas of change can get in the way of real change. For example, ideas such as “Driving the change” or, “Installing Agile” or, “Evangelizing Agile” are not helpful.

What is helpful is to NURTURE complex change in complex environments.

Her Six Rules are:

1.Work from a stance of congruence.

Congruence is a place from which empathy is possible. Consider your own internal state, the context, and the situation of the people who are facing change. Think about what legitimate reasons they may have to keep things as they are!

2. Honour what’s valuable about the past and what is working now.

Don’t force people to admit they’ve been wrong. Shift your language, i.e. “This served you well when…” People don’t change because of data, but only because of what they value!

3. Assess the current situation and the current system.

How is the system working now? What holds the current pattern in place? What might shift the pattern? Who benefits from the status quo, and who will benefit from change?

4. Work by attraction.

Find those who are willing to work with you, i.e. try pair-programming with someone. Find your allies and follow the energy. Don’t rely only on the formal hierarchy. Analyze existing networks, activate and enhance them. Those who cross silos can influence others and change people’s norms. Ideas can be contagious.

5. Guide the change, and work by successive approximation.

Everything (and everyone) thrives in different conditions. Not every scrum team needs to work in the same way. Consider where global principles apply, and what can evolve locally. “When people get their fingerprints on something, it becomes theirs.” Ask for more of this, and less of that – scrum teams aren’t necessarily standardized.

6. Use experiments.

Big changes scare people. Experiments help people practice and learn. Insert at least 3 ideas – not more – then observe, evaluate and adjust.

7. (Esther tacked on this extra…) Use your own curiosity, generosity, patience and self-care. Use yourself. Change is often stressful.

These are my notes from the Regional Scrum Gathering, Toronto, March 2018, and any misunderstandings of Ms. Derby’s presentation are mine.

See also http://www.agileadvice.com/2015/02/10/referenceinformation/retrospective-technique-what-did-you-learn/

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban, Scrum Master, Uncategorized

Slaying Hydra: The Story of A Business Agility Coaching Partnership

Leave a comment

Part I of III

Summer 2014. The IT group of “Big Data Marketing” was in the full throws of an Agile transformation spearheaded by the new CTO. I was brought in as a Scrum Coach. My initial objective was to launch a couple of Scrum teams and serve as their Scrum Master. Around the same time, the firm’s head of PMO had been re-assigned as the Agile Practices Lead (APL) and he and I began working together on supporting the new Scrum Master community of practice, populated by his new reports. Our work gradually evolved into much more than what either of us could have imagined at the time. This 3-part series is my first attempt at putting down the story of that partnership.

In addition to serving as the initial Scrum Master for some of the teams, I was also trying to help existing team members transition into the Scrum Master role. I wanted to develop internal capacity so that I could focus on supporting a growing program of multiple teams. As the number of Scrum Masters and teams I was supporting increased, so too did the need for collaboration with the APL.

At the time, senior IT leadership was focussed on getting those doing the work of creating value (the teams) to fundamentally change the way they were working. That is, into self-organizing teams with Scrum Masters as “servant-leaders”. This included the reassignment of project managers as Scrum Masters and business analysts as Product Owners and staff into cross-siloed teams.

Chaos and confusion ensued. It was a deliberate strategy of senior leadership: Disrupt the culture of complacency. Force people to transform by throwing them into chaos. Throw everyone into the deep end and the right people will learn to swim.

A great deal of pressure was placed on the Scrum Masters to measure and improve team performance (based on pseudo-metrics such as story point velocity). They were essentially told to create a new identity for themselves and this was painful. Similarly, the APL was on the hook to support all these people in their new roles – to be a “servant-leader of the servant-leaders”. This concept of servant-leadership was front and centre in the conversation: “What is it, and how do we make it work here?” My role was to help create a shared understanding of the desired new culture.

I discovered months later that the day after I started the engagement, around 50 people had been fired. This had nothing to do with me, but naturally people thought that it did. Even years later, this day was commonly referred to by the survivors as “Bloody Monday”. Because of the timing of the mass-exit, unprecedented in the company’s 25-year history, staff understandably regarded me as the consultant who advised the cull. It’s not exaggerating to say that it instilled terror, was emotionally coupled with the transformation as a whole and implicated me as an individual. I thought of myself as one contributing help, but I was regarded as one contributing to harm. I saw myself as a Hippocrates but I was known as a Procrustes. I only learned about this months later, after I had finally managed to cultivate a bond of trust with some folks. A consequence of this fear was that I found myself in many one-on-one sessions with new Scrum Masters who were struggling to adapt and afraid of being the next victim to lose their jobs. Rather than providing Scrum Master therapy, I should have been helping the company to improve its delivery capabilities.

The theme of this first stage was the deep, broad and painful disruption of people’s lives caused by this deep Satir J-curve transformation model deployed by senior management. What I didn’t fully appreciate at the time is that emotionally, people experience change the same way they experience pain. The human brain literally responds the same. Not only were these human beings experiencing deep, chaotic change, they were also experiencing deep pain. And I was complicit in this.

The other contract coaches and I attempted to bring the crisis to the attention of senior management. We believed that it was a leadership problem, they believed that it was a staff complacency problem. The standoff lead to the coaches losing access to the leaders we were trying to help. This was a deep crisis for the group of coaches and the staff. The staff were beginning to see us as their advocates and we failed. For many Agile coaches, their part in the story ends here. In fact, some of the coaches on our team soon decided to move on to other opportunities. Others were not asked to extend their services beyond their initial contract term. Fortunately for me, the story didn’t end here. I will share more about this in Parts II & III of this series.

A teaser: These days, I advise and coach senior management to take responsibility to deliver services to customers, to understand what makes their services fit for the purposes of their customers and to design and evolve service delivery systems the fitness criteria of which are transparent to all those involved in the work. Then, allow people to truly self-organize around how the work gets done. In other words, manage the work not the people.

To be continued…

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Miscellaneous, Uncategorized

Selling Organizational Transformation (Part I)

Leave a comment

Perhaps the most difficult sales effort is the one where you need to move beyond the level you’ve fixed yourself in. The focus of this article is to look at one way to mature a relationship beyond the initial landing to where real traction occurs and where you could really sell effective transformational change in the organization. For example, you’ve landed a small deal somewhere in the junior corporate strata, say at the ‘Team’ level, and you’re now seeking to expand. The problem is you are stuck at that level and you may have pigeonholed yourself with that small deal. And now you face the real risk of losing out on larger opportunities – opportunities perhaps where you can help drive real business agility.

To further complicate matters, it is very rare that your customer will ever fully tell you exactly what is going on in an organization. And that can be for a number of reasons. And in my recent 24 years of sales efforts, the reasons are virtually endless.

However I have found there is one common tactic that works towards the successful expansion of your valued services within an organization, especially if the level you initially land on is junior.

To demonstrate, I’d like to look at what actually happens, in my experience, with the typical sales process. Personally, I love having my Senior Consultants helping medium and large enterprises achieve real business agility. It’s the difference, in my opinion, between ‘doing Agile’ and ‘being Agile’, so I have been quite keen on developing ways to drive towards this outcome.

True story (and all names are pseudonyms): I reached out to a colleague who introduced me to his friend in the IT side of a large bank. Purposefully I did not use a PowerPoint or give a presentation. Instead, we talked about his industry, his competitors, the future, and where the real change needed to happen in order to meet that future. As a salesperson, my feet are on the street, and I was able to discuss trends, customers, potential pitfalls and potential opportunities.

I was able to do this (hint) because I studied his industry – hard – before the meeting. I looked at the changes in associated industries, and the implications that might have on his industry. And the implications if his company initiates a strategy to meet those challenges, and the implications if they don’t make that effort. We discussed the impact on different generations, for example how Boomers consume services differently than Millennials do, and why.

Asking really good questions in such meetings can be difficult, if you are not prepared. So do your homework. I was able to secure a small deal at the ‘Team’ level based on the combination of what I’ve described above.

But still, even as the work started, I wasn’t getting the audience to discuss their larger organizational initiative, and that is really where I wanted to play.

In this same scenario, I found out that a new CEO had taken up the helm at this bank. Where did that CEO come from? What challenges were faced and overcome at their previous positions (aka, why did this bank hire her?). New CEO’s tend to ‘shake things up’, and given that, where do you think the first mandate will be directed? What is the lowest performing division or operations in that bank?

Look at the stock market, the Quarterly and Annual Reports. Look for clues. I found that the CEO stated that “it is a new era to find Efficiencies and Effectiveness” in a public announcement. I just discovered their organizational initiative.

Next step was to structure all meetings at that bank to sell that same message. If you’re not selling the same message, then you are not aligned to that strategy. And you will never get above that junior level you wish to move beyond. Of course, if you cannot deliver efficiencies and effectiveness, move onto a different client. But this happens to be completely aligned to what we at BERTEIG do, so it’s gold.

And use social media. What has that CEO written/published? How many followers does she have? Which symposiums has she attended or spoken at?

I found one of her Sr. Executives had traveled to the States for a conference. I found that out through Facebook. If you can suspend the ‘creep factor’, I was looking at his profile and I noticed that 50% of his friends were co-workers of a former 3-letter acronym company. And he published a photo of the road sign naming the city where the conference was held. Research showed there were 4 conferences in that city. Three were local in focus, but one was on Big Data and Analytics. LinkedIn told me that the Sr. Executive is in charge of End-User adoption (i.e. Customer focused).

It doesn’t take a leap of faith to figure out that the Sr. Executive is most likely looking at options to obtain and manage customer information in order to better support their customer, and to tailor future offerings to that customer. That’s a lot of data that has to be managed, and managed well. (I urge you to think like his customer when doing this research.)

Knowing that alone gives you something to talk about when you meet an Executive in an elevator – and you will get that opportunity.

But don’t stop there. Who spoke at the conference? Do a search. In my case I found out that the Sr. Executive who attended, had a former co-worker speaking on behalf of that 3 letter company. I downloaded his Big Data presentation. Since the two of them worked together, which is the most likely company to get invited in to do Big Data work at the bank? And if I went into a meeting with a negative view of that acronym company, how would that help my chances with the Sr. Executive, considering his friends are employed by it?

This is not a negative. You now know who your competition is. Do your research. That competition is really, really good at Executive-to-Executive pairing, but their delivery is known as being a bit ‘thin’. That’s your entry point. Don’t fight the battle on grounds you cannot possible win on.

You’ve done the bare minimum of research so far that if you were in an elevator and that new CEO was standing there, you could strike up a meaningful conversation of value, without “going over the head” of your contact. But the conversation must have meaning, bring value, be customer focused, show that you know her industry, and it must be aligned to her mandate.

I got that elevator opportunity, because I wasn’t sitting at my desk. “Sarah Jameson, I am Mark Kalyta, congratulations on your new role. I’m working with Christine Smith, your VP who is over in IT. We’re providing some consulting (don’t sell the ‘training’ for example, unless you want to pigeon hole yourself again) to help her team bring ‘efficiency and effectiveness’ to her vertical, and we are having some early measurable success”. Pause.

Note, you’ve just reiterated her mandate, you indirectly informed her that her message is reaching her VP’s, and ‘Christine Smith’ is actioning the CEO mandate by hiring you, and you are applying measurements that show your group is helping her team. In this case, I wasn’t able to insert my knowledge around their Big Data efforts, however I wasn’t worried, and I could play that card later.

So I started with a small bit of work in a junior team with no access to Christine Smith, the VP. LinkedIn research found a connection in the chain from my junior person up to the CEO, and identified Christine as my project owner, and the CEO as owning the mandate.

Back to Sarah Jameson. “Sarah, my challenge is that the work over there represents 5% of what my organization is really good at, and that is helping organizations at the Leadership level find those efficiencies and drive effectiveness (see what I parroted there?) so that your ‘customer’ sees the value and benefits from it” (and there). “We are doing great work with Christine, and early measurements show a 10% improvement in efficiency with her teams, and that is great for the overall effectiveness of your organization. I’d like to broaden that message across your Leadership team; is that something you can help me with or could delegate to me accordingly? Because I think we can duplicate this early success, if there is an appetite for it. How would you suggest I proceed?”

Now the above may seem sloppy, but there are key points that can be drawn from it. I am not going to get into all of them. You may fall flat on your face with this approach, and if so, that would be all about Sarah Jameson, and not about your skills. But you’ve hedged your bets.

Now, your next steps are clear. You need to advert the perceived “end-run”, and that requires a different strategy.

Read Part II to find out what comes next!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Trust at Work

Build Positive Relationships With Trust in Your (Work) Life

2 Comments

Trust is an exceptional quality that we humans can develop with each other. It goes a long way to building positive relationships. We hope and strive for trust in our families, and with our most intimate connections. Yet do we expect trust in our work lives?

Can you imagine the  relief you might feel entering your work space, knowing that you can do your work with confidence and focus? That encouragement rather than criticism underlies the culture of your workplace? That a manager or co-worker is not scheming behind your back to knock you or your efforts down in any way? That you’re not being gossiped about?

Trust is especially key in today’s work spaces. Teamwork is becoming an essential aspect of work across every kind of business and organization.

Here’s what one team development company writes about this subject:

The people in your organization need to work as a team to respond to internal and external challenges, achieve common objectives, solve problems collaboratively, and communicate openly and effectively. In successful teams, people work better together because they trust each other. Productivity improves and business prospers. http://beyondthebox.ca/workshops/team-trust-building/

It Starts With Me and You

As with so many qualities in life, the idea of trust, or being trustworthy, starts with me and you.

It is essential that we take a hard look at ourselves, and determine whether or not we display the attributes of trustworthiness.

To do this, I might ask myself some of these questions:

  • Do I tell the truth?
  • Do I avoid backbiting (talking about others behind their back)?
  • Do I do what I say I’m going to do?
  • Do I apply myself to my work and do my best?
  • Do I consciously build positive relationships with all levels of people in my workplace?
  • Do I encourage or help others when I can?

There are many more questions to ask oneself, but these offer a place to start.

One website proposes a template to assess employees in terms of their trustworthiness:

Trust develops from consistent actions that show colleagues you are reliable, cooperative and committed to team success. A sense of confidence in the workplace better allows employees to work together for a common goal. Trust does not always happen naturally, especially if previous actions make the employees question if you are reliable. Take stock of the current level of trust in the workplace, identifying potential roadblocks. An action plan to build positive relationships helps improve the overall work environment for all employees.

http://smallbusiness.chron.com/develop-maintain-trust-work-relationships-12065.html

This snippet comes from “Lou Holtz’s Three Rules of Life,” by Harvey MacKay:

“The first question: Can I trust you?”

“Without trust, there is no relationship,” Lou said. “Without trust, you don’t have a chance. People have to trust you. They have to trust your product. The only way you can ever get trust is if both sides do the right thing.”

http://www.uexpress.com/harvey-mackay/2012/5/7/lou-holtzs-3-rules-of-life

Asking questions helps me to be more aware and to learn. What might you change to help create greater trust with your colleagues or team?

As well, what actions can you take to help your team to experience greater trust altogether?

You can read more about Trust at http://www.agileadvice.com/2017/05/29/uncategorized/soft-skills-revolution-may-want-team-development/

Valerie Senyk is a Team Development Facilitator, Blogger, & Customer Service Rep at BERTEIG. You can learn about her Team Dev workshop at http://www.worldmindware.com/AgileTeamDevelopment

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Theory of Agile

Unpacking the Fifth Principle of the Agile Manifesto

3 Comments

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/

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Kanban, Uncategorized

Kanban: Real Scaled Agility for Your Enterprise

2 Comments

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…

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Theory of Agile

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

1 Comment

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.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban, Theory of Agile

How Kanban Saved Agile

6 Comments

In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.

Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.

Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.

Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.

For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.

There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.

The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.

Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.

Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.

But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.

For my working definition of Kanban, please refer to my previous article 14 Things Every Agilist Should Know About Kanban (this contains links to the Kanban body of knowledge, including Essential Kanban Condensed by David J. Anderson and Andy Carmichael).

For my working definition of Agile, please refer to The Manifesto for Agile Software Development.

 

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Reference Information

Leading to Real Agility – Leader Responsibilities

Leave a comment

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

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Scrum, XP and Lean

The Retro Game

3 Comments

The Hunt for Better Retrospectives

The rumours had started to spread, retrospectives at our organization were flat, stale and stuck in a rut. The prevailing thought was that this was stalling the pace of continuous improvement across our teams. In truth, I wasn’t sure if this was at all true, it’s a complex problem that has many possible contributing factors. Here are just some possible alternative or co-contributing causes: how the teams are organized, the level of safety, mechanisms to deal with impediments across the organization, cultural issues, levels of autonomy and engagement, competence & ability and so on…

Despite this, it didn’t hurt to have a look for some inspiration on good retrospectives. I really liked Gitte Klitgaard’s talk called Retrospectives are Boring and Useless – Or are They? In particular the parts around preparing and establishing safety.

On the theme of safety, I thought we could try to go as far as having fun; we’d already had lots of success with the getKanban game (oh Carlos you devil!). Where it all tied together for me, was being inspired by the great question-based approach from cultureqs.com that I’d had a chance to preview at Spark.

If I could create a game with the right prepared questions, we could establish safety, the right dialogue and maybe even have some fun.

The Retro Game

This is a question-based game that I created that you could use to conduct your next retro for teams of up to 10 people. The rules of the game are fairly simple and you could play through a round or two in about 1 to 2 hours depending on team size and sprint duration. Prep time for the facilitator is about 2-4 hours.

theretrogame

Prepping to play the game

You, as facilitator, will need to prepare for 3 types of questions that are thought of ahead of time and printed (or written) on the back of card-stock paper cards.

One question per card. Each question type has its unique colour card. About 8 questions per category is more than enough to play this game.

The 3 types of questions are:

In the Moment – These are questions that are currently on the mind of the team. These could be generated by simply connecting with each team member ahead of time and asking, “if you could only talk about one or two things this retro, what would it be?” If for example they responded “I want to talk about keeping our momentum”, you could create a question like “what would it take to keep our momentum going?”

Pulse Check – These are questions that are focused on people and engagement. Sometimes you would see similar questions on employee satisfaction surveys. An example question in this category could be “What tools and resources do we need to continue to be successful?”

Dreams and Worries – This is a longer-term view of the goals of the team. If the team has had any type of Lift Off or chartering exercise in the past, these would be questions connected to any goals and potential risks that have been previously identified. For example if one of a team’s goal is to ship product updates every 2 weeks, a question could be “What should we do next to get closer to shipping every 2 weeks?”

On the face-up side of the card it should indicate the question type as well as have room to write down any insights and actions.

You will also need:

  • To print out the game board
  • To print out the rule card
  • Bring a 6-sided dice

Playing the Game

Players sit on the floor or at a table around the game board. The cards are in 3 piles, grouped by type, with the questions face down.

therules

  • The person with the furthest birthday goes first.
  • It is their turn and they get to roll the dice.
  • They then choose a card from the pile based on the dice roll. A roll of 1 through 3 is an “In the Moment” card, 4 is a “Pulse Check” and 5 to 6 “Dreams & Worries”
  • They then read the card question on the card out loud and then pass the card to the person on the right.
    • The person on your right is the scribe, they will capture notes in the Insight and Actions boxes of the card for this round.
  • Once they have read the question, they have a chance to think and then answer the question out loud to the group. Nobody else gets to talk.
  • Once they’ve answered the question, others can provide their thoughts on the subject.
  • After 3 minutes, you may wish to move on to the next round.
  • At the end of each round the person whose turn it was chooses the person who listened and contributed to the discussion best. That person is given the card to keep.
  • The person to the left is given the dice and goes next.

Winning the Game

  • The game ends at 10 minutes prior to the end of the meeting.
  • At the end of the game, the person with the most cards wins!
  • The winner gets the bragging rights (and certificate) indicating they are the retrospective champion!
  • You should spend the last 10 minutes reflecting on the experience and organizing on the action items identified.

Concepts at Play

players-playing

Context & Reflection – Preparation is key, particularly for the “In the Moment” section. The topics will be relevant and connect with what the team wants to talk about. Also when presented in the form of a question they will likely trigger reflection for all those present.

Sharing the Voice – Everyone gets a chance to speak and be heard without interruptions. The game element also incentivises quality participation.

Coverage of topic areas – The 3 question categories spread the coverage across multiple areas, not just the items in the moment. The probabilities are not however equal, for example there is a 50% chance of “In the Moment” being chosen in each turn.

Fun & Safety – The game element encourages play and friendlier exchanges. You are likely to have dialogue over debate.

Want to play the game?

I’d love to hear how this game worked out for you. I’ve included everything you need here to setup your own game. Let me know how it went and how it could be improved!

Resources:
Retro Game – Game Board
Retro Game – Rules
Retro Game – Card Template
Retro Game – Champion Certificate

Martin aziz

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

Business vector designed by Freepik

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies

The Scrum Master and Product Owner as leadership partners

11 Comments

After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”

I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.

Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.

At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.

Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?

Recognizing the impact of change

A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.

The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.

Scrum as a form of Change Management

I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.

A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.

One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.

As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:

  • Do we both understand and support the team’s mission and goals?
  • What are the product goals?
  • How can we best help the team achieve those goals?
  • Are there any conflicts between the team and product goals?
  • When our goals or methods are in conflict, how will we resolve them?
  • In what ways will I be supporting your success as an SM/PO?
  • How will we keep each other informed and engaged?
  • Should we have a peer/subordinate/other relationship?

So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.

Dec17-368b

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Links to Agile Info

Link: Agile Coaching and Flight Instruction – An Emotional Connection

Leave a comment

My friend Mike Caspar has another great blog post: Similarities between Agile Coaching and Flight Instruction.  Check it out!

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Links to Agile Info

Another Agile Article on Slashdot – Andy Hunt has Failed, not Agile

Leave a comment

For reference, here is the link to the article on Slashdot called Is Agile Development a Failing Concept?

This article will generate lots of great discussion, but most of it will be ignorant.  My biggest problem with this is that one of the authors of the Agile Manifesto, Andy Hunt, has asserted that Agile just isn’t working out.  My opinion: Andy has failed to have the necessary patience for a decades-long cultural change.  This is a lot like a leader at Toyota saying that lean has failed because 50 years after they started doing it, not everyone is doing it properly yet.  One organization that I know of has been working on changing to Agile for over 10 years and they still aren’t “done”.  That’s actually okay.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile, Professional Development, Reference Information, Theory of Agile

Tips to Start Agile in a Hostile Environment

3 Comments

Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally.  In some cases, management may even be hostile to the concepts and practices of Agile methods.  If you are interested in Agile, you don’t have to give up hope (or look to switch jobs).  Instead, here are some tips to start using Agile methods even in hostile environments.

Regular Retrospectives

Some Agilists claim that the retrospective is actually the key to being Agile.  In some ways, this is also the easiest practice to introduce into an organization.  Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“.  These are retrospectives that can be done in 15 minutes or half an hour.  Try to do them with your team weekly.  If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting.  If you are “just” a team member, you might have to get some modest amount of permission.

So why would it be good to do a retrospective?  Because it’s a high return-on-investment activity.  For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning.   Here are a couple more articles about the importance of retrospectives:

What’s an Agile Retrospective and Why Would You Do It?

What is a Retrospective?

Practice-by-Practice

Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start.  Myself, my first formal Agile environment, I started with the Daily Scrum.  Another time less formal, I started with Test-Driven Development.  In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months.  This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders.  This is the practice-by-practice approach.  Start with a simple Agile practice that you can do without asking anyone for permission.  Make sure it is a practice that makes sense for your particular environment – it must produce some benefit!  If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start.  If you are more business-oriented, then maybe consider user stories or one of the Innovation Games.  If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.

It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another.  If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.

Stealth Project

Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy.  This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”.  This is an opportunity to do Agile.  Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.”  There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support.  In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it.  Don’t talk about it.

The “just do it” approach requires that you have some influence.  You don’t have to be an influencer, but you need connections and you need charisma and you need courage.  If you don’t have at least two of those three, you shouldn’t try this approach.  You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works.  Here are a few comments on Stealth Methodology Adoption.

Co-Conspirators

There’s nothing like working with a band of rebels!  If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work.  Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans.  Of course, you need to actually execute some of your plans.  Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.

But, like any rebellion, you really need to trust those you work with in these early stages.  Lacking that trust will slow everything you do possibly to the point of ineffectualness.  Trust means that you have, for some time, a formal vow of silence.  Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.

Read “Fearless Change”

I can’t recommend this one enough!  Read “Fearless Change” by Mary Lynn Manns and Linda Rising.  This is a “patterns” book.  It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use.  Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent.  Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.

Don’t Call it “Agile”

This isn’t really a “tip” in the sense of an action item.  Instead, this is a preventative measure… to prevent negative reactions to your proposals for change.  The words “Agile” or “Scrum”, while they have their supporters, also have detractors.  To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names.  Use another name.  Or let your ideas go nameless.  This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”.  By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.

A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”.  Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.

Get Some Training

Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program.  It’s a 40-week program that takes about 12 hours/week of your time for coursework.  The next cohort of participants starts in June 2015 and we are taking deposits for participants.  This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Kanban System Design® (KMPI)
Online
C$1895.00
Mar 22
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 24
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Mar 24
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Mar 29
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Mar 29
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Mar 30
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 31
2023
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Apr 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1795.00
Apr 5
2023
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Apr 6
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Apr 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Apr 18
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Apr 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C$1525.75
May 3
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
May 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 12
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1100.75
May 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
May 16
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
May 17
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
May 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 19
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1610.75
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details