User Tools

Site Tools


what_are_the_changes_in_culture_that_need_to_happen_with_agile

This is an old revision of the document!


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 Comments
“Local optimization” “System optimization” 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 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 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 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 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” 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” 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)” 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” Idea is that management are seen as place where problems are brought and worked aggressively to resolution.
“Do it right first time” “Fail fast” 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” 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” 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” 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” 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” 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” 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” This goes with the accountability discussion.
“Make decisions early” “Make decisions at last responsible moment” 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” 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” 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” 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” 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” 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” “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” 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” 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” 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 model aimed at having engaged people, as engaged people make better decisions, are more responsive and produce more.
“Cost focus” “Value focus” 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” 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 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” 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” 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 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” 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” 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 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” 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” 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
Do it for them Help them learn The difference between fishing for someone, and teaching someone to fish
Commit on behalf of others Only people doing work can commit 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” 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?

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~~

/home/hpsamios/hanssamios.com/dokuwiki/data/attic/what_are_the_changes_in_culture_that_need_to_happen_with_agile.1473685393.txt.gz · Last modified: 2020/06/02 14:28 (external edit)