I came across a great article by Masaaki Imai on Gemba Panta Rei celebrating Taiichi Ohno’s 100th Birthday which contained some of his brilliant quotes on management and thought I will re-post them:
“Let the flow manage the processes, and not let management manage the flow”.
In the lean approach, the starting point of the information flow is the final assembly process, or where the customer order is provided, and then the flow goes upstream by means a pull signal such as kanban. On the other hand, the flow of materials moves downstream from the raw material stage to the final assembly. In both cases the flow should be maintained smoothly without interruption.
Unfortunately, in a majority of companies today, the flow is disrupted and meddled with by the convenience of the shop-floor management.
“Machines do not break down; people cause them to break.”
His life-long pursuit was to make a smooth and undisturbed flow as a foundation of all good operations. He believed that wherever and whenever the flow is disrupted, there is an opportunity to do kaizen.
“The gemba and the gembutsu have the information. We must listen to them.”
Taiichi Ohno always placed respect for the worker first in his approach to kaizen. His focus was always on the customer, both external and internal.
“Just-in-time means that customer delight is directly transmitted to those who are making the product.”
Ohno was a man of deeds. Learning by doing was his motto and he did not engage in empty discussions. You pay money to buy books and go to seminars and gain new knowledge. But knowledge is knowledge, nothing more.
“Knowledge is something you buy with the money. Wisdom is something you acquire by doing it,”
But you gain the wisdom only after you have done it. The real understanding of the lean operations is gained only after you have done it. No matter how many pages you may read on lean books, you know nothing if you have not done it.
“To understand means to be able to do.”
Donald Gray has written a great and interesting article on Three Leadership Styles, based observations on managing traffic at an intersection. In the article the most successful leader is the one that sees people as “adults that most of the time they can take care of themselves, and that the role of a manager is to support these competent adults”. To be effective, the leader should not place themselves at the center of the management task so that they can be much more flexible and effective at the key management activities. A must read.
Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”. It was coined by Fred Brooks in his well renowed 1975 book The Mythical Man-Month.
There was a recent project where unrealistic timelines were imposed on a team and the project was running late largely due to the Cone of Uncertainty – commitments were made early when least was known. The team estimated the project would complete in 12 months. However, the project needed to be complete much earlier than that. As a result, the project showed all the symptoms of a “death march” from day one – desperate attempts to right the course of the project by asking team members to work especially grueling hours, weekends (and public holidays), often causing burnout and by attempting to throw (enough) bodies at the problem with indifferent results. Interestingly, the project was still delivered in 12 months despite all the overtime and adding more resources.
As an observer from the outside, it amazes me how many people overlook the negative productivity impact of actually adding more resources. On face value, we seem to think if we double the team size it will simply mean we would double the workload of the team.
In reality, it takes some time for the people added to a project to become productive. Brooks calls this the “ramp up” time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them. This education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of multiple engineers who must educate the new worker in their area of expertise in the code base, day by day.
In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even have negative contributions – for example, if they introduce bugs that move the project further from completion.
Communication overheads increase as the number of people increases. The number of different communication channels increases along with the square of the number of people; doubling the number of people results in four times as many different conversations. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
To reduce cost on the project, a significant number of resources were obtained from an offshore location which made things more complicated and accentuated the above issues. Due to reduced communication bandwidth, collaboration was even lower with the offshore team.
A senior external consultant was bought in to help the team with some new technology. He commended the (original) team about the high quality code which enabled him to do his work effectively and to extend and maintain the code with low cost. However, all the hard work the team originally put in that resulted in high quality and clean code were being lost with the addition of the new resources. The need for new resources to be coding from day one resulted in poor quality output. Not only did this result in increased defects, but also increased integration issues.
In my blog Don’t rely on overtime to salvage a plan last month I wrote about avoiding daily or frequent overtime as it affects efficiency, productivity, morale and quality. Asking the team for mandatory overtime is a symptom of a serious problem on a project and does not address the root cause. Don’t get me wrong, you can work some short and specific overtime and this can often help get the project out of a tight spot. However, if you come into work frequently and say –
“To meet our goals, we’ll have to work late again”, then you already have a problem that can’t be solved by working more hours”. (Beck, 2004)
So with constantly increasing scope but with a unrealistic fixed schedule, quality was being impacted. Corners that were cut due to unrealistic pressures imposed on the team and excessive overtime came back to haunt the team later. They were finding or making more bugs than before resulting in more delays and greater integration issues due to poor quality of work being provided by the offshore team.
Overtime just doesn’t yield the results promised by Gannt Charts which provide an oversimplified view of the software development process by only measuring the quantity of the hours spent on tasks without also taking into consideration the quality of the time (yes there is a difference).
Sometimes the biggest gains in productivity come from stopping to think about what you’re doing, why you’re doing it, and whether it’s a good idea. We need to work smarter, not harder and have the ability to hear unwelcome news and then address the real issues.
When trying to add new team members to address a tactical and fire-fighting need, we need to realize that an incremental person who, when added to a project makes it take more, not less time – nine women cannot make a baby in one month.
Here is an article published in The Wall Street Journal earlier this year which is very relevant to today’s rapidly changing environment and the role of managers on Agile Projects.
(Mark Hurd who was my former CEO at HP is mentioned in the article)
What is a manager?
In simplest terms, a manager is someone who organizes a group of people to accomplish a goal. It is a job as old as the human race.
As an academic discipline, management is much younger. Frederick Winslow Taylor is often cited as the founder of management studies. His 1911 book “The Principles of Scientific Management” portrays managers as organizers: they arranged cogs in the industrial machine. Their job was about increasing efficiency and productivity. For Taylor, management “studies” meant standing in a workplace with a stopwatch, measuring workers’ actions, and devising ways to eliminate “all false movements, slow movements and useless movements.”
But in the years since World War II, the nature of work has changed. Peter Drucker was the first to clearly capture the difference.
In 1959, Drucker used the phrase “knowledge worker” – referring to people whose work primarily involves the manipulation of information and knowledge, rather than manual labor. The knowledge worker’s contribution to an enterprise couldn’t be measured with a stopwatch or a punch card. It couldn’t be forced or controlled by any amount of oversight. And it couldn’t be encouraged by simple pay schemes tied to hourly output.
Carlos Ghosn, CEO of Nissan Motor Corp., explains how he got buy-in for major layoffs in Nissan’s turnaround. From an interview 11/17/09.
Drucker broke the manager’s job down into five pieces. A manager, he wrote:
Sets objectives. He or she is responsible for determining what the overall objective of the group is, sets goals for each member of the group, and decides what needs to be done to reach those goals and objectives.
Organizes. He or she divides the work into achievable chunks, and decides who must do what.
Motivates and communicates. The manager creates a team out of the workers, so that they can work together smoothly toward a common goal.
Measures. The manager creates yardsticks and targets and determines whether they are achieved.
Finally, a manager develops people. In Drucker’s world, people aren’t interchangeable cogs; they are individuals who must be trained and developed to achieve the full power of the organization.
To be a good manager in today’s world, you must also be a good leader. It is not enough to give employees directions. Managers must also give them purpose.
What exactly does that mean? In his 1989 book, author Warren Bennis listed differences between managers and leaders. Among them:
- The manager administers; the leader innovates.
- The manager focuses on systems and structure; the leader focuses on people.
- The manager relies on control; the leader inspires trust.
- The manager has a short-range view; the leader has a long-range perspective.
- The manager asks how and when; the leader asks what and why.
- The manager imitates; the leader originates.
- The manager accepts the status quo; the leader challenges it.
- The manager does things right; the leader does the right thing.
- The modern manager’s challenge is that you must do all of the above. It’s an awesome but essential task. Managing without leading is a recipe for failure.
Attempting to lead without actually managing is disastrous as well. Many managers have met their downfall by setting an ambitious vision for their organization, and then assuming someone else would execute it.
“One characteristic of the successful dreamers I think of – Francis Ford Coppola, Steve Jobs – is that they also have remarkably deep understanding of the industry they work in and the people they lead, and they often are willing to get very deep in the weeds,” writes Stanford Professor Robert Sutton. “This ability to go back and forth between the little details and the big picture is also evident in the behavior of some of the leaders I admire most,” he says, mentioning Anne Mulcahy, chairman of Xerox; Bill George, former CEO of Medtronic, and Mark Hurd, the CEO of Hewlett-Packard.
These truths don’t just apply to CEOs. They also apply to the millions of middle managers who make up the core of any large organization.
Middle managers, of course, are not masters of their own fate. Unlike a Mulcahy or a Hurd or a Jobs, they must carry out an agenda that someone else has set for them. They may bear a heavy load of responsibility, but they have limited room for freedom of action.
A decade ago, the Journal’s Jonathan Kaufman captured the challenges of modern middle management by shadowing the manager of an Au Bon Pain bakery caf named Richard Thibeault. The 46-year-old Mr. Thibeault, a former factory worker, had always thought becoming a “manager” would mean he had arrived in the world. He would sit behind a desk, work 9 to 5, and be a pillar of the community.
Instead, he found he had to rise each day at 3 a.m. to bake muffins, prepare soups and fret over his store’s falling sales. Instead of the steady hours he enjoyed in the factory, he often put in as much as 70 hours a week. His job was an odd mix of broad responsibility and limited authority. He trimmed staff in order to meet corporate cost-cutting targets, but was not allowed to cut prices in order to attract needed customers.
“Some days I think maybe I should go back to factory work,” he told Kaufman. “It was easier.”
Yet for all their frustrations, middle managers in today’s well-run organizations often find they are given surprising responsibilities. They may find themselves heading up a team whose tasks involve not just following orders, but solving a knotty problem or developing a new product. They will be asked to innovate, to challenge the status quo.
Middle managers often find themselves heading projects that involve others who don’t directly report to them. Giving orders won’t cut it. Middle managers, even more than CEOs, must exercise influence without clear authority.
They must learn, in other words, to be leaders – the topic of our next column.
A “good read” article on Agile Journal, An Agile PM Isn’t What You Think Sub-Head: Where Does Traditional Project Management Fit in an Agile Project Using Scrum
There is always considerable discussion about the role of the Traditional Project Manager on an Agile Scrum Project and this article describes it very well.
In the end, Scrum does not prescribe where the individual currently serving as project manager should go in a Scrum project, only with whom the project management responsibilities lie and, as such, organizations should not assume that project managers always belong in a particular Scrum role.
[Edit 16 Nov 2009]
In another article 10 things a PM needs to know about Agile, the authors go as far as stating
There is no PM role in Agile
Whilst there is no single person performing the role of a PM, the elements and responsibilities of the traditional PM are performed by all the people on an Agile team.
I thought the following statement is quite true
“but who is going to chase them up if they don’t get their work done on time!?” In reality, this is more a fear than a real risk.
Ultimately, organisations and management need to trust individuals and teams to do their work – that’s why they hired them in the first place.
Mark Levison has written an excellent post on How Can Management Contribute to an Agile Project?
His post nicely complements my previous posts on a similar topic.