Let it go or Lose it !
The role of Leadership in organisation's Agile transformation is a critical piece. Yet many organisations struggle to find the right balance between top-down vs. grass-root transformation. I would like to share an experience where we were able to achieve fairly good grass-root movement, but had serious challenges building the agile mindset at the leadership level. While the leadership was trying to help with the best of their intentions, certain actions, behaviours and patterns did affect the spirit of agility. If you are keen to hear about typical leadership anti-patterns during agile transformation and some pointers on how to avoid them, this session is for you.
Outline/structure of the Session
The organization was scaling up in terms of people and technology. At the same time, the agile transformation was happening with the functional teams (against the cross-functional recommendation of agile). As a consequence of the sudden growth, there were new “functional” teams that were being formed. And cross-functional was more virtualized (using release level standups).
All is well !
The journey started well with scrum teams formed across the organization and had started to sprint. The incremental releases were defined across varied functional teams to arrive at realistic release dates. Information radiators started to show up in the walls and the communications. People were curious to know what was happening.
However, as in every change management, the heat was felt in few corners of the organization. Many senior individuals, who could get hold of individuals earlier, found no "resources" when they needed to get some urgent hacks / pet projects/ new spikes done as everyone was locked into sprints and needed to be focusing on the theme of the sprints. Aided by pressure from the business, they needed “to manage randomness” which was not being provided due to clear sprint themes and boundaries.
The Agile Teams discussed using the "Sacrifice one person" approach but given the pressure the projects were in, they ended up calling the scrum rules of "Firewalls" (do not disturb the team in middle of sprints – will take it on priority in the upcoming sprints).
The Slowdown & Drift
The "visible status" was seemingly uncomfortable. In addition, all the risks and challenges being exposed by Agile team was too much to handle. Based on some water-cooler discussions, the Agile rollout team was asked to take the information radiators off the display walls. This led to reduction in visibility of progress and aided an imaginary ambiguity of the real status. Real issues were slowly pushed under the rugs. There were some "expedite" kind of initiatives with fixed deadlines that deviated the team from the rhythm of sprints. The sense of “losing control” by the management started to emerge, which was fuelled by many pressure situations and wrong attribution.
Organization structures & leadership were redone leading to team members serving two masters (in some instances) and getting pressurized work prioritization. The teams got struck into self-organization mode for too long and could not move into the self-managed mode (with exceptions from 1-2 teams, who did show that self-managed is the way forward).
The teams were delivering, yet not happy with how things were going. The development teams loved the rhythm of sprints but the ceremonies were merely mostly on paper with skepticism that they had no control over things. “This process would change anyway” - attitude started to spread within the team.
- Agile rollout is a two-way street, not to be done across the table – “you give me this, I get you that”. It is in fact a round table than a square one where everybody is equal and the support is more participative than autocr
atic is a good starting point.
- Leaders should focus on people and not hide behind processes & tools (Any process, there will be ways to beat the system if the team isn't believing in the goal)
- Be there and help collaboratively set up the right patterns of success
- Sincerely delegate
responsibility – Have managers to hire, groom and remove big impediments but not to delegate tasks. The servant leader !
- Let go of control – Instead of trying to remote-control, participate with your team with a strategic alignment and help them focus on the unified goal
- Walk the talk, esp. with transparency and question people who are shy of the transparency
- Enjoy experimentation, inspire teams, be curious and be prepared for the long haul of Agile Rollout
Agile Managers,Line Managers,Senior Executives, Scrum Masters, Team Members
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Philips - Enterprise SAFe Transformation Journey
About the company
Philips is a healthcare multinational company that focuses on building complete health care products and solutions for emerging markets, in addition to developing solutions and products for global markets, across the three sectors Healthcare, Lighting and Lifestyle. Using the expertise of its nearly 2000 engineers in Bangalore and aligning the marketing and sales teams the campus is responsible for creating and rolling out a complete set of products that include a whole host of solutions for global customers. It also contributes to global solutions in critical health care component development for connected consumer devices and renewable energy.
Beginning of 2014, an external survey brought out the issues wrt time to market and code quality. Taking the survey results positively, the Leadership embarked on an Agile/SAFe journey with pilot projects. The results were amazing and with the currently learning from the pilots, the organization is running 25+ deployments within. The journey has started and Agile release trains are delivering periodic value to our customers at defined frequencies.
Product quality, consistent & predictive delivery and quicker time to market are the key challenges the organization is trying to address today. Continuous Innovation is constrained due to the above issues and hence there is need to find a new way of product development which can meet the dynamic business needs, foster people engagement and deliver meaningful products to the world.
ScaledAgile has been used as a framework for product development across the organization global. The whole organization is undergoing a transformation from waterfall way of working to the SAFe agile way of working and roadmap is till 2019.
The Framework used for the transformation can be summarized into 4 major steps
- Develop products in the Agile way with focus on Basic Agile practices (Scrum)
- Establish Product Ownership with focus on Enabling Scaling aspects (SAFe practices)
- Establish a release pipeline with continuous integration (supported by Automation)
- Adopt a DevOps Culture with focus on Continuous delivery (to production environment)
This includes a comprehensive diagnosis of the various business processes, agile practices and behavior, engineering practices, delivery maturity and recommendations for the transition. A coaching and tooling plan is also an outcome of the diagnostics.
- Predictable Releases to customers (hitting the market with features every three months with features and business criticial bugs with less than 2 weeks with all the regulatory compliance)
- Feature planned vs Feature delivered per program increment > 80%lose
- Defect reduction co t 45%
- Team velocity – Baseline vs actual.
- Very high sense of ownership and high levels of engagement
Transformation team Profile
- Agile Capability program manager -1 FTE
- Agile Deployment Program Management – 1 FTE
- Communication expert – 1 FTE (Today we are 0/1)
- Coordination - 1 FTE
- Enterprise Agile Coaches – 16 (Today we are 9 /16)
If you need to start a project, you’ve already failed #noprojectsEvan Leybourn
schedule 1 year agoSold Out!
I want to be controversial for a moment and propose an end to IT projects, project management & project managers. I propose that the entire project process is flawed from the start for one simple reason. If you need to run a project, you've already failed.
By definition, an IT project is a temporary structure to govern and deliver a complex change (such as a new product or platform) into an organisation. However, to be truly competitive, an organisation needs to be able to deliver a continuous stream of change. Managed properly, this negates the need for a project and the associated cost overheads.
This is fundamentally what #noprojects is. The approach, structure, tactics and techniques available to successfully deliver continuous change. At its core, #noprojects is predicated on the alignment of activities to outcomes, measured by value, constrained by guiding principles and supported by continuous delivery technologies.
This presentation will introduce you to #noprojects. You will learn how to define an outcome and create an Outcome Profile. You will also learn how to manage change within the context of an outcome through the Activity Canvas.
Dark Side of CollaborationNaresh Jain
schedule 1 year agoSold Out!
On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.
It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.
In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.
Everything Is Better When We Stick Together: Building Team Working AgreementsEllen Grove
schedule 1 year agoSold Out!
Whether a team is brand-new or seasoned veterans at working together, explicitly defining and/or refining a team working agreement will help the team to align on how they will work together effectively to meet their common goal. In this fast-paced hands-on session, participants will go through the process of building a team working agreement using LEGO Serious Play (LSP).
Creating a team working agreement helps team members set the stage for effective communication and high performance by making assumptions about ‘what really matters to us’ and ‘how we will work together?’ explicit and negotiable. Great working agreements address some difficult topics - what values do we share? how do we want to deal with conflict when it comes up? how will we handle problems within the team? - which are often challenging to discuss openly and honestly, especially when a team is first assembled.
This session will show you how to use LEGO Serious Play to encourage a frank and fearless discussion in order to kickstart these discussions so that a team can quickly create a powerful set of simple guiding principles for working together. Participants will learn about the importance of team working agreements in creating team cohesion and common understanding of shared values and operational guidelines, and experience hands-on how to use the LEGO Serious Play cycle of build-share-reflect to have a participatory discussion to identify shared values, explore reactions to conflict, and build a set of simple guiding principles.
To Estimate or #NoEstimates, That is the Question
The #NoEstmates twitter hashtag was intended by Woody Zuill "..for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with ‘No Estimates’." Based on twitter traffic it has been successful at generating activity. It's a bit debatable as to whether it has really spawned much exploration. In this talk Todd will actually do some exploration using real data from over 50 projects at companies ranging from startups to large enterprises. In addition to the analysis of the data, Todd was able to build a simulation model of the software development process to both replicate the data to and explore the conditions under which estimates add value and when they do not. Based on the findings from the data and the simulations, along with an analysis of the types of business decisions that organizations need to make, Todd will provide some pragmatic advice for estimators and #NoEstimators alike.
Movers & Shakers of Enterprise AgilityPrasad
schedule 1 year agoSold Out!
With business agility being the new watchword in senior management circles, many enterprises are looking for ways to adopt this into their technology practices. However, it is imperative for such an initiative to go beyond the mere adoption of agile in a few projects.
To run an effective enterprise there are different systems and applications in every value streams. There is no one size fit for all. There could be a broad pattern/ classification like 'Money making applications' 'Applications which bring efficiencies to their operation' and 'Applications which are critical from a regulation and compliance perspective'.
My session is going to focus on experience and patterns that helped in achieving Agility in the above categories of applications with respect to key 'Movers & Shakers' in the system.
OKRs - Building Strategic Agility in Your EnterpriseDan Montgomery
schedule 1 year agoSold Out!
Agile is a radical evolution in how we think about work flow – AND how we engage people’s intelligence and commitment in the process. So now we’re doing a faster, better, more engaging job of ….. What? And Why? The “What” and “Why” questions are the stuff of strategy – purpose, vision, customer value, competitive advantage and sustainable financial performance.
OKRs (Objectives and Key Results) are the missing link between agile practices and alignment with the larger mission and purpose of your enterprise. Developed in Silicon Valley and adopted by industry leaders including Intel, Google and LinkedIn, OKRs are the framework for individuals and teams to set their own goals and align agile action with overall business strategy.
In this workshop, we will explore
- How business strategy is evolving from a waterfall model to an agile approach
- Extending the idea of “cadence” to include ceremonies for enterprise-wide strategic conversations that create “line of sight” for individuals and teams
- The use of OKRs as goalposts for strategic alignment and agile action
The Spiderman antidote to the anti-patterns of Agile leadersRegina Martins
schedule 1 year agoSold Out!
Leading in an Agile environment is all about mindset and understanding what motivates people. This interactive workshop will unpack the superhero archetypes of Agile leaders with their related Agile leadership anti-patterns.
Many leaders come into an Agile environment and feel threatened by a perceived loss of control. Successful Agile leaders empower the team and acknowledge that they can choose their own work and solve their own issues, pull themselves out of the detail and focus on supporting the team, know that if the team succeeds they do too, and are emotionally mature and are not constrained by ego.
The best paradigm to frame the concept of leadership in Agile is that leadership is encouraged at all levels. As such everyone working in an Agile environment is a leader. In smaller organizations this is probably easy to encourage. In larger organizations, where the “Title” or “Position” predominates defines who is a “leader” and who is not, anti-patterns tend to emerge which do not support an Agile culture, even if it is the organisation’s stated vision to become Agile.
In this instance the physical manifestations of Agile are put in place such as physical boards, Scrum ceremonies and an attempt at co-location are put in place. The danger here is that the Agile adoption will be a shallow one and will remain superficial. When the awesome magic of implementing Agile right is not achieved then people blame Agile as being the problem. It is not Agile that makes teams, projects and adoptions fail; it is people that cherry-pick those aspects of Agile that they like and are easy to implement that put the adoption on the path to failure.
All too often leaders dismiss Agile as something the development teams do, rather than as something which affects them too, and that their role is important for its successful adoption. The role of leaders cannot be underestimated to turn a shallow adoption of Agile and make it a deep and lasting change for the organisation’s benefit. In this case, adoption in a small team or program will start the journey toward the tipping point that will make it a lasting organizational change.
This may cause confusion, manifested as cognitive dissonance, in the leader. They may be asking themselves these questions:
- How am I supposed to behave in a changing environment?
- What behaviors am I supposed show to support the values and principles of Agile?
- How do I support support the teams now?
This workshop is based on my learnings and experiences as line manager of a development team in a large organisation, and Agile coach in large organisations in how leaders can in many instances unknowingly "sabotage" Agile initiatives, as well as experiential insights on what the enabling leadership behaviours and characteristics are.
As part of this talk I will share the following:
- What are the superhero archetypes of Agile leaders.
- What are the related Agile leadership anti-patterns?
- Discover the antidote to these anti-patterns (or the good patterns to replace the anti-patterns).
How Predictable is Your Agile ProjectBennet Vallet
schedule 1 year agoSold Out!
“When will it be done?” That is the first question your customers ask you once you start work for them. And, for the most part, it is the only thing they are interested in until you deliver. Whether your process is predictable or not is judged by the accuracy of your answer. Think about how many times you have been asked that question and think how many times you have been wrong. Now think about how much harder it is to answer that question when practicing Agile at scale. Your customers most likely feel like they have better odds of winning the lottery than they do of your next Agile project coming in on time. That you don't know your odds of success is not necessarily your fault. You have been taught to collect the wrong metrics, implement the wrong policies, and make the wrong decisions. Until now. This session will introduce how to utilize the basic metrics of flow to more effectively manage the uncertainty associated with very large scale software development. In it, we will discuss how to leverage the power of advanced analytics like Cumulative Flow Diagrams, Cycle Time Scatterplots, and Monte Carlo Simulations to drive predictability at all levels of the organization. Your customers demand better predictability. Isn’t it time you delivered?
The metrics of flow provide a comprehensive, analytics driven methodology for agile development at scale. By capturing real-time flow metrics and by using powerful analytical tools such as the Cumulative Flow Diagram (CFD), Cycle Time Scatterplot, and Monte Carlo Simulations one is able to more effectively manage the complexity associated with very large scale software development. Better management of complexity ultimately leads to better predictability.
Further, these metrics provide transparency at all organizational layers. At the team level the metrics provide real-time information and act as a catalyst for continuous improvement; and at retrospectives the teams will always have the most accurate, critical and objective information upon which to base any action. For Scrum Masters and the team the metrics provide insight and levers to pull. This level of visibility is crucial to decision making as most organizations and teams can perform multiple types of work across varied layers of work-units.
Similarly, at the enterprise and/or program level the metrics provide the transparency required to effectively manage complex and geographically distributed development and maintenance environments. One is able to track progress, productivity and pro-actively act on systemic issues such as infrastructure concerns, resource capacity, cross-team dependencies, and integration.
Flow metrics are the most effective means to manage to predictable outcomes in an inherently uncertain field. The use of Scatterplots and Monte Carlo Simulation based on real historical metrics eliminates any need for subjective estimation. At all levels of an organization, these metrics provide much higher levels of confidence and more realistic projections.
Pair Programming - Myth Busters!
“If a task takes 1 hour; it takes 2 hours in pair programming.”
“This fix is needed urgently; it is better done alone to save time.”
“It is good only for complicated tasks; there is no need to pair program on simple tasks.”
These are some of the statements you may be hearing around you from experienced developers to even managers. Sadly, there is lack of understanding of dynamics that make pair programming a key agile engineering practice. This, in turn, resulted in lack of its acceptance in teams adopting agile methodologies. Our mission is to dissect the myths around pair programming which brings continuous learning, productivity, quality, and the joy of collaboration to countless developers every day.
Raising the Bar: Being a true influential agile leaderSekhar Burra
schedule 1 year agoSold Out!
This is a nurturing workshop for Agile Managers to become effective influential servant leaders, to support enterprise agility.
This is a workshop for Agile Managers and above to help them shed the command and control behavior and be more of a facilitator and coach for their teams. At the end of this workshop, the participants will understand and appreciate the insights and techniques of being an Agile influential leader. The participants also walk out with a concrete action plan on how they support the agile teams and organization. The whole workshop runs on the technique of asking powerful questions to the participants, thus making them think towards the path of self-discovery.
The number of participants for this session are limited 20-25