Lean Thinking Category
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 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 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.
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.
Last week I attended the LAST Conference (Lean, Agile, Systems Thinking) held at Swinburne University. The LAST Conference is a big departure from the Agile Australia 2012 conference I attended earlier this year. There was no fanfare, no big build up, little corporate advertising and significantly less people. It was also only $50 for the whole day but still contained lots of learning opportunities. It lived up to the advertised “low cost, grassroots mini-conference” message.
The conference schedule contained 5 parallel tracks so it was hard to attend all of it. I found myself at times wandering between sessions to get sound bites of what people where talking about. Being held at a uni one thing I definitely liked was the university lecture theatre style of some of the sessions – it felt right compared to sitting in a large conference center. Unfortunately, I couldn’t stay for the last sessions as I needed to head back into work.
I didn’t take any detailed notes, but here are my takeaways (in no particular order):
- Systems Thinking is the opposite of scientific thinking. Systems Thinking is not:
- Rocket Science
- Sea of Systems a handy guide to Systems Thinking
- Invention is the process of discovering something new or come up with an idea. Innovation is the act of of introducing that idea into the market and commercializing it
- Played some neat games that help with agile learning.
- Stages of learning:
- Unconscious incompetence
- Conscious incompetence
- Conscious competence
- Unconscious incompetence
- I had lots of fun in the Visual Collaboration session fine tuning my sketching skills. Use Wong-Baker Faces to visually represent levels of pain.
- Lots of interesting tidbits some of which I already knew but others just heard of in Edgy Agile things.
Here’s a selection of twitter posts on the conference (#LASTconf):
- @RonicaRoth: #LASTconf motto: you are not an attendee. Excited to participate!
- @lynnecazaly: Story structure: people + place + trouble …people want to know why, why this, why different #lastconf @unorder
- @hwiputra: A good storyteller uses concrete words not abstract words #LASTconf
- @hwiputra: Be comfortable with silence when getting stories out #LASTconf
- @AgileRenee: #LASTconf how to measure value? IRACIS – improved revenue, avoid costs, improved service
- @AgileRenee: #LASTconf my answer: the biggest waste in software dev today is doing the wrong work (benefits to cost don’t stack up)
- @libodyssey: culture is the product of behaviour #lastconf
- @ScrumMasterNZ: Work towards “Decision Meetings” and not “Status Meetings” #LASTConf #agile #lean
- @jodiem: Eg this guy has 3 levels of backlog – team-product , release-quarterly and sprint… #confused #lastconf
- @CEPitchford: The motivation for #offshore at REA was not cost it was talent! #win @hwiputra @frankmt #LASTconf
- @CEPitchford: Standup with #offshore team via Skype was hard. We couldn’t understand each other @hwiputra @frankmt #LASTconf
- @CEPitchford: Was hard for Chinese #offshore team to get visas to come to OZ @frankmt @hwiputra #LASTconf
- @CEPitchford: The whole local OZ dev team went to china for 3 weeks to handover to the #offshore team #LASTconf
- @AgileRenee: Find I’m mentally disagreeing with a lot said in the offshoring session in #LASTconf we have talent and should invest in building it locally
- @jodiem: Self service test environments… Where QA env is exactly the same as production env. Cool #devops #lastconf
- @antomarsh: Team rotation from Aus to China critical #LASTconf
- @gusbalbontin: Words such as “framework” and “governance” should never be in the same sentence as the word innovation. #LASTconf
- IrithWilliams: #Lastconf the real job at a standup is to ‘listen, inspect, adapt’
- @magia3e: Too many context changes slows down the #scrum team. Focus on getting to-do done #LASTconf
- @rooosterboy: How is #LASTconf different to #agileaus ? Seriously.
- @magia3e: If u don’t have some sort of continuous integration toolset/capability it will limit your velocity #LASTconf
- @c2reflexions: @AgileRenee doing a song and dance at #LASTconf
- @magia3e: Document the right stuff, but don’t waffle it out. Cut to the essence of it. communicate it with the right collaborative tools #LASTconf
- @CEPitchford: More control from management = less innovation from empowered teams #LASTconf @frankmt
- @CEPitchford: It’s not about execution anymore. It is about learning. #organizationalchange #LASTconf @frankmt
- @CEPitchford: Change programs: do we actually want to change? Or adapt, innovate and LEARN? #purpose #LASTconf @frankmt
- @CEPitchford: The way we still run companies was invented by people who lived in the last century @frankmt #LASTconf
- @CEPitchford: Project schedules and budgets are a work of fiction anyway @brown_note #LASTconf #fishbowl
- @hwiputra: All good leaders believe in their teams. #LASTconf
- @Drew_1609: Best value and most fun conference attended in a long time #lastconf
- @njhoughton: MVP … what’s the minimum thing to go-live … hold this as a meta-frame as you sprint … my examples are #foresight and #Innovation #lastconf
The visual recordings by @lynnecazaly were done using the iPad Brushes app. I have downloaded the app and now I just need to brush up (no pun intended) my skills. Thanks Lynne for the inspiration to try visually recording my notes.
Thanks to the organisers, Craig and Ed for putting together this great event. Snaps!
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.”
Kaizen (改善), Japanese for “improvement”, or “change for the better” refers to philosophy or practices that focus upon continuous improvement of processes.
Teams I coach frequently ask me for “best practices”. Do not assume that “best practices” in previous projects will be equally successful in another project. In some cases, “best practices” from one context can be counter-productive in another context. Practices and processes from previous projects should be used for learning and improvement. No practice or process is both complete and optimal – once we master it at one level, we see deficiencies that were previously hidden and the cycle of improvement begins again. You should always challenge yourself to experiement and find better ways of doing things and beating your own standards for excellence –
Improvement usually means doing something that we have never done before.
— Shigeo Shingo
Mistakes are a part of being human. Mistakes are not a sign of failure. Appreciate mistakes mistakes for what they are – precious life lessons that are used for learning and for others to learn form. Part of continuous improvement is learning from mistakes. The only failure is the failure of not learning from your mistakes.
Insanity: doing the same thing over and over again and expecting different results.
— Albert Einstein
James Hird, the coach of the Essendon Football Club (a team in the Australian Football League (AFL)) took over the coaching of a team this year that was struggling to win games in recent years. A priority for Hird was improvement in the team – “We’re trying to push for continual improvement.”
The club started the season well winning several games, however, they also made many mistakes along the way and had some big losses. The club learnt many valuable lessons from those demoralising losses which enabled it to obtain an all-important victory against the best team in the competition. One of the team players said:
“The coaches were never too up when we won and they were never too down when we lost.”
“The coaches are all just about learning, evolving and improving.”
Even when the team won games and making the finals was in sight, it was still about improvement and getting better. Hird is solely focused on continuing to develop his team – “improvement first, finals second.” Through continuous improvement, Hird believes they will build a good team that can compete effectively and achieve the goal of winning a finals premiership:
“Whether or not we make the finals this year… in 18 months time we want to keep coaching and teaching so we do become a good team.”
“Our team is not built on superstars it is built on all-round effort across the board.”
In a previous post, IDEO had a fail safe culture and which allowed them to fail often in order to succeed sooner:
Enlightened trial and error succeeds over the planning of the lone genius.
It is important organizations foster continuous learning so teams constantly get better at everything they do—improving their work, making decisions, holding good meetings. That’s why successful teams emphasize continuous learning, always going over what they’ve done, identifying what went well and what didn’t, and finding ways to get better the next time around.
The following from Gemba Panta Rei highlights the importance of learning from mistakes through continuous improvemment:
Here are three important lessons from Irish novelist and playwright, winner of the Nobel Prize for Literature, and wicked wit George Bernard Shaw:
“A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing.”
We often say that continuous improvement depends on the ability of people to experiment, make mistakes, reflect and learn from the mistakes. It is truly honorable when leaders create an environment in which it is safe for people to experiment, fail and learn. In fact it may take more courage to allow others to make mistakes than to make mistakes oneself. The good results of these experiments we call kaizen, and the learning that occurs from poor results we call development of human potential. When we achieve good results free of mistakes we call it competence, but mostly it is luck.
“The power of accurate observation is commonly called cynicism by those who have not got it.”
While opinions and ideologies can be had and held with only minimal effort from our armchairs, facts require that we put forth some mental and physical effort. The act of observation requires presence and attention, the accuracy thereof open-mindedness and the will to release held opinions when they conflict with observed fact. Seeing the truth can be uncomfortable. Having truth that conflicts with one’s belief can be even more so. Pointing out the misconceptions in the minds of others can result in being called cynical or worse. Accurate observation must be preceded by and paired with education, alignment and commitment to act to improve a situation, regardless of our preconceived notions in order for continuous improvement to take root.
“The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.”
I am an Agile Plumber – I eliminate waste, remove blockages and increase flow.
This week we had an agile workshop to establish some goals and create some epics for next quarter’s release for the agile change team at an organization I am coaching.
One of the items we covered in the workshop was to come up with a new team name for our agile change team as a result of some organization changes. Some of the names included:
- Agile Change Team (A.C.T.)
- Agile Capability Delivery Centre (AC-DC)
- The Enablers
- Centre for Agile Practices
….and there were many more.
When we went to vote on a name, a clear winner was Agile Plumbers. This name was quite humorous at first and we all got a good laugh, but the name is symbolic and there is some serious intent behind it.
An important aspect of agile and lean is about eliminating waste, removing blockages, and increasing flow which can really can change the way you build software.
There are many forms of waste including partially done work, extra processes, extra features, task switching, waiting, motion and defects. By looking at the waste that is in the steps you are doing and removing the waste you can do more with less.
We also have failure modes because we’re not paying attention to what it really takes to be agile. There are many roadblocks and blockages to getting to success. There are roadblocks that occur within teams and projects, but there are larger organizational roadblocks which are impediments to any agile approach. Agile touches on many aspects of an enterprise organization and changes many existing organizational processes that are more acquainted to waterfall. Examples include:
- Procurement, such as selecting and working with vendors.
- HR, especially what type of people we want to recruit, and changing manager’s KPIs to align more with a collaborative culture.
- Finance, how we structure the organization’s funding model to align with agile approaches and incremental delivery. Also funding may need to change to support a lean pipeline of work (continuous flow of work), rather than ‘individual projects’.
- Legal, how we write contracts that support agile teams and approaches.
- Training, creating training programs for agile (not only including agile specific topics, but also leadership and soft skills that are required in a collaborative organization).
- Governance, most traditional governance does not work with agile.
- Add your own organizational impact and blockage here that needs removing.
Finally, a goal of lean and kanban is increasing the efficient delivery of value through limiting the work in progress (WIP), making work visible and increasing the overall flow. Optimizing the entire value stream, from initial concept to consumption is fundamental to increasing flow of value through the organization. The idea is to get an idea into the development pipeline and out to the customer as fast as possible by looking at the existing processes and improving them and in the process eliminate waste and create value.
The other advantage of being called an Agile Plumber is that the name creates an memorable impression. In a large organization with many business units and organizational teams, one thing that can be difficult is being able to identify where agile help can be found.
So next time you need someone to help eliminate waste, remove blockages and increase flow, call your nearest Agile Plumber!
I first knew David Joyce, a Systems Thinker and Agile practitioner, through the local Limited WIP Society user group in Melbourne and in more recent times I have had an opportunity to know and work with him. David is one of those people who has a knack of explaining something that you can readily understand and comprehend.
David along with Peter Middleton have just published an IEEE paper, Lean Software Management: BBC Worldwide Case Study that contains anecdotal evidence over a 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24%.
These are impressive and enviable results.
David’s paper shows how the use of lean methods and thinking including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development.
Quote from David Joyce’s website –
I believe it will be one of the most significant papers in Software Engineering this decade.
– David Anderson
Great stuff David J !!!
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
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.
- [Anderson 01] David Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”, 2010, Blue Hole Press.
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.
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.
Despite that we are still yet to finish the current scope of work for the Agile Initiatives, we are starting to discuss future items in our backlog – distributed Agile and Agile@Scale.
There are a few projects in flight that couple of colleagues are working on that are large Agile programs of work. Large-Scale Agile by James Shore provides an insightful and thoughtful approach.
On a past project we used a similar technique mentioned in James Shore’s post to Using Bounded Contexts to Minimize Dependencies and Using Kanban to Manage Cross-Team Workflow. Though we didn’t use Kanban specifically, the outcome of the approach was similar – when the Team A is ready to work on something new, they took the next item off of the backlog, work on it until it’s done, and then delivered it to Team B that requested it. Where this feature is prioritized in Team A’s backlog is dependent on when Team B needed it.