The Dignity Of Work
agile
Talking about HR in Agile Meetup
It was 29°C outside, 7pm in the evening and one of the 2 days in between the world cup matches. I thought everyone would be off somewhere in a bar, movie theatre or somewhere cool. But it was a full turn out. And it was in front of some very lovely and patient french people that I presented a case study on Agile in HR and HR in Agile.
To begin with, it was based on an project I was involved in. And to be honest, before this project, agile was really just an adjective. It still is but there is so much more depth to the agility used in software development. And this group of people I was standing in front of were all practitioners of agile methods for many years.
Agile, whether referring to being flexible and adopting to circumstances or tied to a whole library of terminologies like scrum!, kanban!, XP programming!, burndown! or for that matter burnup! (all terms that made me stopped in my track at one point or another to say huh?!), is irrevocably, undeniably, incontestably about people.
So it was to great wonder why there haven’t been much talk about HR in agile. And even more curious is how the basic principles of agility can be applied to HR? Because, how can an arm in the company (usually IT department) be agile whilst the rest of the company be fat and heavy?
And so it was, after reflections on that project, the hits, misses and the “je ne sais pas quoi” that I attempted to be honest in this sharing about my involvement, my learning and most of all, why if we want to talk agile, we should talk people and if we talk people, we can be agile too.
With or without the library of terminology tied to agile, most business leaders today have to battle with rapidly changing consumer behaviours, disruptors from non-traditional competition, globalisation and accelerating innovation. Thus, being adaptability as Darwin first proposed is really the only contant and means of survival. And so agile or capital A-gile is a logical response.
This is the case for the example I provided. The company had to be quick in time to market, they had to deploy digitally sound solutions across various parts of the customer journey. And they had to use a combination of acquired expertise and in-house capabilities simultaneously across various markets covering different technology platforms.
The example I presented was on a part of the project where adapting agile methods cannot be independent of helping people adopt the change. And where adopting to this change cannot be done through traditional HR means.
The challenge was to condensed it to 1hr 30mins and respond to any questions from the floor. I think we did well as a group, 29°C and hungry to share on a hot July evening.
The english version of the slides are now available on: http://www.slideshare.net/JasChong/agility-in-hr-hr-in-agility-july-2014
Oh did I mention that it was in French, a first for me in terms of public french presentation.
Agile in Organisation Transformation
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.
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.
The Dignity Of Work 