what_are_the_changes_in_culture_that_need_to_happen_with_agile
What Are The Changes in Culture That Need To Happen with Agile?
Work in progress
The “inability to change the organization culture” is listed by most people as the biggest obstacle to implementing a Agile approach.
Some wit once said “if you think agile is simple, just try it”. The basics of Agile are pretty simple (a focus on people and collaboration, continuous improvement through feedback, iterative and incremental delivery of value, etc). The problem is that while this is pretty simple, the result in your complex organization, when adopted is far from simplistic. What you see is the effect of “network effects” - small changes that ripple through your entire system and impact “everything” from governance, management, finance, budgeting, HR, architecture, and so on.
Someone once asked me “what kinds of changes are we talking about?” The chart below captures some of the changes we see. Of course, “your mileage may vary”. You will find that some these are bigger deals in your environment, while others just make sense and you will have no problem implementing thinking in your organization.
Filter:
| 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”. |
| Manage looking backward | Manage looking forward | Management | Traditional approach of managing by the numbers, focusing on “make the month” targets, and working to determine what went wrong (and in the worst case finding someone to blame). This is essentially managing by looking backwards. The problem is that while we can learn from past, we cannot change the past. Instead we should be managing forwards, improving processes as a means of improving future results. |
| 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. For an interim step see How Does Project Management Change with Agile? |
| “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” | “Iron triangle is value, quality and constraints (scope, schedule, cost)” | Management | 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. |
| I am the smartest person | Leverage the team | Person | Base principle - “The team is smarter than the individual”. How many times have you worked a problem, stuck in one place only to find that when you chat to another person about the problem, the problem is solved in 2 minutes. We have a tendency to soldier on by ourselves, and we need to change this thinking to leverage others. Agile practices such as pairing, and the team construct encourage this, ideas like setting a time-box when working an issue that, when the time-box is over you seek out help, help overcome tendency to not ask for help. This is an extension of the “Wisdom of the Crowds” concept. |
| “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”; Reduce Work-in-progress (WIP) | 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. See How Do We Control Work-in-Progress (WIP)? |
| “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 |
| Customer need determined through upfront, discontinuous planning | Customer need evolves through constant interaction | PM | |
| Detailed requirements documented upfront (requirements spec) | Vision coarsely documented | PM | |
| Plan distant, one-time delivery | Evolve continuous near-term Roadmap | PM | |
| Prioritize requirements upfront all at once | Reprioritize based on learning | PM | |
| QA validates requirements | Requirements validated through constant feedback; smaller, more frequent releases | PM | |
| Change controlled (avoided) through CCB | Change is cheap and can be addressed at cadence boundaries | PM | |
| Status is assess through document (phase-gate) review | Status is assessed by seeing working code at cadence boundaries | PM | |
| Release date determined by wishful thinking | Release dates are fixed - manage scope expectations | PM | |
| Meetings / events / reports happen at convenience of manager | Meetings / events / reports happen at convenience of team / train | Manager | This is part of servant leadership. Idea is to ensure that management doesn't slow the team / train down. |
Need To Know More?
- 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.
- This discussion is closely related to What Are The Changes in Management Approach That Need To Happen with Agile?
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/what_are_the_changes_in_culture_that_need_to_happen_with_agile.txt · Last modified: 2023/08/14 11:45 by hans