❌ Myth: #Agile means that we should be delivering ‘big bang’ solutions faster 😌.
✅ Truth: Agile offers you incremental value 😃. What that means is that you are able to get some value, bit by bit, as the team works towards delivering the full solution 🎯.
However, even with this knowledge, some organisations are quick to dismiss any utterance of incremental delivery. They are more concerned about knowing the earliest date that the team can deliver the big-bang solution.
So some organisations miss out on experiencing the true beauty and value of Agile because:
1. They do not understand that delivering some value in a few weeks, while the team works towards delivering the big picture, can make your customers a little bit happier 😊 or earn some revenue in the interim 💰.
2. They have not created an environment for testing and learning - where ideas can be quickly validated before too much time or money is lost on something that may not work or that your customers ultimately do not want 💡.
What has your experience been like? How have you convinced companies to try incremental delivery?
✅ Truth: Agile offers you incremental value 😃. What that means is that you are able to get some value, bit by bit, as the team works towards delivering the full solution 🎯.
However, even with this knowledge, some organisations are quick to dismiss any utterance of incremental delivery. They are more concerned about knowing the earliest date that the team can deliver the big-bang solution.
So some organisations miss out on experiencing the true beauty and value of Agile because:
1. They do not understand that delivering some value in a few weeks, while the team works towards delivering the big picture, can make your customers a little bit happier 😊 or earn some revenue in the interim 💰.
2. They have not created an environment for testing and learning - where ideas can be quickly validated before too much time or money is lost on something that may not work or that your customers ultimately do not want 💡.
What has your experience been like? How have you convinced companies to try incremental delivery?
This means that asking a team to stop working on one thing, to do something else, has several implications and begs another set of questions.
1. Aborting a plan in action can lead to waste. There needs to be strong reasoning (backed by data) to justify why the team is being asked to abandon their work-in-progress.
Consider that this literally means wasted time, effort and money in building something for our end-users and the intended value will no longer be realized.
2. How did we come by this new request?
a) Did we have conversations with our customers to inform this decision?
b) Did we look at the data and found a new opportunity to surprise or wow our customers?
c) What has changed in our marketplace to drive this decision?
What other questions do you ask in situations like these?
#agileteams #agileprinciples #agilemindset
Myth: Estimates are ‘hard and fast’, ‘set-in-stone’ deadlines.
Truth: Estimates in #agile - are simply that - an estimate.
Some of us are used to working by mapping out every detail possible before starting the actual work.
As an agile organization or team, we start with “just enough” information. As we work, we detail new requirements and functionality, as we get to know your customers better and start understanding the problem we are solving even more.
It is advisable that organizations take estimates as just that - estimates. That #teams are given the flexibility to build the right thing, the right way (ensuring quality is built-in at every step).
At the same time, teams must work assiduously and wisely to ensure that they are “maximizing the amount of work not done”.
That is, focusing on doing “just enough” work to get to done. And, as new information is uncovered which impacts the estimates provided, communicating early and often.
Anddddd... if we are truly working as an agile team, we should aim to live the principles of “delivering software frequently” and “early and continuous delivery of valuable software”.
That will be enough to keep our stakeholders happy (wink)!
#agileteams #agilemindset
Truth: Estimates in #agile - are simply that - an estimate.
Some of us are used to working by mapping out every detail possible before starting the actual work.
As an agile organization or team, we start with “just enough” information. As we work, we detail new requirements and functionality, as we get to know your customers better and start understanding the problem we are solving even more.
It is advisable that organizations take estimates as just that - estimates. That #teams are given the flexibility to build the right thing, the right way (ensuring quality is built-in at every step).
At the same time, teams must work assiduously and wisely to ensure that they are “maximizing the amount of work not done”.
That is, focusing on doing “just enough” work to get to done. And, as new information is uncovered which impacts the estimates provided, communicating early and often.
Anddddd... if we are truly working as an agile team, we should aim to live the principles of “delivering software frequently” and “early and continuous delivery of valuable software”.
That will be enough to keep our stakeholders happy (wink)!
#agileteams #agilemindset
Myth: Working out is more physical than mental. And #agile is more about frameworks than mindset. 😥
Truth: Working out is more mental than physical. The same is true about becoming agile.
It's not about going through some practices outlined by any particular framework.
It's about adjusting how you think, which results in a shift in your approach.
For e.g. if you usually tackled problems all by yourself, with no input from any other source, that mindset shift may look like you asking one other person to chime in. Over time, this may evolve into calling a whole group together.
The aim is incremental improvements, even in changing how you think, and pushing through the discomfort of doing things another way.
Inspired by an Insta post we saw recently.
#agilepeople
Truth: Working out is more mental than physical. The same is true about becoming agile.
It's not about going through some practices outlined by any particular framework.
It's about adjusting how you think, which results in a shift in your approach.
For e.g. if you usually tackled problems all by yourself, with no input from any other source, that mindset shift may look like you asking one other person to chime in. Over time, this may evolve into calling a whole group together.
The aim is incremental improvements, even in changing how you think, and pushing through the discomfort of doing things another way.
Inspired by an Insta post we saw recently.
#agilepeople
Myth: The Scrum Master is responsible for setting meetings and meeting notes. -_-
Truth: Anybody on the team can set meetings and take notes during a meeting. The Scrum Master may help to:
✔️Keep discussions focused on the intended purpose of the meetings
✔️Guide discussions towards actionable outcomes
✔️Encourage ownership and timelines, if possible, of those outcomes
✔️Keep it timeboxed
Extract from the Scrum Guide 2020:
"The Scrum Master is accountable for the Scrum Team’s effectiveness."
Truth: Anybody on the team can set meetings and take notes during a meeting. The Scrum Master may help to:
✔️Keep discussions focused on the intended purpose of the meetings
✔️Guide discussions towards actionable outcomes
✔️Encourage ownership and timelines, if possible, of those outcomes
✔️Keep it timeboxed
Extract from the Scrum Guide 2020:
"The Scrum Master is accountable for the Scrum Team’s effectiveness."
Myth: #Agile says documentation isn't needed.
Truth: Documentation is required but it should be lightweight - can be easily maintained, found, referenced etc.
Documentation should not take precedence over delivering working software (value to your customers).
Instead, it should help support the process of delivering the solution.
Document only what is absolutely necessary and keep it as simple as possible.
#agilevalues #customerfirst #simplicity
Truth: Documentation is required but it should be lightweight - can be easily maintained, found, referenced etc.
Documentation should not take precedence over delivering working software (value to your customers).
Instead, it should help support the process of delivering the solution.
Document only what is absolutely necessary and keep it as simple as possible.
#agilevalues #customerfirst #simplicity
0 comments: