This is Part 2 of a two-part series. You can read Part 1 here.
As outlined in my first post, responsibility-based planning and control can greatly reduce administrative overhead and simplify product development. To implement this practice, it is imperative to limit work to capacity; if you expect teams to meet aggressive deadlines while improving quality, speed, innovation, and predictability, you must limit work to capacity. Rally has built-in functionality to facilitate this practice of planning at all levels in your agile operating model.
I alluded to the fact that there are second-, third-, and fourth-order benefits to adopting responsibility-based planning and control practices versus using task schedules. These benefits are the ability to decentralize decision making, unlock the intrinsic motivation of knowledge workers, reverse the gender gap, and prevent employee burnout. I explore these topics in detail in this second part of the blog.
First, we need to acknowledge the premise that knowledge work by definition means that the people doing the actual work have the most knowledge about how to execute it. It doesn’t hold water that a small group of people, who are removed from the actual work, can successfully deduce a big upfront plan that is predicated on long lists of scheduled tasks that other people are obliged to complete.
For starters, this type of management approach is an inhibitor to the learning and discovery loops that are essential to iterative product development. Now, think about the havoc this wreaks on the governance process because the focus becomes the task end date (that is, the output), and not the outcome the work is meant to achieve. Also, remember, in digital product development, logic dictates that a task schedule will always be at odds with the actual task completion dates because of the inherent variability in this type of work. So, is it not fair to say the governance agenda is in peril from day one when managing via a task schedule? Most importantly, predefining a list of tasks has the following impact on behaviors:
- It reduces a team’s input into a lot of the decision making and thus stifles motivation and accountability.
- It limits a team’s ability to preserve options and iterate during solution design and build phases.
2. Reverse the Gender Gap
The fact is that software started out as a female dominated area, and this should be well known given such coverage as this article in NPR, this blog from Dave Farley, and the movie Hidden Figures. What some industry thought leaders have observed is that in the 80's software development became a “crappy job” because management of the day applied this production-line thinking to a job that requires learning and discovery. With this approach, work is reduced to a situation in which a task schedule, created by a select few, dictates what to do and when. That fundamentally took away people's agency to be problem solvers and creative with software development, the characteristics of the job that enable someone to have purpose or make an impact. This approach to management attracts a different caliber of people, including introverts and people who are more comfortable following orders or shunning responsibility for making decisions that have an impact on others.
3. Alleviate Employee Burnout
Well, let's start by understanding what burnout is by referencing the good work of Dr. Christina Maslach. We know employee burnout is more than just being overworked. It occurs when people have a lack of purpose. They become disengaged as they're forced to be more mechanical in their thinking and actions. Employees shoulder all the responsibility, but have little to no input or control over the work. This was basically how the ancient Greeks defined tyranny: Foreign emperors had all the authority, for example, to collect taxes and create laws, while shunning any of the responsibility for creating systems that improved people's wealth and livelihoods. In contrast, responsibility-based planning and control gives teams purpose, ownership, and responsibility to deliver their best work. Please do not discount the second-, third-, and fourth-order social and individual benefits that arise from embracing this type of work practice. It will create the right atmosphere and conditions to spark dialogue and interaction that spurs innovation and motivation.
Conclusion
In this post, I’ve sought to make a strong case for why you should experiment with responsibility-based planning and control today. This will be a fundamental change for any organization, for our industry, and for humanity as whole. Please experiment with it, and reach out if you have questions. My altruistic mission is to make our work environments better. We spend a lot of hours at work. What happens at work affects our family and friends, our health, and everything in our environment. Please, give it a try.
In a nutshell, you can simplify the amount of administrative overhead needed to manage product development, and improve the outcomes delivered by simply not scheduling tasks at all and adopting responsibility-based planning and control. Rally Software customers can rejoice because the solution enables teams to practice this method through Release Planning, Capacity Planning, and Team Planning pages.
One last thing, if you really need something to relieve tedium at work, go ahead and create a task schedule. That’s a spoof to an old classic T.V. sitcom which I think is apropos and hopefully a little entertaining.
Read Part 1 Here
