As a Leader how do you make the Agile SWITCH?
Based on the book “Switch: How to change things when the change is hard?” by Chip Heath and Dan Heath, we discover the basic personalities of the Rider and the Elephant in each team member that continue to conflict, the recommended techniques within the proponents like “Direct the Rider”, “Motivate the Elephant”, “Shape the Path” could be easily adopted in an enterprise agile transformation journey across teams.
Are they pilot agile teams and managers who are leading the way you’re headed? If so, those are the bright spots. Establish processes and capabilities that identify bright SPOTs within your organization and implement policies that allow resource rotations and shadowing with such exemplary teams.
To motivate the elephant, we need to overcome the natural inertia by shrinking the change. We as agile coaches and lean agile change agents need to start small and think big, articulate small wins, perform small acts that kick the ball forward and lead to big change, how leaders can appeal to the identity of the teams.
The paper describes the SWITCH Clinic Framework in action that could be used to establish a game plan using the nine dimensions that helps identify and drive the change. It contains case study of a situation, where the SWITCH template has been applied to chalk out a game plan and make the desired SWITCH.
Outline/structure of the Session
Outline/Structure of the Session
Introduce SWITCH and Change Metaphor? [5 min – 1 slide]
Introduce the SWITCH dimensions, dealing with the rider, the elephant within us and shape the path [ 15 mins – 4 slides]
The SWITCH Clinic- Framework in Action [10 min – 2 slides]
The SWITCH Clinic – Case Study [10 min – 2 slides]
Exercise – Make your own SWITCH? [20 mins – 1 slide]
Summary and Wrap Up [5 mins – 1 slide]
Q & A [10 mins]
Lean Agile change leaders and coaches can adopt the SWITCH framework game plan technique to identify the change and make the desired SWITCH in Agile Transformation Journey
To direct the rider in us, find the bright spots, script the critical moves and point to the desired destination
To motivate the elephant in us, find the feeling, shrink the change and grow your people
Empowered leaders can shape the path forward for their teams by tweaking the environment, build habits and rally the herd
Enterprise Agile Transformation Coaches, Lean Agile change agents, Agile champions and Senior leadership
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Hugo Messer - Why distributed teams don't work and what to do about itHugo MesserEntrepreneurEkipa.co
schedule 1 year agoSold Out!
Based on 10 years distributed agile experience, Hugo's distilled 5 core problems in distributed software development. To find solutions, he's gathered data from hundreds of practitioners and wrote 6 books about remote teams. In this workshop, participants will learn practical solutions to make distributed teams work better.
Siraj Sirajuddin - Enterprise Agility & Leadership Transformation StoriesSiraj SirajuddinCo-FounderTemenos+Agility
schedule 1 year agoSold Out!
Enterprise Agile Transformation initiatives are BIG. Change at this scale of thousands is tough.
The Leaders and Executives involved in these initiatives are going through their own personal transformation. Change at this scale of one is equally tough.
Siraj Sirajuddin has worked with hundreds of executives leading enterprise agile transformation initiatives. These are their stories of personal growth and individuation. We will hear how transformation at a personal level is the leverage for transformation at a collective level. We will also learn of unique methods that activate personal transformation for leaders who are ready to step into their leader persona but are unable to get that from traditional leadership training and coaching methods.
Balaji Ganesh N - Doing Agile vs Being Agile - Sins and epiphanies from my agile journeyBalaji Ganesh NAgile Coach and Product ManagerIntel Technology
schedule 2 years agoSold Out!
There are so many organizations and product teams that are embracing agile implementation methodologies as a means to accelerate product development for competitive advantage and customer delight. Agile is now more than a fad or a buzzword.
Despite all this pervasiveness and penetration, there are only some teams for whom agile works well, whereas it doesn't work so well for some of the other teams and it fails for the rest.
But, is the problem really with adopting agile or is it something else? After all, agile is a mirror.
As Leo Tolstoy once said, "All happy families are alike; each unhappy family is unhappy in its own way.” There is a lesson to learn from every failed implementation.
From the 9th "State of Agile" survey done by VersionOne in 2014, in cases where agile projects were unsuccessful, 44% of the respondents pointed to lack of experience with agile methods.
Drawing from my experiences through my journey as a lean agile coach, this is an attempt to collate the anti-patterns (sins) associated with "lack of experience with agile methods" within the teams implementing agile and possible solutions (epiphanies) to overcome them. I believe that addressing these anti-patterns and preventing them from happening in your teams would significantly enhance the probability of succeeding with your agile implementations. Establishing the purpose and aligning the teams with the organization strategy is one of the key determinant of success. Due to time constraints, I would be focusing on 3-4 anti-patterns (points 1,7,8,9) that are commonly seen while touching on the rest of them briefly.
Details are given below:
1. Square pegs in round holes- These are role anti-patterns and arise by looking at Scrum Master / Product Owner as positions to fill rather than identifying and assigning the right person for the job and abrupt transitions from PM / architect to SM / PO creates this anti pattern. It is important to ascertain the fitment and identify the right person with the attributes of a servant leader who can influence the team without authority, empathize, ask the team the right questions which would empower and enable them to become more self-organizing and step back when required. In cases where a transition is involved adequate training / coaching needs to be provided to smoothen the transition.
2. Ineffective retrospectives - Retrospectives are treated more as a ritual with no feedback loop to the planning process. Ineffective retrospectives are good at addressing the person and not the problem, creating actionable without owner(s) and timelines, have no focused outcomes and create a "blame game" culture.
3. Sub-optimal local execution - This is reflected in product teams / modules / component not aligned at the global / program level and is primarily due to misalignment of the teams during planning, no vertical slicing, poor dependency management, inability to create cross functional teams, no single product backlog, infrequent touch points across the teams with no day to day interaction. This typically results in teams following the sprint cadence but not creating any working deliverable at the end of the sprint.
End to end optimized execution is possible only through creation of flow across the entire product line. As a first step, it helps to visualize the workflow and understand the work in progress across the various sub-systems to surface the bottlenecks. Cumulative Flow Diagram (CFD) is one of the powerful tools that help identify bottlenecks across the system.
Some general techniques that help address bottlenecks are identifying the right features (Kano model and user satisfaction matrix) and then vertical slicing to create a working deliverable every sprint, having a single Chief Product Owner (Scaled Scrum) who owns the overall product backlog and ensures priority and value alignment with each team's backlog, synchronizing the iteration time-boxes to ensure that dependent user stories are delivered in the same sprint as much as possible, investing in building relationships and trust among teams (investing in kick-off meetings and face to face engagement), creating a scheduled daily cadence for points of alignment like daily scrum of scrums (weekly inter-team sync-ups would be a killer for teams working on 2 week sprints), usage of tools like Design Structure Matrix (http://dsmweb.org/) for the right development sequence during planning / accurate impact analysis and complexity assessment alleviates this anti-pattern to a large extent.
Other aspects to address include the team structure and alignment. Executing cross skilling plans levels out workload and integrating business + dev + QA ensures that the right product is built right and reduces failure load significantly.
4. Dysfunctional team - This typically happens due to trust deficit. There is typically no daily engagement with the team and team is comfortable with conflict avoidance. Understanding the team (Use tools like Pat Lencioni's 5 dysfunctions of a team), managing conflicts effectively, creating conditions for constructive confrontation, rewarding team collaborative behaviors goes a long way in creating trust, confidence and collective responsibility.
5. Dis-engaging Daily Standups - Typical anti-patterns here include scrum meetings that overrun significantly beyond stipulated time, team members reporting status to the Scrum Master and not the team, impediments not raised in the meeting, dis-engaged team members. Visualizing the work, raising and tracking impediments, being sensitive to the time zone differences and accommodating them, investing in technology that helps enhance the engagement / involvement levels of the complete team helps make the daily scrums more effective.
6. Unaligned Process model - Team members frequently pulled into firefighting and production support activities with no regard to the commitments made. There is a need to introspect if time boxed sprint is the right way to go for teams in this case or would a different approach like Scrum+ Kanban (ScrumBan) work better ? There are also cases where heavy weight ALM tools are used for short duration engagements or small teams just because of the availability, without any training or regard to the ROI.
7. Product Owner - Team misalignment: This is typically manifested in busy product owners (Example -: product owner spending time in too many discussions with the client, Product Owner for multiple teams) for whom this is an additional responsibility apart from their day jobs, mismatch between the product owner's expectations and the team's expectation, disruptive product owners who do not appreciate or understand the team's challenges, team's velocity not factored in release planning by the product owner. Ensuring that a product owner is not assigned for more than 2 teams, business analysts in the team interfacing with clients to see what the market needs leaving the responsibility of the technical product to the actual product owner, proxy product owner who is empowered to take decisions in the product owner's absence are some of the strategies that ensure enough bandwidth is available for the POs to collaborate effectively with the product team and focus on effective product delivery.Appropriate budgeting for PO during the pre-planning phase, sensitizing the product owners through more face time with the team, identifying chief product owners for alignment across multiple teams (scaled scrum), proxy product owners are also additional strategies that can address this situation.
8. Not building the right thing - As Drucker said "There is nothing so useless as doing efficiently that which should not be done at all". . Appropriate widely used techniques / frameworks (Value Stream Mapping, Value-Risk mapping, Risk Based Testing, Design Structure Matrix, Product-Market fit decision frameworks, Kano model) for identifying the right thing to implement, prioritize and eliminate waste would help tackle this antipattern.
9. Cultural anti-patterns - Typical issues observed here includes -Teams not aligned to the organizational goal / purpose of the program, non-collaboration across teams, offshore team treated as a "B" team,lack of T shaped skills, inappropriate performance / R&R systems that reward individual success over team success, irregular or inconsistent sprint cadence, student syndrome, using velocity as a tool to compare performance across teams, abrupt transition from project manager to scrum master role, management looking at agile as a tool to overwork the teams, poor ALM tooling strategy and non-alignment across the teams.
Why is alignment important ? Because one of the important components of ownership is knowing "What to own ?". In surveys with the top management misalignment of the team's goals with the organizational goals comes out as a top response.
Some symptoms of a poorly aligned team include: poor or failed execution, lack of clarity about priorities, low morale, absence of healthy debate, lack of ownership or follow through, underground communications (gossip, “us versus them” thinking)
Usage of surveys like the team alignment questionnaires, Scrum Butt questionnaire, team assessment versus the 12 agile principles surfaces points of mis-alignment and dysfunction across the teams
Some solutions to address cultural dysfunctions include usage of purpose alignment matrix and four questions (who do we serve ?, What do they need and want most ?, What do we do better than anyone else to meet those needs and wants ?, What is the best way to deliver these products / services ? ) to establish the team's purpose, creating cross-functional teams that can get to “done” in each location, recognizing and rewarding adaptive collaborative change behaviors (cross skilling, taking initiatives in supporting team to overcome impediments, helping others cross skill, breaking boundaries for effective problem solving) to reinforce these behaviors, assessing current project managers and ensuring an effective transition into agile roles through 1:1 coaching (for transforming smoothly from command and control to servant leadership), effective management of time zone differences in distributed teams to ensure appropriate rotation of meetings / discussions so that one of the teams does not burn out, top down approach to sensitize management and make necessary changes to the organizational structure and career roadmap for accommodating agile roles like Product Owner, Scrum Master, agile program manager etc.. , adopting objective metrics like Time to Market (TTM) and business value accrued to measure effectiveness.
As Eliyahu Goldratt once mentioned "Tell me how you will measure me and I will tell you how I will behave". Therefore, look into your performance systems first if you come across any dysfunctional behaviors. One cannot expect a person to display collaborative behavior, if the performance system encourages and rewards individual success over team success.
10. Surfeit of Metrics - Team tracks too many metrics that are not relevant and are inherited from waterfall mindset. There is also an obsession for effort tracking at the individual level and % complete’s. Burn-up charts, velocity, committed vs achieved ratio, defects per sprint are just enough metrics for effective tracking.
11. User story anti-patterns - Teams do not put in efforts to refine the product backlog as it is seen more as a cost than an investment. There are multiple product backlogs and definition of ready is not agreed between the PO and the team. This results in large user stories that cannot be completed in a sprint, wait times for clarifications and things getting put on hold a few days after implementation due to lack of adequate inputs. Agreeing on a Definition of Ready (DoR) and coaching the team / PO on patterns for splitting user stories helps overcome these barriers
12. Agile Manifesto Delusion - This typically manifests as no documentation, no Definition of Done, multiple disruptions during the sprint to accommodate changes etc... Helping teams understand and interpret the agile manifesto and principles in the manner in which they were intended creates clarity and helps obliterate this anti pattern.
At the end of the day, it is all about delivering valuable working software in an incremental manner. Hence principles should always take precedence over practices and tools. We, from the agile community have a big part to play in helping to realize the above and breaking the above barriers for successful agile adoption.
Mirza Asfaar Baig - What's Agility - How to Enable It In The Non-Agile WorldMirza Asfaar BaigAgile Business Analyst/Solutions ArchitectAlessa Industries Company
schedule 2 years agoSold Out!
The true essence of being “Agile” is in knowing the true meaning of “Agility”. “Agile” has been around for a good decade and a half, yet there is lack of clarity regarding agility - even among the practicing professionals. SCRUM is the most popular agile framework that is used to ACHIEVE agility; but what exactly is “Agility”. You can do SCRUM and still be non-agile; sounds strange but it is true. As Mike Cohn, author and coach, puts it:
"It doesn't matter how good you are today, if you are not better next month, you are no longer Agile!"
Mirza will talk about how agile values & principles enable Agility. Frameworks like SCRUM are merely tools; when employed with the agile values and principles, agility is achieved. Agility ensures continuous process improvement and the right products - the products that meet customers' demands and expectations. Attendees will have a chance to see “Agility” separately from the agile framework. The implementation of agility is different for different organizations, Mirza will also discuss how to step into and introduce Agility in non-agile environments.