Recently I was involved in a project that uses agile methodologies and gave me the opportunity to deepen my understanding and see agile in action. Agile methods originated in software development.
“It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.”
In agile, I found a practical companion to change management.
In the organisation transformation and change management, I had often advocated for the importance of step-change to increase adoption and to ingrain change. In many instances however, I had seen organisations embarked on change programs with lofty ambitions only to let it frizzle out or stopped midway due to lack of funding, buy-in and/or change in focus, typically after spending a lot of money with no real evidence of benefits. And this is largely due to a lack of detail application of step change.
Take for example, implementing a personal development program. An organisation had decided to overhaul the people management program through its HR department. Once the team set out to shop for toolsets, it encountered a large variety of choices and methodologies. In an effort to create a holistic approach, the team worked on a blueprint of requirements that may include competency framework, balance scorecard, 360 feedback, review process and etc. Typically, it is followed by numerous RFP process to select the right vendors and consultants. Before long, it had become a huge project with large financial investments implications that would require further board and management approval who would raise concerns on benefits versus cost, investment timing, impact to share holder value. While the efforts were plagued with indecision and continual budget revisions, the next economic cycle would have hit and a new recession in sight., thus further pushing out the decision to more “suitable” times. Sounds familiar?
Perhaps the story is too simplified and a stretch from reality. Reality may not be far behind. In the best of instances, an organisation came out of a transformation process full of fatigue and unable to leverage on the changes for positive impact. In others, an organisation is so scarred by the process that any future change efforts is viewed with cynicism and resistance where necessary change do not happen until too late while more adaptable competitors change and overtake in market position.
It is easy to understand that step change is important, it is quite another to build out the details behind it. This is where I borrow some key terminologies in agile to lend some insights into the practicalities of step change.
Commander’s Intent – The objective of the organisation is expressed as its vision. This vision does not include details in “how”, it is only a view of the future state. In the example of a people development program, the intent should be what the company is trying to achieve and not the specific toolset. And perhaps, the program is only a building block and not the intent itself.
Minimum viable product – MVP is about creating the smallest product that is operable to test a hypothesis and learn from it. In the same example, it is important to define a problem statement that is top priority in achieving the vision. Then create the smallest potential solution that can either prove it is the right solution or if the problem statement is the accurate. There are 3 key steps in the process: build-measure-learn. It is important to decide early the KPIs and the intended learning.
Pilot or Prove of Concept – Both are ways to implement the MVP. In a pilot situation, the solution is deployed in a real scenario with a small set of users and prove of concept is where no real users are involved. Let’s say a competency framework is identified as key solution to assess accurately and create focus in personal development. An MVP is a small set of core competences and it can be piloted with a selected team or a specific group to test out usability. Alternatively, a proof of concept can be used to compare the competences with vendor options prior to purchase committments.
Short release and frequent release cycles – Shorter release cycles meant that the scope is reduced to MVP from idea creation to initial release. Small frequent releases follow for continuous build on the MVP or create other MVPs so that multiple products are released to complement each other. In the same example, the next release could be an extension of the framework to the pilot team and the MVP to other teams and continue simultaneously until the framework is being rolled out.
Feedback loops & Retrospective – Learning from the process is important for adaptive planning and evolving solutions to fulfil the vision. In some instances, the feedback is also used to converge initial ideas. Feedback loops complete a release cycle prior to the next release where KPIs are measured and applied. Retrospective refers to a critique on the process of roll out and people involved. It is key to ensure all environmental factors like buy in, communication, business readiness are reviewed and to provide learning required for continual process improvement.
Fair process – All change efforts have a people impact for success. Fair process ensures that all parties involved have a chance to learn about the intent, provide input and ask questions. Whilst the solution is not a patchwork of individual intents, the process allows for communication, creates understanding and encourages innovation in solution creation. It gives appropriate time for people to debate, question, consider and ultimately accept the changes to come.
Most recently, I had used the above in creating a new team including job profiles and competences necessary to build in-house capabilities to delivery a solution. It helped me frame the process to create a small enough team and feedback loop to add resources as required. The organisation chart was reviewed and built out through feedback and provided me with opportunity and time to coach and integrate new additions to the team.
A suitable consideration in using agile in organisation design is that whilst building a software where codes can be erased and redone, hiring and firing is not as easy. Thus, it is even more important to ensure the right team is created and built on without unnecessary expansion. Using options such as contracting, 3rd party becomes important, a topic I will discuss in the next post on Total Talent Management.