Showing posts with label mindset. Show all posts
Showing posts with label mindset. Show all posts

Wednesday, March 29, 2023

The Meta of getting to Small in an Agile World

If you are Agile in the Product delivery and software development space, there is strong emphasis on thinking small.  This means decomposing work to small pieces to allow for iterative and incremental delivery and eventually the continuous flow of work. While this sounds straight-forward, in practice, it is hard because it disregards the challenging mindset shift that must occur to get people to think small. 
It is important for Agile teams, coaches, and leaders need to understand for those who have never decomposed their work to “small” size chunks, they have little idea what that means and it may take time. This article focuses on several reasons why “decomposing the work to small pieces” is challenging and the meta surrounding the concept of small.

Small is mindset shift  

Imagine that you have never considered what is small and someone says, “think small!”  This is meaningless without any context or experience in “getting to small”.  To achieve the concept of understanding small bite-sized pieces or work, there is mindset change that must occur.  Imagine if you were piloting a plane for the first time and your instructor says, you must go “fast” to take off.  What does fast enough mean if you’ve not done this before? If you only ride a bicycle, then fast may mean 25 mph (or 40 kph). However, in order to take-off, fast means 75 mph (or 120 kph) for a propeller plane and 170 mph (or 275 kph) for a jet.  There must be a strategic steps to shift the mindset to think differently that includes allowing the team time to learn and experience their way to small. 

Small is Relative 

What is “small” will be different depending on the type of work a team is doing. There is back-end, middleware, front-end work and more. Each team must gauge what is small based on their work. Also, what is small will differ from team to team and is relative to team size, talent, and experience. What is small must be specific to each team. Management must not compare sizes across teams as this will deteriorate the relative sizing for the specific teams.
  
Small is Complex 

Creative work like building new products and services (or features therein) are considered complex (per the Cynefin framework) as there are unknowns and “unknown unknowns”, ergo requiring a "probe–sense–respond" approach.  Many will translate small to days of work. But translating small to time of work disregards the complexity and unknowns of the work. In an Agile world, we consider not just effort, we look at complexity of the work (e.g., what is known and unknown), and any risks involved in the work (e.g., what skills, experience, tools, infrastructure a team has and more specifically what they don’t have.  What this means is that to identify small work, you must look at effort, complexity, and risk so it isn’t straight-forward.

Small is Imprecise 

In an Agile world, we don't pretend to think that we can have precision in our sizes. We want good sizes but we have to move away from the traditional mindset where we think we can provide accurate estimates. If it isn't correct, this is actually okay as we’ll soon learn more about the work.  When you size the work within an iteration (aka, sprint) and the iteration is done, you will quickly build a historical database of sizing and will learn more about the work.  The very next iteration, you will have learned whether you were over or under for a size and when similar type work comes along you have input for the future sizing of work.  In other words, “don’t sweat the sizing”. 

Summary

When transforming to Agile, there is a shift to to small pieces of work allowing for iterative and incremental delivery of the work. Small is challenging for teams that have not had to work decompose to small. Understanding the meta around getting to small can help coaches, teams, and leaders navigate the challenges knowing that it is a mindset shift, it is imprecise, it is relative to the work and each team, and is complex.  



Sunday, June 23, 2019

The importance of Meeting them Where they Are



As I work with teams, leaders, or executives when applying Agile, often times what they ask for is not the first thing they need.  This is why bringing a “meet them where they are” mindset is important.  When you meet them where they are, you can bring the kind of coaching, education, and feedback that better fits their role and experience.
In most cases “meeting them where they are” means to understand where mentally (both intellectually and emotionally) they are in relation to the topic, in this case Agile.  This may mean attempting to understand their level of Agile knowledge, experience with Agile, and motivation or willingness for Agile. Sometimes meeting them where they are is physical meaning you join them in their workplace, their daily stand-up, or any space you may observe their interactions to better understand where they are.
This approach can help you understand the common ground. This helps the Agile coach know where they are and where they can go from there. It helps a coach determine how to engage in a way that is sensible and motivating to those they are coaching.  Example of meeting them where they are include:
- If a team has only just begun to form, it may be better to educate them on what it means to be a team, the Tuckman model, and on what it means to form before you expect them to perform well. 
- If a new team wants to give and receive honest feedback to each other, it may be better to first initiate icebreakers and connecting activities so that team members can get to know one another and build psychological safety and trust first.
- If a team or company wants to embark on an Agile journey, before you educate the team on how to do Scrum it may be better to first start with a discovery activity to gauge the current knowledge of Agile, Agile experience, and willingness to apply Agile.  This can help you better adapt the level of Scrum education they need.
- If you learn that the team is fairly Agile savvy and have applied Scrum already, but are having challenges with decomposing work, then you can meet them where they are but experimenting with story mapping.
Meeting them where they are has multiple advantages but the primary one is that you can determine what they need first.  When you meet them where they are, you can bring the kind of coaching, education, and feedback that better fits their knowledge, experience, and willingness.

Sunday, March 4, 2018

Woven Together - A Practice to Build Authentic Connection and Psychological Safety


By Jody Gold with Mario Moreira

The game is changing.
 Hierarchies are flattening out. Companies are re-organizing to profit from the agility and collective intelligence of smart, flexible teams.  The concept of “leadership” itself is changing—from individual leadership that devises strategy and drives troops into battle, to relational leadership that catalyzes the creativity and commitment of all team members.

The good news is that there are constructive frameworks from the isolation, frustration, and disengagement that reduce collective learning and performance, to fully engaged, highly coordinated, innovative and agile teams that increase learning and performance. Matrix Leadership is one such framework that helps you successfully navigate this transformation.

Woven Together is an early practice and part of Matrix Leadership that helps strengthen the fabric of your team. Icebreakers and team-building exercises are often fun but their value fades.  Woven Together builds authentic connection, curiosity, and care among team members that last. People who’ve worked on teams together for years often rarely know about each other as people.  They may not know that John has a baby girl, and fills up with love when he talks about her getting her first tooth, or that Jennifer gets lit up by the smells, sounds, and tastes of street food when she is in another country. 


Woven Together raises energy in the room and can be used as a stand-alone activity.  It’s also a tangible introduction to core concepts like seeing relationships as first class entities that Mario Moreira describes in his article (part 1 of this series) and the entire network of relationships within a team as the relationship infrastructure that Jody Gold describes in part 2 of the series.  You can practice Woven Together with your team, right now.

Set-up

The ingredients include your team, a ball of yarn, 20-30 minutes depending on the size of your team, and enough space to stand in a comfortable circle.

Determine if each person in the circle will say just their name or their name, role, years in role, years at company, years doing agile.  This will depend on how well the facilitator and team members know each other.

You are person A.  You will explain the activity and model the two most important components: 1) forming a connection with one person—person B - and speaking to that person only, instead of scanning from person to person as we’ve all learned to do, and 2) telling person B 'something that light you up' in a way that is genuine and concise.

Steps 
  1. Person A wraps the end of yarn around a forefinger and loosens enough yard equal to the distance between person A and B.  Person A throws the ball of yarn to BA speaks directly and only to B.
  2. Person A says their Name.  Person B says their Name. 
  3. Person A shares, “Something that lights me up is…”
  4. B responds in a few words to complete the connection, “Cool. Thanks for telling me that. I want to know more about that. Etc.”
  5. Person B chooses person C.  Repeat steps 1-5 (figure 1)
  6. C chooses D and repeats steps 1-5.  Iterate until all people steps 1-5 and the ball of yarn is back at A  (figure 2).
  7. After the yarn is back at person A, ask people to share what the experience was like and how things feel different now than before the activity.  

Final Thoughts

If Woven Together is used to introduce other practices, you may invite observations about the structure itself and its capacities.  Participants will name many characteristics of distributed leadership before they’ve learned about them formally.

Woven Together almost runs itself.  It’s amazing how much authentic connection, trust, and psychological safety arise from sharing ‘What Lights You Up.’  As the one leading the activity, be prepared for someone to say that speaking to only one person feels rude, exclusive, or uncomfortable.  Of course it may—scanning from person to person is a deep cultural norm.  Others may describe a sense of ease staying in connection with one person, like talking one-on-one with a friend.

Woven Together is also a good way for everyone to hear everyone else’s name a couple of times, and to quickly know who’s in what role and for how long, and/or how long they’ve been on the team or in the company.  It’s a great activity for a new team, a team whose membership has changed, or a new cross-functional project.

You have everything you need right now to turn thirty minutes into gold.  If you would like more information, consider contacting Jody Gold to discuss Woven Together or to learn more about how to equip teams to think, decide, and act as effectively as they can together.  

---------------
Read Part 1 & 2 of the Relationship series:
(Part 1) Importance of treating Relationships as First Class Entities 
(Part 2) Strengthening the Relationship Infrastructure to Build High-Performing Teams

Sunday, February 4, 2018

Strengthening the Relationship Infrastructure to Build High-Performing Teams


By Jody Gold with Mario Moreira

Teams, not individuals, are the essential building blocks of sense-making and action-taking in organizations.  Research, theory, and experience tell us that great teams depend as much on the relationships between the people, as the people themselves.

When I was younger, I spent years practicing leadership development the way most consultants do. We focused on strengthening the skills of individuals and hoped that teams would automatically improve as a result. We probably knew that relationships are the connective tissues that hold teams together, but we didn’t provide the mindsets, maps, or tools for people on teams to take care of the entire network of relationships themselves. Improving the skills of individuals is like lifting weights without strengthening and stretching the ligaments and tendons that connect them.

Matrix Leadership provides the mindset, maps, and methodology needed to build the capacities teams need to perform as interconnected, coordinated, adaptive wholes. It’s the ‘how’ of how we think and act like we’re in it together.  This is true whether the ‘it’ is diversity and inclusion, building resilient communities, or succeeding in complex and chaotic business environments. 


The heartbeat of our approach is building the relationship infrastructure that is the most important contributor to and predictor of a high-performing team.  Economic activity and value creation can only happen when working infrastructure (roads, bridges, tunnels; power grids; telecommunication; the Internet, etc.) support them. Might relationship infrastructure be equally important?

Research from MIT[i] and Google[ii] show that the pattern and quality of interactions within teams contributes more significantly to high-performance than the personalities, experience, skills, and individual intelligence of team members combined. In the image above, a blue line between two people represents a relationship, the first-class entities that Mario Moreira writes about in his recent article. Wider lines illustrate more interactions, more capacity, and deeper relationships.  The entire network of connections within a team comprises the relationship infrastructure. 

Developing the capacity for team members to speak to each other—in the open—is an indicator of a healthy relationship infrastructure.  It replaces the common norms of talking offline, not engaging, or scapegoating.  We call this speaking “in the eyes and ears of the whole”—a capacity that creates the foundation for many other high-functioning behaviors, including delivering effective feedback.

Agile uses early and iterative feedback about products so developers can generate more valuable and higher quality products faster. Matrix Leadership uses early and iterative feedback to optimize the relationships that high-performing teams depend on.  Feedback about relationships is the most direct way to build trust, psychological safety, and resilience so teams can turn their energy into results instead of friction. 

Both Agile and Matrix Leadership bring feedback into the open where it can do the most good.  When entire teams understand their shared challenges, they are better able to collectively solve them.  In addition to improved feedback, a healthy relationship infrastructure supports other behaviors including increased ownership and accountability; collaboration and innovation; engagement and satisfaction; and leadership that is distributed, flexible, and emergent.

Relationships are first class entities, real things that can be built, maintained, and repaired.  Yet it’s the entire web of relationships, the relational infrastructure, within the best teams that enable them to out-think, out-perform, and out-happy the others. 

Thanks Mario for inviting me to expand these concepts with you. 

----------------------------------------
We hope you enjoyed Part 2 of the Relationship series. Consider reading Part 1 & 3 
(Part 1) Importance of treating Relationships as First Class Entities 

- (Part 3) Woven Together - A Practice to build Authentic Connection and Psychological Safety 


[i] Pentland, Alex S. (2012, April). The New Science of Building Great Teams. Retrieved from https://hbr.org/2012/04/the-new-science-of-building-great-teams
[ii] Duhigg, Charles. (2016, Feb. 25). What Google Learned from its Quest to Build the Perfect Team.  Retrieved from https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

Sunday, July 9, 2017

What is Self-Management and is it good for Agile?

This is a four-part series on Self-Management.  This first article focuses on what is self-management.  The second article conveys the difference between self-organization and self-management.  The third article focuses on putting self-management into action.  The fourth article shares the ways to mitigate the challenges in moving towardself-management.  First up, what is self-management?
Self-Management is an alternative approach to management.  It moves away from the traditional structure of hierarchical management and moves the core management activities and work related activities to employees therefore effectively eliminates the manager role.  Typical management activities that move to employees include planning, organizing, staffing, directing and controlling (per Morningstar Self-Management Institute). 
A major change that must occur for self-management to be achieved is a shift in mindset.  People within the organizations that move to self-management must believe they both have ownership and accountability of the work and each other.  More importantly, relationships matter in self-management as there needs to be personal responsibility to each other. 
Self-management in context to organizations and corporations doesn’t mean people can do whatever they want.  Leadership defines the mission level 'what' and 'why' for the organization. Employees own the 'what' to work on and the 'how' to do the work, along with 'who' does the work.  It means that within the boundaries of the organizational mission or strategy, employees align the priorities, budgeting, planning, staffing and more around the work.   
Models similar to self-management include Holocracy, which is defined as a different way of operating an enterprise that moves power from a hierarchy management structure and distributes it across autonomous teams. Holocracy should have clear rules and definitions on what teams and individuals can do. 
It is recommended to start self-management with first understanding all of the types of activities that management would do so that they are understood and then adapted in a manner what allows for more of a distributed ownership of the activities. 
As self-management relates to Agile, it may be said that they are both mutually supportively of each other.  Agile works better when the bounded authority of many management decisions particularly regarding the work are pushed down to the team effectively reducing hierarchy.  Inversely in order to achieve self-management, it is supported by the Agile values and principles and the mindset it brings that is center around a strong focus on individuals and collaboration.

To read the second article in this series, go to: The Difference between Self-Management and Self-Organization

The third part of this series is titled: Putting Self-Management in Action!
The fourth part of this series is titled: Ways to Mitigate the Challenges of moving toward Self-Management.

--------------------------------------------  
To learn more about self-management, consider visiting the Morningstar Self-Management Institute website at: http://www.self-managementinstitute.org/about/what-is-self-management