Attributes of an enlightened-ish leader

Leaders and Followers

When adopting any method or framework (e.g. Scrum, lean, orTameFlow), organizations need a leader that believes in both the journey and the destination. The recent thread on enlightened self-interest and enlightened leaders cast doubt on how much enlightenment is really going around.  Whether a leader is enlightened or just seems that way because they are on the right side on an issue we are passionate about is less important than studying how they behave. There are five attributes of a leader that impact the direction and adoption of change. They are:

 

Agile Teams In A Waterfall Environment: Reactions

The idea of an agile team toiling away trying to be agile in the face of a waterfall organization evokes a huge amount of passion. 

 

SPaMCAST 612 I Am An Agile Guide, A Conversation With Woody Zuill and Allan Kelly

 

The Software Process and Measurement Cast 612 features a conversation with Woody Zuill and Allan Kelly on the topic of being an agile guide. I have felt that the term coach was overused for more than a few years. Woody and Allan put a voice to a topic that I started writing about earlier this summer describing the term ‘agile guide’. Over the past 14 years, there have been a number of conversations that changed how I think and work.  This is certainly one of those gestalt moments.  

 

Agile Teams In A Waterfall Environment: Steps Away From Fixed Everything Work

A waterfall precedes and follows rapids

In Agile Teams In A Waterfall Environment: Fixed Budget, Fixed Scope, Fixed Date, I talked about a panel discussion that I participated in that was asked: 

“We have been presented with a project with a fixed budget, fixed scope, and fixed date — can we use agile to deliver this project?” 

Interpreting the question as can we “be” agile, the answer is no (heck no if you want to be emphatic).  However, does that mean we need to take our ball and march off the field — never to be or do agile? Again, the answer is also heck no. There are several strategies that a team or even an organization can take to make progress toward a better way of working. 

 

Agile Teams In A Waterfall Environment: Fixed Budget, Fixed Scope, Fixed Date

A waterfall precedes and follows rapids

I recently participated in a panel discussion that was presented with the question: 

“We have been presented with a project with a fixed budget, fixed scope, and fixed date — can we use agile to deliver this project?” 

A bit of context, the work was not a simple request that had been done many times and the software team had not had access to the ultimate customers that requested the work before the scope, date, and budget were set. Unfortunately, this is not the first time I have heard this question this year. The simple answer is that the team can’t be agile in this scenario although they may use specific agile techniques. Just using techniques doesn’t make you agile. One of the reasons the ‘you can’t be agile’ answer is so easy in this scenario is that this type of project explicitly clashes with two of the values in the Agile Manifesto. They are: 

 

SPaMCAST 611 – Operational Anti-Patterns with DevOps Solutions, A Conversation With Jeff Smith

Play Now!
Listen and Subscribe on Apple Podcast
https://bit.ly/3fmn1IAListen and Subscribe on Google Podcasts

The Software Process and Measurement Cast 611 features our conversation with Jeff Smith. Jeff and I talked about his new book, Operational Anti-Patterns with DevOps Solutions. Our conversation branched out to cover DevOps and how writing a book changes your perception of life. The conversation was the most clear-eyed and penetrating conversation on DevOps I have had on the podcast. Jeff challenged all of us to recognize that we can make a difference.

 

Does Agile Deliver Value? Yes And You Can Prove it!

I participated in a panel today that had to wrestle with the question of why companies use agile. There are lots of good reasons, including improving delivery performance, increased ROI, and higher retention.  What is generally missing is context-specific proof. Realistically, all of the magazine articles or happy stories from consultants trying to sell you on adapting agile (or any other framework) pale in comparison to the ability to measure the impact of change. Which brings me to a re-edited version of an essay published two years ago.  

Does Agile Deliver Value? Yes And You Can Prove it!

Organizations and teams embrace a framework or technique for a purpose. That purpose is generally to address a real or perceived problem.  When you get very specific, each change is done for a different reason.  When teams or organizations are asked whether they attained their goals, solved the problems they intended, or realized the promised benefits, very few have gathered more than a handful of success stories before losing focus and moving to the next big thing. Unless you can answer whether the framework or technique delivered tangible value,  leaders will be reluctant to spend money on changes.  Best practices are a point in case.  Best practices are, by definition, practices that some have found useful (or at least that someone has professed are useful).  Every process improvement and/or best practice adoption that is not legally mandated needs to follow the following high-level feedback loop.

1. Decide why you are making the change and what the outcome of the change will be in tangible terms. Developing a solid reason for why you are making a change may sound like a trivial step, however, the rationale will often directly impact the passion for making the change. People pursue survival changes with a lot more vigor than incremental quality of life improvements.
2. Develop a hypothesis of why the change you are making will satisfy the rationale for the change.  Changes that actually work rarely are the outcome of magical thinking or dumb luck. If there is no logical reason the change you are proposing will have an impact you are very likely wasting time and money.  Use the scientific method!
3. Set SMART goals that will be used to track and evaluate the change.  As a reminder, SMART stands for specific, measurable, achievable, relevant, and time-bound.  The goals should cover the journey and outcome based on the hypothesis crafted in step 2.
4. Benchmark the process you are changing.  Consider collecting data specific to the change and data to evaluate the impact on the overall system.
5. Make the change.  You still have to make and support the change.  Your journey measures will be helpful to make sure that the change is being implemented well.
6. Collect the data to show the impact (compared to the benchmark developed in step 4) for several cycles after the change has been implemented.
7. Use the data you collect to tune the process. Pick a feedback loop and tune the process.  Rarely are major changes perfect right out of the box.  Using feedback to tune the process helps to ingrain the change and to make sure it is delivering value.
8. Report your findings.  Share the impact with everyone involved.  Positive data will help to reinforce the change and will help sell the next round of changes.  In scenarios where the change doesn’t deliver value reporting reinforces the principle of transparency.  If a change doesn’t deliver, don’t double down on a failure; revert back and try something else.

People make changes to how they work on a daily basis.  Some changes are minor and, in some cases, are not worth developing a full-scale proof of impact. For example, deciding on whether to order grilled tofu or pizza for the team lunch doesn’t require a proof of impact.  Some large-scale changes like adopting Scrum, Kanban, or DevOps require a great deal of time, focus, and money. It makes sense to be able to answer the question of whether you got what we thought you would get with something more substantive than a shrug.

Notes and Afterthoughts:

The world has changed substantially since January 2018, but knowing whether you are adding value, regardless of the definition, is even more important now!

www.tomcagley.com is up!  The site is a work-in-progress.  I would like your feedback so I can prioritize next steps (a minimum viable product has to grow or it will wither).

 

Directive or Non-directive Coaching: Why Everyone Needs To Know

The discussion of whether a coach is using a directive or non-directive coaching approach is not an academic discussion. As a person that has held internal and external coach positions, the primary reason to explicitly understand the expectations of the role and how those expectations can evolve is so that you can manage those expectations. As noted in Directive or Non-Directive Coaching, coaching one way or the other is neither good nor bad depending on the context. The big but is that when a person, team, or organization expects or needs you to act one way and you act the other things go awry.  Three basic scenarios can be used to illustrate when one approach is indicated over another. They are: 

 

SPaMCAST 610 – Organizing Around The Product Flow, Agile or Traditional, Pick One, Conversations and Essays

Play Now!
Listen and Subscribe on Apple Podcast
https://bit.ly/3fmn1IAListen and Subscribe on Google Podcasts

The Software Process and Measurement Cast 610 features our essay, An Agile Team In a Waterfall Company – Organizing Around The Product Flow. Focusing on getting features and support for a product to market changes how teams and groups organize to solve business problems.  This is a standalone essay that can be read as part of a larger theme covering the trials faced by an agile team in a waterfall company.  The four separate essays can be found at: 

1. An Agile Team In A Waterfall Company – https://bit.ly/3hXpPy5 
2. Postponing Commitment – https://bit.ly/3dBhCfl 
3. Values, Principles, and Behaviours – https://bit.ly/2ZsoO8t 
4. Organizing Around The Product Flow – https://bit.ly/3k05jhj 

We also have a visit from Susan Parente with a discussion that I have named, Agile or Traditional, Pick One!  Many organizations have to make accommodations for mandated classic project management approaches. Susan provides excellent advice for making these types of scenarios work. 

 

Directive or Non-directive Coaching

Move you head this way!

The word coach is used so indiscriminately that the meaning is hard to discern. Saying you are a coach still sends a signal, but the signal is at the mercy of the person that hears the term and it might not be what you’ve intended. In Agile Coaching Techniques: Styles of Coaches we used two different coaching approaches to define a continuum: directive and non-directive.  We used athletic coaches to mark the directive end of the spectrum and life coaches to mark the non-directive end. Each style has a very different approach to involvement.

To get a sense of how the market is leaning on the coaching involvement level scale, I grabbed a handful of job postings from LinkedIn from the US (some from the East Coast, Central Plains, and West Coast). I pulled out the job requirements and sorted them into categories. These categories could then be interpreted as directive or non-directive based on the verb they used.  For example, if the requirement used the active verb “manage” I put the requirement in the directive column. Verbs like advise and mentor I put in the non-directive category. I threw out things like projects and activities to be assigned as needed.

Coaching styles, as noted earlier, can be separated into two macro styles: directive and non-directive.  The basic approach of a directive coach is to “tell, show, do.”  The coach will teach the coachee (individual or team) how to perform a behavior or ceremony, then demonstrate, and then oversee the coachee performing the activity. The train-the-trainer approach used for transferring the knowledge to teach classes is a form of directive coaching. In directive situations, the coach needs to have deep levels of knowledge about the subject matter. For example, if you were coaching a team on behavior-driven development (BDD) you need an understanding of not only the theory but the practical knowledge of how to write and execute BDD tests.  

Directive job requirements included action verbs such as: 

• Enforce,
• Implement,
• Lead,
• Manage,
• Methodologist,
• Participate,
• Improve (process), and
• Measure.

The basic approach of non-directive coaches works by helping the person or people they are coaching to discover and apply their personnel experience to solve their problems.  Alyssa Adkins, the author of Coaching Agile Teams, uses the phrase, “ask the team” which is reflective of non-directive coaching. This style is very popular in agile circles.  

Job requirements whose action verbs include one or more of the following were judged as non-directive:

• Facilitate,
• Mentor,
• Coach (this feels like defining a word with the word being defined), and
• Train.

Even though the non-directive style of coaching is more popular in the agile community, the small sample of job descriptions include substantially more directive type responsibilities (about a 60/40 split). Styles are just styles; I have used directive and non-directive techniques. The context and my agreements with the people involved provide a way to navigate between the two camps.  

August 4:  Why understanding style matters

August 6:  I am an agile guide