RSS

Can we get out off the Agile weeds?

I’ve been having far too many conversations regarding Agile frameworks, their implementation, and scaling recently. It seems to me that a majority of agile coaches and their clients seem preoccupied with rituals over results and I get the sense that people are too mired in the weeds and losing sight of the few basic things needed for becoming a more nimble and customer centric organization. So, here are some things to ask yourself:

  • Are we truly a customer centric organization? Do we actually get out of the building enough to understand our customers, their needs, their problems, and how they use (and struggle with) our products. Can team members do a “follow-me-home” or some other customer discovery practice – journey maps, customer interviews? Are product teams primarily focused on gaining customer insight in order to better meet their needs? Do we even care about customer delight?
  • Are we open to disrupting ourselves without the motivation of a crisis? Does our culture allow us to preempt crises, without much drama, by reinventing products and services offered or by changing the existing business model? Or are we complacent and reactive and buffeted by what are competitors are doing?
  • Do we have true business and IT partnership? No, I don’t just mean that a PO sits with the team or that there is a Product Manager who ensures that her POs are aligned on the order in which to build the identified features. What I mean is that the business folks and IT have the same goals, the same targets, the same key metrics – and that they together focus on the same desired outcomes (and not just the outputs). Think X-Matrix and OKRs here. Think collaboration (in the true sense of that word) and not just communication, cooperation, or coordination. Think the CIO meeting daily with the Chief Marketing Officer (CMO) to strategize.
  • As a company, are we good at making accurate decisions quickly? Can we get the right information to the right people making the right decisions at the right time? Can we provide the decision makers with relevant and timely feedback about their decisions? And then, do we encourage them to learn from mistakes and improve?
  • Do the IT folks sit together with people from Product, Marketing, UX, Finance, and Operations so that we have true cross-functional product teams? Do these product teams (small, collocated, long-standing, cross-functional) have the autonomy to determine their own best solution to meet the defined goals? Do they have license to experiment and learn? Do senior leaders trust them to do the right thing?
  • Are we providing open collaborative spaces for the collocated product team members? Or are we still struggling with ineffective communication amongst the distributed and/or dispersed team members?
  • Are teams keeping design simple and writing good code? Can they rapidly get feedback by integrating and deploying continuously? Can they release on demand? Do they demonstrate their working product frequently to their stakeholders and to their customers? Yes, inviting real customers to a demo is a good idea.

You’ll notice that these are independent of any agile framework used. You can actually start improving on all of these without even using the term agile. So what’s keeping you from moving off the rituals bandwagon and focusing on what truly matters?

 
Leave a comment

Posted by on November 24, 2017 in Agile, Improvements, leadership

 

Tags: ,

Executive Conversations At the Start of a Transformation Effort Are Key

To have a decent chance of leading a successful change effort it is imperative to have the right conversations, at the start, with the executives and stakeholders who will be instrumental in the success of the transformation effort. While starting at the team level and focusing on the process introduction is far easier, it is also the riskiest strategy long-term.

So what might you want to do during the initial session:

  • Ensure that the executives and sponsors are clear on why they are embarking on their Agile journey. Remember that Agile practices and methods are just a means to an end and not the end itself. Additionally, most transformations fail because people treat them as transitions instead — you want to make sure the leaders understand the difference between the two.
  • The leaders also need to be clear on what outcomes (quantified where possible) they want to achieve.
  • Change efforts succeed when leaders actively lead the change and remove barriers to higher performance. You may want to talk about the three key components of organizational agility — (1) leadership agility (how leaders lead, inspire, direct, and motivate others), (2) organizational structures (structures, rules and policies that facilitate how work gets done and how results are produced), and (3) organizational culture (collectively held beliefs, values, and assumptions that determine how people think and how they behave) — and how they themselves need to approach the leadership work differently.
  • Ensure they understand the concept of looking at things holistically — discovery, development, delivery, and leadership and how each affects the other.
  • Lay out at a high-level what the incremental goals might be — moving from tactical to strategic to aspirational.
  • Check their level of commitment on a 1-10 scale, where anything less than 8 indicates wavering commitment.
  • If committed, introduce the concept of an enablement team and ask them for recommendations on who should be on that team.

Make sure you keep engagement high — have the leaders work through exercises that get them up and collaborating.

Bottom line — in my experience, two to three hours spent with the executives and sponsors early on will prevent hundreds of hours of pain and suffering later on. What have your experiences been?

 
Leave a comment

Posted by on November 9, 2017 in Coaching, leadership

 

Tags:

Decentralize to be more nimble

Flattening the organization (i.e., reducing layers of middle management) by itself is not the answer to becoming more nimble. Flat organizations are still steered by the remaining managers and not driven by market pull.

Delegation is a small step in the right direction; however, decisions are still made by lower level managers and not by self-organizing teams nor those closest to customers.

Decentralized organizations, however, encourage decision making at the boundary where customer or market interaction occurs. Learning is fast, decision making swift, and pivoting easy. TJ Maxx is an example – purchasers can make on-the-spot decisions without prior approval or permission from head office. Contrast this with purchasers from other retailers who are bogged down with long-term contracts and have little leeway in who from and what they can purchase. Not surprisingly, TJX is one of the two retailers in the US growing despite a tough environment.

 

 
Leave a comment

Posted by on July 31, 2017 in leadership

 

Tags:

The Toyota Way to Lean Leadership

In partnership with George Trachilis from the Lean Leadership Institute (LLI), I’m making available material from LLI’s “The Toyota Way to Lean Leadership” course. Check back every week for a new chapter from the course.

Week 17: A3 Examples: Standards, Standard Work, and Visual Management
Week 16: More A3 Stories
Week 15: A3 Stories
Week 14: A3 Thinking
Week 13: Why PDCA?
Week 12: Problem Solving to Develop People
Week 11: Root Cause Using 5 Whys
Week 10: Toyota Business Practices – An Example
Week 9: Toyota Business Practices Explained
Week 8: Problem Solving Towards Ideal Part I and Problem Solving Towards Ideal Part II
Week 7: What is Lean? Problem Solving, Improvement, and A3 Thinking
Week 6: Developing People
Week 5: Lean Thinking—Philosophy for the Long-term
Week 4: True North Values
Week 3: Toyota Production System Origins
Week 2: Problem Solving: The Toyota Way
Week 1: Great Company Characteristics

 
Leave a comment

Posted by on July 31, 2017 in leadership, lean

 

Tags: ,

Agile Transformation Learning Curve

Many a time, I’ve brought up the conventional learning curve (J-Curve) to help agile champions understand that there will likely be a dip in productivity while adjusting to the new lean-agile way. This dip is followed by a rapid increase in effectiveness and efficiency as the new approach is mastered and finally culminates in a plateau at a higher level.

While I’ve seen this J-Curve (on the left in the image below) unfold countless times with team members making the transition to agile; I’ve seldom encountered this with managers in large organizations. A different dynamic plays out and the transformation’s learning curve looks slightly different (on the right in the image below).

Sketches - 3

In the right hand figure, there is an initial improvement that is driven by an illusion of learning. In this stage, managers have had some introductory training and the organization has mastered the rhetoric of the new approach. People know enough to be dangerous and spend some effort in grafting the new way onto the old organizational approaches — but the same old premises are at work. While there is much activity nothing new is being done by management — no new approaches to problem solving, decision making, budgeting, horizontal relationships, etc.

The initial rise in effectiveness/productivity stalls and subsequent introspection leads to a sufficient understanding to see that “we don’t really know much.” This “A-ha!” experience is the beginning of the integration of acquired knowledge with know-how. It leads to a reset — a new beginning — and the start of real learning that results in a rapid increase in effectiveness.

I know real learning has started when I begin noticing signs of managers asking smarter questions and applying the principles learned earlier to current circumstances.

What has been your experience? Do you see this primarily in large organizations or is this a universally predictable pattern?

 
Leave a comment

Posted by on July 10, 2017 in Agile

 

Tags:

Misplaced Agile Transformation Priorities

Most companies that I’ve worked with begin their lean-agile transformation effort by attempting to fix/improve the development teams. However, the source of most of the problems lies either upstream (lack of sequencing of work, demand far outstripping capacity to do the work, suspect value of work requestsed, etc.) or downstream (lack of environments, wasteful and onerous deployment processes, etc.) of the development teams. And, of course, management struggles in creating an environment that is conducive for high-performing teams is well known and another area for improvement.

A significantly better approach would be to start with introducing the CALMS conceptual framework (culture, automation, lean, measurement and sharing) for driving the integration of development, support, operations and business. Over time, plan and prioritize initiatives and improvement efforts to move each of the CALMS elements forward. Simultaneously, work with the business and with stakeholders to better define and sequence customer-valued increments of functionality.

You have a higher probability of making meaningful improvements and moving the needle on the busniess metrics that matter by changing your starting point. What have your experiences been?

 
1 Comment

Posted by on May 15, 2017 in Agile, Coaching, Improvements, lean

 

Six levels of waste

In a WhatsApp conversation, Charles Protzman, co-author of, “The Lean Practitioner’s Field Book” shared how he categorizes wastes. His words:

We have categorized waste into six different levels:

  1. The first level is obvious waste: low-hanging fruit (or walking on it).
  2. 5S wastes: the easiest wastes to see.
  3. The seven (eight) lean wastes.
  4. Boiled frog waste: the waste that is hard to notice because it is old and we pass by it every day.
  5. Tribal waste or sacred cows: untouchable waste in our culture and systems.
  6. Hidden unseen waste: waste we don’t typically see, as it is hidden behind or masked by other wastes; you really have to hunt for it! The hardest waste to find and yet the most dangerous.

To #3, I would add and emphasize the knowledge work wastes of scatter (lack of focus), hand-off, wishful thinking, reinvention, and lack of system discipline to make the list more relevant to software development.

This is a really good list. What do you think?

 
Leave a comment

Posted by on February 22, 2017 in Improvements

 

Tags: , , ,