As agile readers, I am sure we all agree that LARGE is a relative term and may not be defined just by number. What does LARGE imply?
- Is it something that has employees above 5000 but completely structured
- Or an organization that has <1000 employees but complex due to the silos, style, and technical limp.
My personal definition - Large organization can be defined as an organization that has fostered distance between employees with process, silos, hierarchy and complexities. Numbers don’t reflect the magnitude during the transformation, but the complexities and the mindset to change.
Over the years I have realized, transformations of companies with 10K+ employees and slightly structured, will take same amount of effort as an organization with 1000 employees but unstructured !!!
Similar to the two piles of books below. Where does one take more time to find a book? And the answer defines the magnitude of LARGENESS.
Let us assume, for the above pictures, if the problem statement is given as:
Find a book called “Why Agile?”
Scenario 1: Considering the books are thrown and piled all around the room, one would take almost days together to get the above problem statement resolved, despite the fact that it is such a small collection of books.
Cause of Delay:
- Not structured
- Chaos and redundancy
Impact: Cost of delay
Scenario 2: Books are arranged in an orderly fashion, could be alphabetical, year based, genre etc. !!! Also, this is digitally transferred to make the search easy via computer seen in the picture. In this scenario, one may not take more than 30 mins to find the book stated in the problem statement
In a software world, efficiency should be the measure of Largeness. Lower the efficiency higher the complexity and the magnitude of measure. As, despite the number, journey of transformation is the same. It has to go through the same cycle of form, storm, and norm and perform in order to successfully adopt agile transformation.
Irrespective of the approach or magnitude it is always important to understand the organization prior to committing to transformation or adoption.
An analogy to Agile transformation is, similar to any long journey, it gets as pleasant as the people surrounding you; you get a grumpy passenger your trip gets grumpier. There are many articles and blogs that describe impacts of people and surroundings on health and mindset. Hence it is very critical to building safer and pleasant roadmap , that emphasizes and enables empowerment and self-organized organizations.
Few steps that can enable a pleasant travel are:
Simple steps to a pleasant journey by Sushma
- Leadership Buy in: This is very critical and I write about this all my blogs, as they could be the major inhibitors of change if not in sync. They need to be made aware of what this change could bring and how it would impact their organization. It is usually a myth among leaders that, Agile implies delivery in 2 weeks and a fast track tool to production, as suppose to the reality which includes complete mindset and organizational change. Hence it is important that they understand the impact during ideation than in the middle when their struggling direct report squeal up to them!! Coach management on enablement than heroism. As many Agile leaders define, it’s an attitude change to build enablement and empowerment within teams than building a dynasty of managers. Motivation is intrinsic and not something that can be driven by bonus or money.
- Recognize and Build optimal teams: Team structures could vary between organizations; some work the best in a matrix wherein others may build Agile teams with single reporting structure. Organizations with open culture and fearless platforms are optimal for Agile teams. During initial transition, it is always advocated to have diverse reporting within the teams to enable health conflicts and feedbacks.
- Define Agile techniques and cadence: Build techniques that optimize the efficiency of transformation. During inception phase of transformation, it is always encouraged to have all ceremonies planned in accordance to the Agile framework. Many organizations prefer to have sprint planning of a 2-week sprint to be 1-2 hours and end up creating half-baked stories that do not sync with the definition of readiness. I have noticed teams that conduct 3-4 hours of sprint planning build stronger and optimal backlog for the team to build appropriate product that syncs with the vision.
- Coach your teams: And Practice what you coach, be an example. Be a leader to harvest leadership among employees. Build Fearless platform of speech.
- Retrospective: Identify key areas that need further iteration of change, build a plan and implement.
- Agile Mindset: Enable teams to identify the Agile way!! Encourage an environment that seeds openness, transparency, and fearless speech. Build a collaborative mindset, a place where someone swims right in front of a shark to save their peer.
- Integrate Technology: It is always important to facilitate the behavioral change with technology that facilitates this change. Build stronger CI/CD, modularization, and automated testing. It is critical that the system and architecture promote the agility of the teams. The simplicity of tools also plays a vital role in encouraging agility among teams. Tools and Reports used to assess Agile maturity need to be transparent and manageable.
Going to @mcottmeyer 's On Leading Large Scale Agile Transformation. Not really sure if it will scale for our org at scale in the engerprise— mheusser (@mheusser) May 5, 2017
Complex tools can lead to frustrations and resistance towards the change