What Are The Changes in Culture That Need To Happen with Agile?

Note: this discussion is closely related to What Are The Changes in Management Approach That Need To Happen with Agile?

The “inability to change the organization culture” is listed by most people as the biggest obstacle to implementing a Scrum / Agile approach. Here is a more detailed list of some of the culture changes that need to be made for an organization to become more agile in it approach:

Traditional Organization	Agile Organization	Role	Comments
“Local optimization”	“System optimization”	Management	In general, local optimization leads to sub-optimization of the system. Think about a delivery system set up where developers get bonuses for developing new features, while testing gets bonuses for finding bugs. In terms of delivery of value to the customer this system will result in behavior where developers will cut corners to show fast deliver, while testers will find hundreds of trivial bugs. We need to focus instead on “delivery of value to the customer” and optimize that system. The idea is to “watch the baton, not the runners”. The baton is what is important in a relay race - if the runner with the baton crosses the finish line first, they win. Just watching the runners will mean that you will worry, for example, if your runners are not busy “running” while the baton is being moved by another runner. The question should be “what can the runner do to help move the baton”.
Resource efficiency	Flow efficiency	Management	The focus with agile is on delivering business value as a smooth flow. This may mean that the best thing for people to do is not to be busy the whole time. Traditional management focuses on “resource utilization” which often means you reduce the flow going through the system because of context switching and contention for scarce people or resources.
Large annual bets based on plan	Multiple small actively managed bets based on reality	Management	Traditional approaches to implementing an organization plan is to do a yearly plan, and then determine if we meet the plan. The agile approach assumes we have plans, but they are smaller, more regularly reviewed so we can more easily adapted based on the changing business situation. See Why Should We Start Without Doing a Complete Analysis?, What Is The Effect of Batch Size On How Long It Takes to Get Something Done?. This leads to …
“Fixed” business case	“Conditional” business case	Management	See previous comment, Why Doesn't Traditional Project Management Work For Software Projects? and How Can We Understand the Real Value of Fast Feedback and Deciding Late?
Efficiency	Effectiveness	Management	According to Peter Drucker “efficiency is doing things right; effectiveness is doing the right thing.” He then adds “There is nothing so useless as doing more efficiently what should not be done at all.” With agile idea is to focus on business efficiency (delivering value) even at the expense of technical efficiency.
“Project Management”	“Agile Portfolio Management”	Management	The agile approach is less about setting up and meeting project plans, and more about the continuous flow of features / value and “validated learning”. See Why Doesn't Traditional Project Management Work For Software Projects? for more information
“Command and control” management	“Servant leadership” and “empowerment”	Management	For knowledge work we want to leverage the abilities of our people and not assume management knows best.
“Iron triangle is scope, cost and schedule”	Management	“Iron triangle is value, quality and constraints (scope, schedule, cost)”	Traditional projects pretend that you fix two sides of the iron triangle so the third is variable. Reality is that quality suffers when the project is under pressure. Agile assumes quality is required, that we focus on value and there are constraints in how we get there.
Solution focus - “Bring me solutions, not problems”	Problem focus - “Bring me obstacles”	Management	Idea is that management are seen as place where problems are brought and worked aggressively to resolution.
“Do it right first time”	“Fail fast”	Management	Why fail fast? Would you prefer to find out that we went in the wrong direction at the end of the project, or close to the beginning? Traditional approaches mean you only find out at the end of the project that there is a problem. See How Can We Understand the Real Value of Fast Feedback and Deciding Late?
“Best practices”	“Relentless improvement through experimentation”	Management	Best practices only work when the problem you are dealing with is simple. Most software projects, since we are inventing something that hasn't been done before, is more like “new product development” so it is a “complex” problem, not a simple or even complicated problem. This means a continuous “experimental” approach is required to improve how we work.
“Phase gate reporting”	“Reporting based on working software”	Management	Traditional software development approaches report based on stage gate milestones and intermediary deliverables of documents (eg we completed this set of documents therefore we are X% complete). The problem with this approach is that you are reporting progress when no software is running. Worse because you have increasingly detailed planning based on existing assumptions, your plan moves further and further away from reality. The agile approach is to only report progress when some (even the tiniest sliver of the) functionality is working and potentially available to the user. And as Dantar P. Oosterwal says “There was in fact no correlation between exiting phase gates on time and project success. The data suggested the inverse was true.“
“Bring project back on plan”	“Plan will evolve based on what we know”	Management	Lets face it, plan was put together when we knew the least about the project we were undertaking so it is safe to assume the plan is flawed. See also How Can We Understand the Real Value of Fast Feedback and Deciding Late? and Why Doesn't Traditional Project Management Work For Software Projects?
“Test quality into the product”	“Build a quality product”	Management	Quality is not something you achieve by a separate test phase. Everyone is responsible for doing quality work - quality first! In particular building in quality means that speed up the development process and creates a viable platform for future enhancements.
“Get 'r done”	“Software craftsmanship”	Management	With Agile you work to ensure a sustainable pace and build software to a high quality standard using modern development approaches. We are professionals and have professional standards that we meet for our work. We maintain those standards for all work.
“Highest paid person makes the decisions”	“Decisions pushed to lowest level in the organization”	Management	This implies that the information as well as the authority to make those decisions is at the lowest level as well. Not all decisions are pushed down. Decisions that are made infrequently, or where there is benefit in centralizing (eg tool selection) might be candidates for higher decision levels. In general though, as Don Reinertsen says “Any inefficiency of decentralization costs less than the value of faster response time.”
“Project Manager is the 'single wring-able neck'”	“Team is accountable”	Management	This goes with the accountability discussion.
“Make decisions early”	“Make decisions at last responsible moment”	Management	Agile approach is to make sure when the latest time it is to make a decision so we can leverage information and learning before that time. Traditional approach often forces decisions when you do not have all the information and so you end up with inflexible and potentially inappropriate solutions. See also How Can We Understand the Real Value of Fast Feedback and Deciding Late?
“FTE”	“Team”	Management	In agile the “unit of execution” is the Team. This idea implies that we no longer try to assign bits of people to projects, but rather bring work to high performance teams. The “team” needs to be treated as a corporate asset - something the organization has developed to high performance that we want to leverage. Note that this concept will effect hiring decision, performance appraisal, job descriptions and incentive plans. It will also effect physical layout of offices as face-to-face communication is the most effective mechanism of communication for a team. Another way to think about this is …
“Assign (bring) people to the work”	“Bring work to the team”	Management	Once you have high-performing teams in place it is better to leverage this high performance by bringing new work to the team, rather than thinking we can select the optimum group of people for the next task / project. Note that this removes the need to the great big “capacity planning” worksheet, where you allocate % time of FTE's to projects / tasks.
“Big upfront planning”	“Just in time planning”	Management	Assuming that we cannot build detailed plans upfront, do just enough planning to get started and update plan based on what we are seeing. Implies that teams are involved in continuous planning and, if there is a problem, then the answer is not to do “more planning”.
“Stretch goals”	“Reality based plan”	Management	Stretch goals actually have the effect of reducing results - to see why understand the impacts of 100% utilization on a team (see What Is Wrong With 100% Utilization Thinking?)
“Start lots of things to ensure project is done”	“Stop starting, and start finishing”	Management	There is a tendency to kicking things off in traditional processes. The reason there is this bias is because people are unsure when they will get something, and worry that their stuff will fall through the cracks. Problem is that you end up with a lot of work in progress this way and, often, things that are started are never finished. With Agile you focus on completing work, not starting it, to reverse this dynamic. Deal with the most important thing first. Make sure you finish them off one at a time before starting something new.
“Death March”	“Sustainable Pace”	Management	“Death March” as a tool when the project goes bad. Idea with Agile is that we don't get ourselves in this situation because we get information early.
“Late learning”	“Early learning”	Management	Projects come in late in traditional world because we find our late (i.e. when handed over to QA) that we have a problem with the project. With Agile, you might not like what you see, but at least you'll see it early, in time to do something about it.
“Sequential, serial development”	“Iterative and incremental development”	Management	For Agile you use a “lego” approach to building software. Try something. If it doesn't work out, try something else. If it works out, build on what you have.
“Dependency management”	“Aggressive removal of dependencies”	Management	This starts with setting up teams that are focused on developing features (not components) so that functionality can be developed without creating a dependency management nightmare, but goes much further than this (see Why Should We Work Harder to Eliminate the Effect of Dependencies? for more information).
“Compliance”	“Engagement”	Management	Management model aimed at having engaged people, as engaged people make better decisions, are more responsive and produce more.
“Cost focus”	“Value focus”	Management	Traditional model is based on cost accounting with little discussion of the value we get as a result of this. Agile changes model to focus on value delivery, where value, as in “lean” is defined by “what the customer sees as valuable”. Also most agile approaches improve ability of team to focus.
“Individual performance”	“Team performance”	Management	Move away from “hero” approach to projects and focus on team. Note this has implications for things like HR performance review processes and so on.
People as the source of problems	The system as the source of problems	Management	But we have a tendency to focus on people as the problem but as W. Edwards Deming says more than 80% of performance is based on the system people are working in, not the individuals themselves.
“Reactive prioritization”	“Economic prioritization”	Management	Traditional prioritization happens based on people work directly with who they know, or driven by the loudest person, or highest paid person. The result is often that there is no clear priorities and so decisions on what gets done is made by the development team. This usually doesn't reflect business priorities. We need an open, transparent process for prioritization based on the economics of the business with a single place to go to for “truth” on what to do next.
“Big batches of work”	“Small batches of work”	Management	Traditional approaches encourage handover of a lot of work from one part of the process to the next. This lowers the throughput of delivery system decreasing productivity. Agile approaches work to reduce batch sizes so there is smooth flow through the delivery system.
Expert (or HIPPO) decides	Wisdom of the Crowds	Management	In general traditional thinking is that the expert or high paid person is the one that has to make all decisions. In agile, we realize that if we get all the stakeholders in a room and make decisions that way, not only will we probably make better decisions because we a leverage all the available intellect, but we will also probably make the decision faster, as the decision doesn't have to go through multiple people to be made, to be the transferred through multiple people as well.
“Do more” means “need more”	“Do more” may mean “need less”	Management	Sometimes the right answer is to scale down rather than scale up. Since we have more effective structure in place, we are more focussed on what the customer needs and we can be more responsive, we might want to put in place a smaller group of folks to work delivery of business value, not add more to a current group.
“Information as source of power”	“Radical transparency”	Management	In traditional organizations people hoard information to make themselves look better (which generates a large amount of fear and threat, look for scapegoats) or they are bureaucratic where the aim is to protect the department, maintain turf and insist on rules. Examples include corporate SharePoint sites where how is allowed to access and create information is a jealously guarded endeavor. In many ways in traditional organizations information is a weapon. Agile organizations treat information as a resource that is useful and available to all. In general all information is available to everyone.
“Specific results”	Continuous (Team) Improvement	Management	The assumption is that if teams get better at what they do, the results will follow
Success is “achieving scope, schedule or budget targets”	Success is “value-driven delivery to the business”	Management	Give the customer what they want at the end of the cycle, rather than what they thought they wanted at the beginning of the cycle
Focus on “resource efficiency”	Focusing on “end-to-end flow”	Management	Systematic thinking indicates that high resource utilization does not lead to delivery. See What Is Wrong With 100% Utilization Thinking? for more information
Judging or manipulating people	Stay curious and seeing the best in people	Management
Do it for them	Help them learn	Management	The difference between fishing for someone, and teaching someone to fish
Commit on behalf of others	Only people doing work can commit	Management	Basically the idea of commitment in an agile approach is that the people doing the work are the only people who can truly make a commitment. Most traditional management approaches expect people to make commitment on behalf of others.
“Analysis”	“Bias for action”	Management	Traditional approaches expect a plan to be put in place after a significant amount of analysis has been completed. Agile approaches replace this expectation with a bias for prroducing something, and then driving the feedback cycles so we can steer the generation of the value

Need To Know More?

Excellent graphic describing some of the transitions from the perspective of traditional project management viewpoint

FYI: I expect to edit this list as I figure out better ways of saying things and identify other changes that are required. And I expect to focus this list and edit it to make it more concise as it is pretty lengthy at the moment.

Note: page is getting big so need to refactor. Perhaps based on “things that are general” vs “things that a coach would need to change”?

~~LINKBACK~~ ~~DISCUSSION~~