LeadingAgile is a management consulting firm. We're focused on solving the complex problems that block meaningful change in organizations as they transition to Agile software development practices.
We consider ourselves to be methodology and tool agnostic and we believe in safe, incremental, and pragmatic change. As a trusted advisor, we want to meet you where you are and partner with you to craft a customized roadmap that will help you to achieve your desired business outcomes.
Understanding the mindset of people is crucial to having them come with you on the transformation journey, assuring them that this is place for them is so important to making them feel safe about discussing experiments on ways of working and to make mistakes in that journey. I discovered LeadingAgile back in 2016, in my early days as a scrum master, and it's in my speed-dial list of sites for guidance on Agile.
It is remarkable that coaches, leaders, and managers continue to concentrate solely on team optimization regarding velocity, capacity management, the crafting of user stories, the utilization of Jira, and report generation, all the while neglecting the impact of cultural elements on the overall system.
Scrum alone is inadequate for organizing dependencies, and even when scaled, Scrum frameworks struggle to organize a system that delivers value across an entire company.
Leaders often delegate responsibilities to others. Orchestrating a system means that as a leader, you remain accountable until the desired results are achieved.
🎯 Key points for quick navigation: 00:32 *🎙️ Overview of the talk* - The talk focuses on the safe, pragmatic, and repeatable formula for leading Agile Transformation in large organizations. - Insights are shared on how executives can hold their organizations accountable for measurable progress through the transformation and what practitioners need to do to support this. 03:35 *📈 Importance of structure in Agile Transformation* - Emphasizes the need to structure and plan Agile transformations for success. - Discusses the relevance of understanding the unit of value in a transformation before tracking and planning progress. - Challenges the notion of solely relying on emergent approaches in Agile transformations due to organizational readiness and systemic barriers. 07:02 *💼 Executive perspective in Agile Transformation* - Most executives are now seeking Agile transformation but require planning and control to justify the economic outcomes. - Agile transformation needs to focus on delivering measurable progress and addressing financial concerns. - The responsibility is on Agile practitioners to provide safety, accountability, and progress tracking to meet executive demands. 15:26 *🛠️ Fundamental factors for successful Agile adoption* - Backlogs, teams, and working tested software are identified as essential preconditions for successful Agile implementation. - Backlogs should have specific formats and user stories to enable estimation and collaboration. - Teams in Agile are defined as cross-functional, stable groups necessary for maintaining velocity and delivering backlog items effectively. 22:44 *🛠️ Addressing impediments to Agile transformation* - Training people on Agile is essential, but fixing the organization's broken elements is the actual work of the transformation. 27:53 *🧩 Structuring Agile transformation* - Forming teams and establishing governance support agility. - Encapsulating teams with minimal dependencies is crucial for scalability. 36:27 *📊 Progressive transformation steps* - Incremental transformation involves breaking the organization into slices and implementing the entire value stream in Agile. - Iterative transformation focuses on continuous improvement to move the organization forward. 42:24 *🛤️ Transformation process implementation* - Build a leadership coalition and define an in-state vision to set the transformation roadmap. - Create a detailed 90-day plan aligned with the roadmap to guide the transformation work. - Implement a structured approach with 30-day sprints to achieve measurable outcomes and connect them to business goals. 46:51 *📊 Objectives and Outcomes Discussion* - Goals, objectives, and outcomes are interconnected in achieving company success. 47:33 *🚀 Transforming Organizations Key Points* - Incorporate feedback, manage communication, and create safety for everyone involved in the transformation process. - Understand the nature of transformation work, focus on iterative and incremental transformation at scale, and align roadmaps with accountable outcomes. Made with HARPA AI
I am desperately looking for an Agile consultant position anywhere in the world. I have experience implementing agile transformations in companies like Infosys, TCS, Accenture and Wipro. I am from India. Please help, please !
I can't believe how bad understanding someone with that amount of experience can have. I worked with some of the biggest companies in their industries, and scaled agile simply doesn't work. It will never work. It's not important how good velocity is, if the thing a company is building is a waste.
Velocity and estimates in the context of similarly sized makes no sense whatsoever. The velocity, or at the speed at which a team grinds away the backlog is the raw data for certainty. And that is a statistical exercise. In the context of statistics you are not interested in similarly sized bodies of work. You are only considering the average size of them. In certain cases that is not needed either. Personally whenever I build something, I also build up a scenario where the customer uses it. Depending on how deep I go, I know the exact value of my work. And by exact, I mean dow to a $100 precision per year per 100 users. If i open up the SAFe tools we are using, none of the titles has anything to do with the customer value... Plenty of team performance metrics and a whole lot of planning reaching into almost 6 months ... this when our customers change their behaviour roughly once a month. Yeah .. SAFe does not work. And no, not even as a training wheel for agile.
1:31 The sprint goal was in the original 2010 scrum guide and page 48 of Agile Software Development with Scrum (2002, red yellow green blue) says it was added to give the team wiggle room for sprint success.
It's clear to my that processes are part of what makes a culture, and that Agile is not a process but a mind set that helps in the design of processes. What I think I understand a system is, is that it's a structure and/or a strategy that will help us use Agile in order to create effective processes for a rich and effective work culture. I other words: Find out what your vision is, and use the Agile values and principles to achieve that vision. Is my assessment correct? If not, have no mercy.
love this conversation - thank you guys. The question about the many lenses - this feels like could be boil the ocean moment, although agree that they are all the same. So how to divide up the problem? Sounds fascinating to work with companies through these discussions!
On the development side I agree that pair programming with various team members is a solution. Would also look at the way the team deploys their code and move from feature branching to Continuous integration where small changes are built tested reviewed and merged on a daily basis to ensure that issues are detected as early as possible. Would also rope in the tester on the team to pair with Felix to see if automation tests and AI tooling like GitHub co-pilot could assist in improving throughput while at the same time maintaining quality. On product side need to check if story maps clearly layout achievable releases while having a backlog that reflects ALL work (user stories, tech debt tickets, Architectural upgrades and defects) in small batches for quicker feedback. On team building retros should be facilitated to encourage collaboration but also make it possible to have uncomfortable conversations. 1:1 coaching session also vital to uncover personal problems, interpersonal hostility and skills journey map planning. Complex issue with many possible areas to investigate.
Can u put them on another team, which they are more apt for? Can they support by doing more unit testing or bug fixing. Pair programming is definitely a good idea!
LeadingAgile blew my mind, in a good way. I'm sick and tired of the culture talk without concrete plan/roadmap of real fixes for the broken system. With coaches getting angry and blaming C-level for "not getting it" to top it off. Hope you guys get more and more attention :)
