I was recently asked what is the most difficult agile transformation task facing executives today? My response was holding their people accountable to the requirements of the new agile jobs, such as product owner, scrum master, scrum teams, etc. I got quite a puzzled look in response and then an ‘aha’ smile from the questioner.
Technology innovations have been creating new job roles ever since the first technology was placed in the hands of early craftsmen. In The Perfectionists: How Precision Engineers Created the Modern World By Simon Winchester, Simon shows how the evolution of measurement and precision changed engineering and manufacturing over time. As you might imagine, the evolution also changed the jobs that people held. Prior to the innovation of carving out a large steam cylinder out of a single piece of iron done by the first machinists, blacksmiths were employed to hammer a sheet of iron into a cylinder held together with rivets.
Equally, technology innovations have changed jobs in our high-tech industries. Remember typists using typewriters, operators using word processors, and executive assistants using email who each handled document creation and distribution based upon fundamentally different tools. Now, that document creation and distribution is pretty much done by all of us due to technology innovations and ever improving tools. Who knows, maybe with Zoom, we won’t be using written words in the future?
Each new innovation follows an ‘S’ curve of adoption where adoption is slow at the beginning, speeds up through the transition point and slows again at saturation or maturity. You could imagine part of the adoption curve to be limited or enabled by the rate that humans are trained and hired into the newly created jobs that utilizes that technology. As a manager of a new, emerging job type, you would be expected to hire high-potential, yet untrained, employees and train them on the new tool or technology. Think of being that first manager over the factory milling large steam engine cylinders where all your potential new hires were blacksmiths with their hammers in tow.
Nice, but what does iron milling have to do with agile development? Let’s focus on job types that are different between traditional or sequential development programs and agile development programs.
With traditional development, we have programs lasting quarters, if not multiple years that span across various organizations’ functions: business planning, product planning, design, engineering, testing, manufacturing, support, marketing and sales. Each organization will have specific job types for their area of expertise, like software development engineer, quality engineer, product manager. Each organization will also have similar job types shared across the whole organization, for example, program managers and group managers.
Each traditional development program job type is consistent with the long duration programs, that is, their work is based upon long-duration-program methods, or technologies. Program managers use requirement documents, estimates, gantt charts, dependency management, commitment tracking, check points and status summaries. Each function’s role, knows and when to plan, work and communicate their deliverables. All of the group managers were likely promoted within their organization based upon their ability to do their organization’s jobs well. They know how to coach new employees in each of these roles.
Shifting to agile development programs, the new jobs are based upon very different technologies and methods. The organizations have self-managing teams, scrum masters, product owners, small increments frequently released to production (like every few hours… or, yikes, minutes) and velocity. The people in these new jobs hold or attend daily standups, sprint planning and review meetings, scrum of scrums and meta scrum meetings. The organizations operate in a constant flow of production changes and improvements. There are no checkpoints, gantt charts, or estimations. There is no equivalent of design, implementation, or test phase gates. While group managers exist, their jobs are totally different with self-managing teams, scrum of scrums and metascrums.
All well and good, but what’s does this have to do with holding people accountable to their new job requirements?
Many executive leaders are not aware that job types dynamically change when the organization starts on an agile transformation. If they are aware, they may face resistance from HR when communicating the new jobs now exist. Equally important, even if the new job can be coded in the existing HR system, the actual work done by the person is very different from the traditional development jobs. For example, in traditional development, software engineers often focus on implementation of code per the committed requirements and designs, leaving it to quality to demonstrate that those commitments were met. However, in agile development, software engineers, as a team, have to demonstrate that the desired customer value increment was delivered to production quality for each and every increment.
Let’s imagine, we are the first hiring manager for our new milling machinists. We would describe the new job, require skills, necessary training and evaluate our new hires against these needs to help them continuously improve and grow. As demand for our new steam engines grew we would be holding ourselves accountable to mastery of our whole organization against these new milling jobs and tools.
Equally, executives have to hold their organizations, their managers and their people accountable to the new agile job requirements. In doing so, the organization will work towards mastery of the new jobs, tools and technology.
No comments:
Post a Comment