Agile Cheatmap

Get Started. It's Free
or sign up with your email address
Agile Cheatmap by Mind Map: Agile Cheatmap

1. Assumptions

1.1. Adaption

1.1.1. Many problems we deal with are complex adaptive ones. This means that the best solution is not fully knowable upfront and only discoverable through many test and learn cycles

1.1.2. Planning is very important, but plans are going to be wrong so we better be prepared to adapt them rapidly when new insights occur

1.1.3. We should be prepared to stop and change focus at any time, so we should look to deliver early and often to at least have something valuable to show for our efforts

1.2. Improvement

1.2.1. There is always something to improve -- we will never reach a state of perfection. This is a sweet sound to the ears of people who have a growth mindset

1.3. Risk

1.3.1. A minimally viable solution (i.e., one that minimally solves the problem) may not be possible within the time and/or cost constraints, so the sooner we can expose that, the sooner we can stop and use the money on something feasible

1.3.1.1. There are often risks that if not addressed/discovered could cause the initiative to fail, so better expose them asap

1.3.2. Not all product features are equally valuable and each feature shouldn't be assumed to have a positive return on investment

1.3.3. It's difficult to assess the value of a product feature over time; this risk needs to be actively mitigated during the features lifetime (not just set once at the beginning)

1.3.3.1. This means features like products can and should be decommissioned over time

1.3.4. Knowledge work is perishable: the tacit nature of knowledge is difficult to transfer and it's value diminishes over time

2. Six Questions

2.1. Do we have a clear mission and prioritised plan?

2.2. Are we co-creating solutions rather than taking orders or imposing our solution?

2.3. Are we ACTUALLY working on the most important thing?

2.4. Are we working effectively on few things rather than spreading ourselves too thin?

2.4.1. Multi-tasking -- the art of messing up several things at once

2.5. Are we delivering to our commitments and at a sustainably fast pace?

2.6. Are we getting better through experimentation and learning?

3. Factors for Success

3.1. (in addition to applying our principles)

3.2. We have the right people: hungry, humble, smart, capable, and we give them a trusted and safe environment to experiment and learn rapidly

3.3. We have people with the right authority: their authority to make decisions is aligned to their responsibilities

3.3.1. Authority is given where information, competence and clarity lie

3.3.1.1. L. David Marquet

3.3.1.2. Decision-making is as decentralised as possible

3.4. We throttle demand to our peoples capacity to meet the demand

4. Rules

4.1. We always deliver something of value to our customers in less than 4 weeks

4.2. We’re done when we have run out of time/money, as such we should favour finishing over starting and rapid lead times

4.3. We don't wait until the end to do user acceptance testing, just like we don't wait until the end to assure quality – it's baked into the end-to-end process from the very beginning!

5. Principles

5.1. We deliver valuable outcomes as early and often as possible

5.1.1. We establish rapid feedback loops

5.1.2. A small valuable outcome is the only meaningful measure of progress

5.1.3. We reduce risk exposure by focusing on prioritising important unvalidated assumptions early

5.1.4. We actively look to reduce the cost of change

5.1.5. This principle is in tension with

5.1.5.1. the cost of repeated tasks like testing, integration, deployment

5.1.5.1.1. Other Principles

5.2. We seek to learn fast through small, preferably reversible, experiments with a limited blast radius

5.2.1. “The only way to win is to learn faster than anyone else.” Eric Ries

5.2.2. We don’t repeat the same mistakes—we communicate and embed our learnings

5.2.3. We seek root causes rather than look for someone to blame

5.2.4. We inspect and adapt frequently and intentionally

5.3. We only build what we understand to be necessary and important

5.3.1. We don’t build things people don’t want!

5.3.2. We implement the simplest possible thing that could work

5.3.2.1. YAGNI (You Aint Gonna Need It)

5.3.3. Simplicity is the art of maximising the work not done

5.4. We put hungry, humble, smart and capable individuals at the core of our initiative We give them the environment and support they need, and trust them to get the job done.

5.4.1. We actively seek to grow trust, care deeply about people and seek win-wins for everyone involved

5.4.2. We seek to understand our customers pains, gains and context and cocreate solutions with them

5.4.3. We favour openness and transparency

5.4.4. We favour high bandwidth communication and collaboration (face-to-face in front of a whiteboard)

5.4.5. We give continuous attention to technical excellence and good design

5.4.6. We seek to facilitate the attributes of highly effective teams

5.4.6.1. We seek to favour Google's research findings:

5.4.6.1.1. Psychological safety

5.4.6.1.2. Dependability

5.4.6.1.3. Structure and Clarity

5.4.6.1.4. Meaning

5.4.6.1.5. Impact

5.4.6.2. We address any observations of Lencioni’s 5 dysfunctions of a team with a long view in mind

5.4.6.2.1. 1. Absence of Trust 2. Fear of Conflict 3. Lack of Commitment 4. Avoidance of Team Accountability 5. Inattention to Team Objectives

5.4.6.2.2. Do your team members openly and readily disclose their opinions?

5.4.6.2.3. Are your team meetings compelling and productive?

5.4.6.2.4. Does your team come to decisions quickly and avoid getting bogged down by consensus?

5.4.6.2.5. Do your team members confront difficult issues rather than avoid them?

5.4.6.2.6. Do your team members sacrifice their own interests for the good of the team?