what_are_the_changes_in_culture_that_need_to_happen_with_agile
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
what_are_the_changes_in_culture_that_need_to_happen_with_agile [2016/11/01 19:01] – hpsamios | what_are_the_changes_in_culture_that_need_to_happen_with_agile [2023/08/14 11:45] (current) – ↷ Links adapted because of a move operation hans | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== What Are The Changes in Culture That Need To Happen with Agile? ====== | ====== 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|What Are The Changes | + | <WRAP todo> |
- | The " | + | The " |
+ | 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, | ||
+ | |||
+ | Someone once asked me "what kinds of changes are we talking about?" | ||
+ | |||
+ | < | ||
+ | < | ||
^ Traditional Organization ^ Agile Organization ^ Role ^ Comments ^ | ^ Traditional Organization ^ Agile Organization ^ Role ^ Comments ^ | ||
| "Local optimization" | | "Local optimization" | ||
+ | | 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 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 " | ||
| 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|Why Should We Start Without Doing a Complete Analysis? | | 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|Why Should We Start Without Doing a Complete Analysis? | ||
- | | " | + | | " |
| Efficiency | Effectiveness | Management | According to Peter Drucker " | | Efficiency | Effectiveness | Management | According to Peter Drucker " | ||
- | | " | + | | " |
| " | | " | ||
| "Iron triangle is scope, cost and schedule" | | "Iron triangle is scope, cost and schedule" | ||
| Solution focus - "Bring me solutions, not problems" | | Solution focus - "Bring me solutions, not problems" | ||
- | | "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 [[blog:how_can_we_understand_the_real_value_of_fast_feedback_and_deciding_late|How Can We Understand the Real Value of Fast Feedback and Deciding Late?]] | | + | | "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|How Can We Understand the Real Value of Fast Feedback and Deciding Late?]] | |
| "Best practices" | | "Best practices" | ||
| "Phase gate reporting" | | "Phase gate reporting" | ||
- | | "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 [[blog:how_can_we_understand_the_real_value_of_fast_feedback_and_deciding_late|How Can We Understand the Real Value of Fast Feedback and Deciding Late?]] and [[blog: | + | | "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|How Can We Understand the Real Value of Fast Feedback and Deciding Late?]] and [[what_is_the_best_approach_to_making_decisions_in_our_context|Why Doesn' |
| "Test quality into the product" | | "Test quality into the product" | ||
| "Get 'r done" | " | | "Get 'r done" | " | ||
| " | | " | ||
| " | | " | ||
- | | "Make decisions early" | "Make decisions at last responsible moment" | + | | "Make decisions early" | "Make decisions at last responsible moment" |
| " | | " | ||
| " | | " | ||
+ | | I am the smartest person | Leverage the team | Person | Base principle - "The team is smarter than the individual" | ||
| "Big upfront planning" | | "Big upfront planning" | ||
| " | | " | ||
- | | "Start lots of things to ensure project is done" | "Stop starting, and start finishing" | + | | "Start lots of things to ensure project is done" | "Stop starting, and start finishing" |
| "Death March" | " | | "Death March" | " | ||
| "Late learning" | | "Late learning" | ||
| " | | " | ||
- | | " | + | | " |
| " | | " | ||
| "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 " | | "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 " | ||
Line 49: | Line 57: | ||
| 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. | | | 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. | | ||
| " | | " | ||
+ | | 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' | ||
+ | </ | ||
+ | </ | ||
+ | |||
====== Need To Know More? ====== | ====== Need To Know More? ====== | ||
Line 54: | Line 74: | ||
* [[https:// | * [[https:// | ||
* 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. | * 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 | |
- | Note: page is getting big so need to refactor. Perhaps based on " | + | |
{{tag> | {{tag> | ||
- | |||
- | |||
- | ~~LINKBACK~~ | ||
- | ~~DISCUSSION~~ |
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/what_are_the_changes_in_culture_that_need_to_happen_with_agile.1478052062.txt.gz · Last modified: 2020/06/02 14:25 (external edit)