Do you have a real deadline?

The first written record on the use of the word “deadline” was in 1864.  It was a the term to describe the line over which prisoners were forbidden to go –

Along the interior of the stockade, 19 feet from the stockade wall, was a line of small wooden posts with a wood rail on top. This was the “deadline”. Any prisoner who crossed the deadline could be shot by guards stationed in the sentry boxes. [1]

“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” – Agile Manifesto.

Leaders need to focus on providing Clarity and Competence, not control

Self-organising teams is the antithesis to hierarchical structures that exist in many organisations.  Traditional leadership required a strong leader to take control, attract followers and make it happen.  Modern leadership is about leaders giving control and creating leaders.

Self-organisation requires autonomy and control to be given to teams.   This includes trusting individuals to figure out how to solve problems, make decisions and how to best get work done.  With knowledge work the best decisions are those in teams who are closest to the information and customers.  However, structure, policies, processes and hierarchy often take the decision making away from these teams.

In his book, Turn The Ship Around!, nuclear submarine Commander David Marquet describes how control was given to the ship’s crew.  It required each member of the team to improve his or her technical competence and have a clear understanding and clarity of the organisation’s driving purpose:

Competence:   Provide teams with the tools and technical competence to get the job done; create the environment for thinking.

Clarity:  Define and communicate the organisational intent so everyone is clear on the vision, goals & objectives.  Everyone understands what is the right thing to do.
As a leader you trust the teams are competent and have clarity of vision.  Individuals have the freedom to adjust actions and make decisions in line with the vision and intent.

So what does this mean for a leader in today’s ever fast changing world?

If leaders don’t believe individuals can understand the vision or pick up the skills, why did the leader bring them in the first place?  And if there is a competency gap, why did the leaders not mentor or provide training?  We all have the extraordinary meta-skill to learn and acquire new skills.   If people do not have the competence, the role of leaders is to mentor, give people training and provide the environment for learning.

Leadership Debt

For the past 10 years I have been working with various organisations to humanise the workplace, help improve the leadership capability and dampen the toxic culture that may currently exit.  A recent article  (28 Oct 2015) in the news has provided no relief.

The article indicated that the thinking and culture of tomorrow’s leaders being taught at school’s today still resembles ‘traditional’ management of command and control borne out of the industrial era and Taylorism.  Traditional command and control is about managers telling subordinated what to do, when to do it, where to do it and how to do it.  There is very little thinking required of the subordinates and very little autonomy in this hierarchical culture.

The article has quoted a student stating to some other students:

Just remember your parents work for mine, so don’t go complaining to them.

Remember to say ‘hi’ to me when I’m your boss one day.

Girls who replied to the thread were told to shut up to “let the men handle business”:

Could all woman (sic) please refrain from expressing there (sic) opinions thank you

This type of thinking is a big contrast to modern management and leadership styles of ‘Servant Leadership’ where the leader is servant to those they work with.

The student’s comment resembles Level 1 of John Maxwell’s 5 Levels of Leadership.  Level 1 is more about “hierarchy” rather than “leadership”.

John Maxwell’s 5 Levels of Leadership

There is a real leadership debt in some organisations.  We have too many leaders who work “in” the organisation rather than working “on” the organisation.  Organisations and machines don’t build great products and services, people do. It is the collaboration and the human spirit that are at the heart and mind of great work. We need to stop viewing people as ‘resources’; treating them as robots or commodities who are easily interchangeable. We need to enable performance rather than manage performance. 

Humanising the workplace is about making a work environment that puts a greater emphasis on knowledge, passion, inspiring people to collaborate towards common goals, and fostering teamwork where creativity can flourish.  Leaders have a large role to play in humanising the workplace.

Effective leaders are increasingly collaboraters rather than being command and control.  Effective leaders realise great outcomes from setting appropriate context, rather than trying to control people.  Modern leaders provide vision and purpose that allows individuals and teams to be self-organising and self-disciplined.  It’s not about “managing” people but more about “leading” people and being more facilitating.

Further to my last post, Malcolm Turnbull – The Agile Australian Government, Turnbull has said:

We need a different style of leadership.  A style of leadership that respects the people’s intelligence, that explains these complex issues and then sets out the course of action we believe we should take and makes a case for it.

We need to stop accumulating more leadership debt and start erasing this debt in schools so we can survive the challenges of today and tomorrow and build better world for the future.

What is the relationship between Systems Thinking, Lean and Agile?

I was recently approached about the relationship between Systems Thinking, Lean And Agile.  Without going into too much depth and using too much terminology I have tried to summarise it in the following diagram.

Agile

Agile is an iterative and incremental approach for developing product and services through collaboration between self-organising, cross-functional teams.  It promotes adaptive planning, evolutionary development, early and continuous delivery, continuous improvement, and encourages rapid and flexible response to change.

Lean

Lean is a management mindset and a set of tools to create customer value, using the least amount of human effort, capital, inventories, time and capital investment in the process.  Lean focuses on continuously improving work processes, increasing throughput and flow and removing waste.

Systems Thinking

A system is defined as two or more parts that work together to accomplish a shared aim.  An organisation viewed as a system consists of not only its departments but also all of its interactions (both internal and external) including customers and suppliers. The success of all workers within the system is dependent on management’s ability to optimise the entire system.

Systems thinking is about:

• looking at the whole instead of focusing on components
• understanding components within their context, not in isolation
• paying attention to the interactions between components
• seeing cycles instead of linear cause and effect

By thinking of their organisation as a system, managers can begin to understand and address the problems facing them, their staff and their customers.  W. Edwards Deming, an American statistician and management theorist, found the majority of possibilities for improvement are in the system (95%) and the remainder are with the worker (5%).  He learned that if you want to change behaviour, then change the system.

Quotes from Taiichi Ohno

Taiichi Ohno

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.”

Leadership styles

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.

Enlightened trial and error succeeds over the planning of the lone genius

“Enlightened trial and error succeeds over the planning of the lone genius”

is a quote from a great video demonstrating how teamwork and agile concepts at IDEO is used to successfully deliver innovation and solutions in a non-IT environment in just 5 days!

Some highlights which I thought were pertinent to agile:

• The people are not experts at any given area.  They innovate by using and applying the process.
• The person leading the team is the leader because he is good with groups, not because of seniority.
• There are no titles, no permanent (role) assignments – everyone is a generalist but brings specific skills.
• Everyone communicates and share what they learn.
• Iterative development with showcases/demonstrations of prototypes to get feedback for the next iteration of the product.
• Some of IDEO’s mantra for innovation:
• One conversation at a time
• Stay focused on topic
• Encourage wild ideas
• Defer judgment
• Build on the ideas of others
• No criticisms (this is self moderated)
• Time-boxing, to prevent the process from going on for ever (Parkinson’s Law and Pareto Principle comes to mind).
• Self-organization.
• Team judges what are the best ideas (team votes).
• Fail often in order to succeed sooner (fail safe culture).
• Having an open mind – think outside the box.
• Belief that focused chaos can be constructive.
• High use of visualization tools, story boards, information radiators.
• Fresh ideas come faster in a fun place.
• High level of collaboration.
• Teamwork, teamwork, and more teamwork!

Lean and Agile – Doing more with less

Have you been in a similar situation as the above Dilbert?

Lean and Agile is about doing more with less.  Lean and Agile doesn’t focus primarily on cost reduction, but more on strategic alignment around enterprise agility – reducing waste and simplified processes which then could have an impact on cost reductions.  Furthermore, for comparable cost as traditional (waterfall) methods Lean and Agile can deliver higher quality product and a greater return on investment (ROI) by working on the most important and highest valuable features first – the business gets greater value for less.

Lean Software Development which has been popularised by Mary Poppendieck is derived from Toyota’s Production System.  Basically, lean is centered on adding value with less work.  Lean Software Development (Poppendieck) recognizes the following 7 types of waste:

• Partially done work
• Extra processes
• Extra features
• Task switching
• Waiting
• Motion
• Defects

Some of these wastes can have a large impact on the amount of value you can deliver.  Essentially, by having less of the above wastes we can deliver more.   Partially done work means you have unfinished development and resources are tied up on items that provide no business value.  Business value is only delivered when features are fully completed.  Partially finished features result in hidden costs to projects.  When it’s time to release, you have to complete an unpredictable amount of work.  This destabilises release planning efforts and prevents teams from meeting commitments, often resulting in more work.  Methods like Scrum deliver small increments of fully working software that are usable and tested.  Scrum teams agree on a definition of done to ensure they are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.

One big waste often found in waterfall approaches is doing extra steps and tasks that add no value to the actual process of developing working software.  Doing extra process steps (such as necessary meetings, extra paper work, manual reports) ties up resources which can be better used on value-added tasks and on activities of producing working software.

Extra features or the overproduction of features is often a result of gold plating.  Gold plating as described in Wikipedia:

Gold plating in software engineering refers to continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any).  After having met the requirements, the developer works on further enhancing the product, thinking the customer would be delighted to see additional or more polished features, rather than what was asked for or expected.  The customer might be disappointed in the results, and the extra effort by the developer might be futile.

On one of my past projects we had an Architect who wanted the team to build a framework for the system to cater for future needs.  This future need may not be realized as things inadvertently change.  The framework is a typical example of YAGNI.  There was no real requirement (technical or business) for the framework and there was a simpler solution which still satisfied the immediate business needs.  The framework added complexity which in return increased maintenance overheads to support it.  Every extra piece of code produced will mean more time is needed to test, integrate, compile and maintain and thus increasing the overall cost of ownership.  The key to avoiding gold plating is to ensure you only build the bare minimal that is necessary to deliver the greatest business value.  If you don’t need it now, don’t build it.  Keeping things simple is one of the Agile Manifesto Principles – Simplicity–the art of maximizing the amount of work not done–is essential.

To help avoid extra features, it is important to identify the minimal marketable features (MMFs).  Minimal marketable features is the smallest set of functionality that must be realised in order for the customer to perceive value.  It is the minimum viable product that has just those features and no more that is fully functional and allows you to ship the product to users so they can start using it.  The goal is to build the features that are the highest priority and has the most business value and avoid building unnecessary extra features that are less useful.  Agile’s approach of iterative and incremental development and focusing on delivering the most valuable business capabilities takes advantage of Pareto’s Principle which says you will get 80% of the business value from 20% of the effort.  This will allow you to deliver more value with less waste.

To complete more work with less time, you should avoid multitasking or task switching.  Every time you switch between tasks, you have to completely shift your thinking and gather your thoughts before you can get into the flow of the new task.  Multitasking can make you lose focus as it takes you a while to get back and remember where you were.  As a result there is a cost each time you change tasks or shift from one project to another.  To complete more work, try single tasking.

Waiting is the result of time delays and idle time (time usually waiting for things to happen and where no value is being added).  This can be waiting on people, analysis paralysis, delays in approvals, long planning times, delays in testing, and delays in integration and deployments.  Lean seeks to optimise the process by reducing the cycle time, which is the time from when an idea is realised to the time it is consumed by the customer.

Agile approaches such as Scrum emphasise the need for cross-functional teams where the team has all the skills it needs to develop and deliver fully working and tested software in each iteration.  The reason for this is to reduce the cost of motion and actions of people that do not add value to producing the product (such as traveling from one location to another to find an answer).  Furthermore, Scrum emphasises the need for a dedicated Product Owner who can guide the team daily from a business perspective.  All team members and customers are often co-located in a team room on Agile projects to reduce the amount of motion needed to find an answer.  Frequent face-to-face verbal communication is also important to reduce the motion of moving artifacts and documents.  Traditionally, hand-offs of documents between analysts to designers to developers to testers is fraught with waste and mis-communication.

Finally, Defects are a huge waste and takes resources away from producing business value (new business capability) to fixing defects.  Instead of fixing defects, Lean principles address this point by focusing on building quality into the process and preventing defects from occurring in the first place.  Agile teams deliver working, tested software every one to four weeks.  They find themselves making more changes to the code, and staying focused on today’s deadlines.  The development team and the code itself must become more Agile, which means it must be capable of faster change, sooner to keep up with business changes.  Agile teams have found in practice that Agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented.  It is well-factored and well-protected by unit tests.  Among the Agile methodologies, Extreme Programming (XP) goes into the most depth concerning how developers can keep themselves and their code agile.  Such practices enable the team to do more changes and provide them with a kind of Tai Chi flexibility – a new feature, enhancement, or bug can come at the team from any angle, at any time and teams can make the change with confidence that it won’t compromise on the integrity of the system.

Agile development teams regularly reflect by inspecting and adapting their way of working through retrospectives.  This enables the team to make incremental improvements regularly and tackle changes in manageable, bite-sized pieces that can be actioned immediately.  These retrospectives are important in identifying and eliminating waste in processes which will allow teams to do more valuable work.

In recent times, Kanban systems are being used in software development to limit a team’s work-in-progress to a set capacity and to balance the demand on the team against the throughput of their delivered work.  By doing this we can achieve a sustainable pace of development and flushes out issues that impair performance and it challenges a team to focus on resolving those issues in order to maintain a steady flow of work.

The simple act of limiting work-in-progress with kanban encourages higher quality code and greater performance.  The combination of improved flow and better quality helps to shorten lead times, improve predictability and due-date performance.  [Anderson 01]

Through commitment to Lean and Agile approaches of waste elimination, simplified processes and continuous process improvement teams can deliver in a continuous flow and do more with less.  So next time your pointy-haired boss wants you to do more with less, look into how Lean and Agile can help you.

References

• [Anderson 01] David Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”, 2010, Blue Hole Press.

Cost Center Disease

I recently attended the local Melbourne Agile user group meetup where Mary Poppendieck gave a couple of great presentations. I have watched many of Mary’s presentations over the Internet so it was a welcome change to hear her speak in person. It was also good to hear two presentations that I haven’t seen or heard before from Mary.  The presentation titles were:

• It’s Not About Working Software: First Build the Right Thing
• Socio-Technical Systems: Cost-Center Disease

I love the term “Cost Center Disease” that Mary introduced. I have seen many projects and organizations with symptoms of this disease. I would go as far as saying it would be a chronic disease in some organizations.

Cost Center Disease afflicts IT departments, government organizations, even consulting firms – anywhere the value created by one organization is realized by another organization and the governance system substitutes an artificial target for providing real value. – Mary Poppendieck

Organizations need to strike a balance between cost containment and delivering value.  However, too many times organizations focus too much heavily on costs and not enough on delivering value and ultimately the business goals takes a back seat.

Cost Center disease leads to local sub-optimization and projects and organizations that focus too much on costs often results in a ‘pants on fire’ delivery schedule.  This leads to overall increased costs due to teams adding technical debt, constant fire-fighting and overburdened processes due to management having a tendency to over micro-manage in an attempt to ‘control costs’ in the first place.

One attempt to control cost is to focus on people’s utilization which is a form of local sub-optimization – people have to be 100% utilized so they are efficiently used.  Focusing on utilization ignores the reality of software systems.  In a recent post, Alan Shalloway says:

While Lean adopters are looking for higher productivity and lower cost, they have learned that going after these directly actually results in lower true productivity (value delivered per person) and higher costs. The reason is that productivity measures too often are geared toward how much work people are doing rather than how much true value is being delivered and cost, alone, is inadequate for deciding on process and/or product improvements.  For example, measuring how much work people are doing leads to keeping people busy. Unfortunately, this leads to overworked analysts, developers and testers are incredibly busy while seemingly taking forever to deliver what the business stakeholders need. It does not translate into true added value.

Organizations with Cost Center Disease tend to have a mentality of contract negotiation over customer collaboration which results in additional legal costs which would have been better spent on delivering the customer value in the first place.  Decreased team morale is also evident which further deteriorates the system.

Due to a cause and effect relationship, I believe that by focusing and making decisions based on costs will have an opposite effect and not deliver the anticipated cost reduction or cost savings that is promised.

Ultimately, the one that suffers the most from Cost Center Disease is the customer.  Unhappy customers will soon turn to no customer.  And no customer will lead to no business.  So start focusing on delivering customer value.

As Work Changes, So Must Managers

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.