Showing posts with label Coaching. Show all posts
Showing posts with label Coaching. Show all posts

Friday, December 12, 2014

The Socratic Coaching Approach

"The secret of change is to focus all of your energy, not on fighting the old, but on building the new." -- Socrates

I recently read "The Goal: A Process of Ongoing Improvement" by Eliyahu M. Goldratt. For those of you unfamiliar with this masterful work, it is the book that introduced the Theory of Constraints and was a primary predecessor of "The Phoenix Project" - in fact, "The Phoenix Project" not only makes mention of "The Goal", it is written in a similar style and format!

I learned a lot from "The Goal", but I was able to apply a couple of learnings immediately to my coaching: 1) The Goal itself; 2) the Socratic method. Granted, I'm very new to this and still have a lot to learn about the Socratic method, but that's not stopping me from giving it a try!

This is the basic conversation I've been having for the past couple of weeks, usually in response to "How do I convince so-and-so to be more Agile?"

Me: What is the goal of any company?
Them (usually after some thinking and a few guesses): Make money?
Me: That's right! Now, as a development center, how do we help the company make money?
Them: We provide solutions/capabilities/cost savings/etc.
Me: Okay, and when do we provide them? When we finish requirements?
Them: No...
Me: When we finish Coding? Testing?
Them: No.
Me: Then when?
Them: When we deploy.
Me: Okay, so we deliver value when we deploy. How often do we deploy?
Them: Not often enough.
Me: I agree! So as soon as we deploy something and start working on something new, we are basically just accruing expense until the day we release again. Yet, in Agile, we often find ourselves sitting on "Production-ready" code without releasing it. What are some other consequences to releasing code in large, infrequent batches?
Them: It's more difficult for our customers to handle the change. They require weeks of User-Acceptance Testing and have to build Change Management plans around each release.
Me: Precisely! Also, what happens if we find a defect?
Them: Defects can be very expensive because we find them late, which means they are large and highly impactful. Plus the defect may be something that we developed a long time ago and have forgotten about.
Me: Right. So... what I'm hearing is that when we deploy less frequently then we delay delivery of value and increase risk, both of which are contradictory to our goal to make money, is that right?
Them: Yes, exactly!
Me: So why don't we just define Agile as a mindset of striving to deliver more valuable functionality with high quality at faster rates? Then "Being Agile" means doing whatever makes sense to reach that goal. Do you think they could get on board with that?
Them: Absolutely - they'd have to be foolish not to!

Notice that I didn't say Agile until the very end. The idea is to help them realize for themselves the obvious truths that Agile espouses in a way that solves their problems or aligns with their current paradigm. This results in a more natural mindset shift, as opposed to one that feels forced or alien in a classroom environment. I've seen a lot of success with this approach so far, and I'm hoping to get even better with experience.

How about you? Have you used the Socratic approach in your coaching? What ideas, successes, or failures would you share with someone just getting started with this approach?

Friday, January 17, 2014

A(nother) Response to SAFe Criticisms: Part 1

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

Before you continue reading this somewhat lengthy, multi-part blog post, let me lay out the prerequisites. Well, really just the one. If you are not already at least somewhat familiar with Dean Leffingwell’s Scaled Agile Framework (SAFe) then this post is not going to be as meaningful to you. The official website for SAFe is http://scaledagileframework.com, although there are others out there (Andrew Blain, for example) who have done a good job of explaining what SAFe is.

Last year Dean Leffingwell (and SAFe in general) had a significant presence at Agile2013. In response, Ken Schwaber wrote a provocative blog post entitled “unSAFe at any speed”. What Ken failed to accomplish was to produce criticism that was any more founded than your run-of-the-mill angsty hearsay. He did, however, manage to set off a civil war within the Agile community over whether or not SAFe should be allowed in the Agile club or beaten until silenced or killed. I have been rather surprised at how many “Agilists” have chosen the latter.

Agile has always appealed to my inclusive nature. The goal is outlined in the Agile Manifesto and its 12 Principles. Anything that strives to deliver within the paradigm of the Manifesto and its Principles can be considered Agile. All approaches have strengths and weaknesses, and all approaches focus more on some aspects than others. In the end, though, all approaches are well-intentioned efforts to elevate teams to their potential. I think that’s beautiful, I really do.

A roadblock that has existed for years is that of large organizations who are not already Agile. Getting these behemoths to shift the way they work, much less the way they think, is no easy task. Many have taken the “All or Nothing” approach – either adopt an existing Agile approach in its purest form, wholesale, with no alterations, or surrender yourself to your competition, wither away, and die. Neither of these options is particularly appealing to most of these organizations, so they ignore Agile and continue their status quo.

Along comes Dean Leffingwell and SAFe and, all of the sudden, you have an Agile approach that the organization can use to become Agile. Of course it looks different from the other options currently available, but that’s kind of the point. It aims to establish Agile Principles and Lean Thinking in larger enterprises in increments that are actually realistic. Just as every Scrum team is different, every organization that adopts SAFe does so in its own way. And, just like Scrum, a lot of the implementation details cannot be neatly outlined in a guide or abstract for anyone to pick up and repeat without putting in any of the effort.

The reality of the situation makes the Purists out there really uncomfortable. A lot of criticism has been published. I am going to attempt to address some of this criticism. My intent here is not to get everyone out there to use SAFe. Heck, I don’t even intend for everyone to like it. My intent is to clarify a few misconceptions, first and foremost the one that SAFe is not Agile.


I’ll be publishing my response in multiple parts in order to accomplish this intent. The number of parts depends, at least partially, on you. I want to know what criticisms or misunderstandings of SAFe you would like me to respond to. I would further ask that you communicate with me as a respectful professional (and I’ll do the same). I’ve seen this topic get out of control without ever getting to root cause. Not that I have delusions of grandeur or anything, but I’d like to think that I can help find and address the root cause of these criticisms without it turning into a shouting match. I guess we’ll find out.

Series Posts:
Part 2: 25% Scrum Master
Part 3: HIP Sprints

Tuesday, January 14, 2014

Addendum: Agile 2014 Proposals

I blogged recently about a proposal I submitted to Agile2014. As the deadline for submission is today, I won't be asking for your feedback on the submission website (unless you're a reviewer for the track). However, I'd still love to hear your thoughts here on the blog!

Additionally, I have assisted a co-worker with putting together 3 additional proposals as co-presenter. I'd like to share the information on all of these proposals here with you now. I cannot over-emphasize how much I want to hear what you think about them!


Practical Application of Dude's Law: Come Play the Value Estimation Game!

Abstract:

You know how you determine the "bigness" of your work and establishing commitments, but how do your customers ensure you're committing to the right thing?
Come experience relative estimation to determine value. We'll use David Hussman's "Dude's Law" (Value = Why? / How?) to prioritize the work.
We will share techniques for determining the "Why?" so that you can generate a Value Index. What many people will be surprised to learn is that they already have tools for sizing that can be used for determining value and prioritization.

Information for Review Team:

The break-out of the 75 minutes would include:
3 minutes: Introduction to Dude's Law and the Value-Driven Heuristic
10 minutes: Explain and model the first exercise (Team Estimation Game for relative sizing)
10 minutes: Have round-table teams execute first exercise with a set of 10 features
5 minutes: Explain and model the second exercise (Team Estimation Game for relative benefit - same mechanism, so it takes less time to explain and model)
10 minutes: Have the round-table teams execute second exercise with the same set of 10 features
10 minutes: Have each team determine the Value Index of each card by applying Dude's Law
15 minutes: Have teams share their outcomes, insights
12 minutes: Explain the flexibility of Dude's Law (you can use Planning Poker or whatever technique works best for you) and introduce them to concepts such as Weighted Shortest Job First and Value Dial weighting*

* As this section is the least important it may be reduced or eliminated if previous sections run long

Prerequisite Knowledge:

The concept of Relative Sizing (Story Points, T-shirt sizing, etc.)

Learning Outcomes:

1.       Experience and learn how to apply a practical, proven game for prioritizing your work based on value
2.       Understand that using a heuristic for valuation is better than both gut-feel and over-engineering
3.       Understand that, as with estimating size/cost, the real value comes from the conversation

Presentation History:

I've done the Team Estimation Game dozens of times before with as many teams and have done the exercise including benefit to determine a Value Index with at least one of those teams. I also have led Program Management teams through a very similar prioritization matrix model that leverages the concept of Weighted Shortest Job First.

Comment:

My presentation is a reflection of my own beliefs and experiences. None of the material I present should be interpreted as an endorsement by my employer. I have received express written permission from David Hussman to reference Dude's Law, and I am a Certified SAFe Program Consultant (SPC), which qualifies me to speak on their Weighted Shortest Job First (WSJF) Framework.


The Secret Sauce of Agile

Abstract:

Humans are basically moist robots. As much as we like to think that we are logical, rational beings, we really aren't. The best thing we can do to improve our decision-making is to influence our environment and develop skills that will increase the odds of making the right decisions.
Beyond the techniques, practices, principles, and even beyond the manifesto; that's the secret to Agile success. Through dialog, games, and an open agenda, we'll explore that secret. Together we'll find the next evolution of Agile via application of that secret.
The foundations of Agile are human centered and scientifically backed. To get the most out of Agile and to leapfrog beyond it, we need to understand how Agile works. It's the wiring of our social minds, the relationships, tacit knowledge, and our predictably irrational natures that ensure Agile success and doom all other approaches. So, what is that secret sauce that mix of ingredients?

Information for Review Team:

Introduction (7 minutes)

We will discuss the hypothesis that influencing those factors that determine our decisions is a more effective use of time than simply exerting willpower to make correct decisions. We will introduce factors of significance that we have already found and invite the audience to provide others.

Mind Mapping (50 minutes; up to 10 minutes per factor)

We will use mind-mapping to explore what we can do, as practitioners and coaches, to increase our odds of success by influencing:
1.       Knowledge and skill-set (what knowledge, if internalized and applied, will help us make the right choices?)
2.       Environment (How can we modify our physical environment to make us more successful?)
3.       Chemical makeup of our bodies (What foods, drinks, and activities make us more likely to succeed?)
4.       Removal of guesswork (What decisions can we make when in a "rational" state that will lessen the impact of impulse decisions when we're "irrational", i.e. conflict protocols, etc.?)
5.       Others as identified by the audience

So What? (Remaining Time)

Use the information to help those in the audience generate actions based on their new knowledge to help their teams and organizations succeed. This is not a theoretical exercise; this is an Inspect & Adapt exercise rooted in human psychology.
We are prepared to adjust the presentation style depending on the seating arrangement; we can make both work well.

Prerequisite Knowledge:

Deep experience with breathing

Learning Outcomes:

1.       Learn the success secrets of Agile embedded in human behavior, social science, and the way we're wired.
2.       Learn to use science and human nature to go beyond Agile.
3.       Walk out being able to use your knowledge to be more successful with Agile.
4.       Move to the next evolution of Agile.

Presentation History:


This is a new approach that we're experimenting with currently with small teams and leadership groups. The agenda is loose because every group is different and responds differently; our goal is to let those present take ownership of the meeting and take it where they need it to go.


Flexible IT Using Enterprise Kanban

Abstract:

We will walk through multiple examples of how to setup visual signaling systems to replace the wasteful reports, meetings, management, tools currently used to track, prioritize, manage, and control portfolios, investments, programs, and projects. This talk will describe the essentials of how IT can adapt to massive disruptions. The story comes from one of the world’s largest companies. We've altered things to form a generic story; but the techniques are proven, simple, working and effective. These disruptions are constant major shifts in technology and business that have been canceling and starting new programs / projects for years.
Big data, competitive innovation, mobility, leverage, and fluxes in profit and loss have had huge impact over IT. Consider having to building a data center, starting a big data pillar with hundreds of specialists, and dropping large portions of budget all at the same time. These disruptions cannot be planned for their adaptations in response to technology, financials, and business changes.
To protect the innocent, this story details in this discussion have been formed in the form of a story. However, this leverages stories from a successful implementation of enterprise kanban at a major retailer. The approach is so simple it may not seem realistic. But stories of dealing flexibly with disruption are becoming common. Our stories will be richer and will have more real without any complexity. This story leverages a chain of values, decentralized and centralized decision-making, transparency, collaborations, evolutionary architecture, and innovations. These form the backbone for allowing a simple kanban system manage the flow of a flexible approach to dealing with global, enterprise disruption.

Information for Review Team:

Ideally, this would use large post-its and sticky notes with strings in a live demonstration. Our current system uses LeanKit; but we'd like to present tool agnostic.
The break-out of the 75 minutes would include:
5 minutes: Introductions - A story of 5 Continuous Crucial Conversations
5 minutes: Pre-requisites to Flexibility
5 minutes: Disruption – Innovation – Zero Click Shopping
5 minutes: A Flexible Response –Enterprise kanban in Action
5 minutes: Business Leadership - Reprioritize IT funding (Business Investments)
5 minutes: IT Leadership – Adjust IT capacity and create big requirements– (epics)
5 minutes: Domain Leadership - Breaks big requirements into pieces, rank, and distribute work (sub-epics)
5 minutes: Team of Teams Leadership - Form domain teams, Break sub-epics, and rank (features)
5 minutes: Teams - Break features into stories, Deliver solution parts (stories)
5 minutes: Enterprise kanban as an Innovation engine
5 minutes: Enterprise kanban supported by Lean IT & Kanban Services
5 minutes: Enterprise kanban as an Execution engine
15 minutes: Q&A

Prerequisite Knowledge:

Have to have worked in mindless, massive, and. Mismanaged companies. Need to have intimate, firsthand knowledge of corporate waste, stupid status and other mindless bureaucracy. Must have years of experience trying to do the right thing while working with overly complex, boring and unproductive program and portfolio management policies, processes, methods, tools and people.

Learning Outcomes:

1.       Walk out being able to setup a simple, flexible way to connect the effort of teams of teams.
2.       Trace funding, strategy and progress to value delivery.
3.       Increase visibility and communication while decreasing reporting, meetings, and planning.
4.       Know how to use enterprise Kanban to replace status reports, time sheets, and management.
5.       Having talking points and examples that will help you set your organization free of vanity metrics, over processing, and micro management.

Presentation History:

Not formally presented outside the company internal Agile User Group


Leading Agile Transformation from a Beach: 2 Agile Coaches’ Journeys

Abstract:

Todd and Mike have both experienced the growing pains that come from becoming Agile and helping others with the same. They had similar experiences and learned similar lessons, but their journeys have been surprisingly different. One took 15 years, the other took 5, and both took longer than they had to.
This is a story of what not to do, what to do, and how do it by not doing anything. It pulls from at least six multi-year Agile transformations in some of the world’s largest companies. We'll share our experience in a story that is sometimes funny, mostly true, and utterly real. We'll save you from failures, help you see new ways of transforming yourself, teams, companies, and cultures. Or, perhaps, we'll just provide a self-affirmation opportunity for you to confirm that what you are doing is much more intelligent than what other Agilists have done.

Information for Review Team:

May have to protect names to save the innocent and spend less on legal fees. Combined transformation experience of almost 2 decades covering thousands in major companies and consulting firms.

Prerequisite Knowledge:

Must have lead an Agile transformation of a team, set of teams, company or, that hardest of all Agile transformations - yourself.

Learning Outcomes:

1.       Build confidence
2.       Teach you how to transform without working
3.       Help you avoid stupid transformations

Presentation History:

First time for this one. Parts shared at PMI chapter and local Agile User groups.

Attachments:

Thursday, January 2, 2014

New Year's Resolution: Kaizen!

If old acquaintance be forgot and never thought upon then you're not holding retrospectives correctly.
I've never been a fan of making New Year's Resolutions - their short life spans are clichéd for a reason. I've also been reading Scott Adam's new book "How to Fail at Almost Everything and Still Win Big", and one of the major themes in the book is that goals are for losers; winners use systems. This resonates with the Agile principle of continuous improvement through inspecting and adapting.

So my New Year's Resolution this year is not a goal, but truly a resolution. I resolve to exercise personal Kaizen. Continuous improvement has been a major part of my life for as long as I can remember, but it hasn't always carried the urgency associated with Kaizen. I'm going to experiment more so that I can fail more so that I can learn more. I'm going to schedule Introspectives (1-person Retrospectives) on a regular basis whereby I can challenge my own personal status quo.

I wouldn't be an Agile Coach if I didn't encourage each of you to adopt Kaizen as a New Year's resolution as well. If you don't like the commitment associated with that term, can you commit to trying it just for January? Each Friday in January, I challenge you to hold your own Introspective. Ask yourself what you did well and what you could have done better. You may have made good decisions, but did you make the best ones? Did you have an answer for each time you were asked "Why"?

I'll be sharing the results of my own Introspectives every Friday this year. What I share may not be comprehensive, seeing as how I don't have the time to write out all the context for my results, but I'll share as much as I can within reason. I'll also work hard to blog frequently between Introspectives in an attempt to get more of a dialogue going than I've been able to in the past.

If you decide to take on my challenge, please share your results with me. You can comment on my blog, message me on LinkedIn, or tweet me @MLCarey321. I'd love to see the effects of personal Kaizen in your life!

Tuesday, November 19, 2013

When NOT to Use Agile

When HealthCare.gov first rolled out, everyone experienced how terribly it was built. Many Agile enthusiasts cried out, “If only they had used Agile…!” We have since learned that HealthCare.gov used Scrum. It’s uncertain how superficial their adoption was. Michael Daconta has already done a great job describing their poor use of Agile methods in the GCN blog, and NPR has published findings from the McKinsley & Co. consultants who were brought on in March to do a progress report.

My focus here is not about the degree to which Agile was or was not properly used for HealthCare.gov. My focus is to debate under what circumstances, if any, Agile will not work. When would you NOT use Agile?
My assumptions for this debate are as follows:
  1. Agile is any processes, practices, tools, and frameworks that comply with the Agile Manifesto and its 12 Principles.
  2. In the spirit of healthy debate, I assume the audience to be open to the possibility of new and different ways of doing things. This applies particularly to both Agile skeptics and to those entrenched in a specific Agile approach.
  3. The ideas in this discussion are not etched in stone. I encourage you to share your own ideas so we can learn and grow together.

Possible Agile Risks

I was recently invited to an introductory Agile presentation. The audience was Project Managers with varying Agile knowledge and experience. It facilitated a conversation for answering questions and resolving concerns around Agile adoption. About halfway through, there was a slide that had five “Possible Agile Risks”:
  1. Business or management commitment
    • Agile requires an increased level of commitment from the business and IT management to be successful
  2. Remote or distributed teams
    • Agile benefits from close collaboration on a consistent basis. Distributed teams pose a challenge in the effort to do this effectively
  3. Remote product owners
    • The business must be consistently involved, so a remote product owner may be challenging to engage
  4. Balance delivering new features with high-quality, sustainable code
    • Agile delivers new features frequently, but this should never come at the expense of creating low quality code
  5. Team not provided adequate guidance as they implement Agile
    • Anything new will take time to get good at, it is important to supply the team with training and guidance so they can improve quickly

This disclaimer followed these risks: “These risks do not preclude teams from applying Agile; they just need to be addressed in the scenarios they are present.”

Before we get to my reaction, let’s walk through these risks. Let’s identify why they’re risky in an Agile environment.

Business or Management Commitment

A deep understanding of the business is essential to the success of the software that supports it. In Agile methodologies, this means a dedicated person who has a deep understanding of the customer’s needs, often called a “Product Owner”. Traditionally, this person is seen as “from the business side”. However, getting someone from the “business side” isn’t always possible and is, arguably, unnecessary.

In my area we have Business Analysts who understand the business needs. They are bilingual in business and IT speech. Our developers and testers have a deep business understanding of the business because they’ve been supporting it for a long time. Some Agile practitioners feel the Product Owner role is unnecessary; they believe the team should understand the customers’ needs better than anyone. The team can, therefore, manage the work themselves.

In Agile, management is not a clearly defined position. Managers may feel their job is threatened by a “self-managing” team. A manager must have the team’s best interests at heart. They must become Lean-Thinking Servant Leaders, not Command-and-Control Managers. This is a cultural shift from Waterfall. Agile teams without Servant Leader management will plateau until they are allowed to “self manage”. However, that doesn’t mean they can’t find some measure of success.

Remote or Distributed Teams

This is one of the first and most frequent challenges brought up when introducing Agile. A team is distributed when its members are not capable of frequent face-to-face conversation. Lack of co-location for an Agile team is a challenge, no question. However, modern tools such as IM-enabled ad-hoc video conferencing, digital code review tools, etc. make long-distance coordination much simpler. It may be hard to work out timing with time-zone differences, but it’s possible to have a time overlap for some real-time collaboration. This may result in having a tech lead that takes the brunt of the development’s complexity to reduce the need for collaboration among the other team members, though this will limit the team’s overall productivity.

Remote Product Owners

For this I say, “See my previous 2 sections.” However, perhaps there are situations where the team is new to the product? Perhaps the SMEs are remote? Even worse, what if those remote SMEs do not dedicate time to work with the development team? Wait, what on earth are you thinking? Seriously, this is a bad idea, regardless of methodology. You are stacking the deck against yourself and setting the team up to fail.

Balance New Features with Quality Code

One of the 12 Agile Principles states, “Continuous attention to technical excellence and good design enhances agility.” Delivering new features at the expense of quality is the technical equivalent of being “penny wise, pound foolish”. This may be faster short-term, but the long-term consequences are a slow-down of delivery. Without addressing the quality of the application, it will eventually be cheaper to replace the application than to fix it. This isn’t unique to Agile. This brings me to my initial reaction to ‘Possible Agile Risks’.

My reaction to "Possible Agile Risks"

When I first saw this list, my reaction was that the first four are not “Possible Agile Risks”. Instead, they are “Possible Software Development Risks”! The four risks of commitment, distributed teams, remote product owners, and quality are often associated with Agile development because Agile brings risks to light early. Agile makes it much more painful to ignore risks than to address them. They are not less risky with non-Agile approaches. In fact, the realization of these risks is more likely in a non-Agile approach. In Waterfall projects, risks manifest so late in the process that they are painful and expensive to fix. The first four are risks to all projects; but not necessarily the fifth and final risk on the list.

Agile Training and Guidance

Without proper training and guidance, it is difficult for those unfamiliar with the Agile paradigm to be successful with an Agile approach. Most people new to Software Development find the Agile way of thinking to be a more intuitive and human-centered. In those cases, there is less risk because less training is needed.

Those entrenched with Waterfall approaches will find it difficult to switch gears. This is the only risk I could concede as being a “Potential Agile Risk”.

Where’s the Risk?

So there are my thoughts on five risks commonly thought to make Agile less successful. I have yet to find a risk that is made any less risky by Waterfall. Does that mean Agile’s guaranteed to succeed? Absolutely not. In fact, Agile will push you to your limits. Then, right as you’re starting to feel comfortable, it pushes you some more. However, Agile will consequently turn your team into the best team they can be. Agile will expose risks and inefficiencies sooner. It will also make them more painful. As long as you don’t ignore the pain, taking care of those risks and inefficiencies will be less expensive because they are dealt with early.

But hey, maybe I’m wrong. What risks have you heard associated with Agile? What situations are wholly inappropriate for the basic tenants of the Agile Manifesto?