Using the "Agile Adventurer" challenge as an excuse to say "Hello", I thought I'd also throw in a little humor to see what conversation it may spark.
So, what is an example of something you have heard referred to claim "agile" that either isn't, isn't enough, or can run counter to? And what advice would you offer?
For example, estimation. Many claim the use of story points as helping them be agile. How so? And given that there is no reference in the manifesto, how does estimation or pointing map back to one of the values or principles?
I have the pleasure of working with one of the original manifesto authors and have followed others for most of my career. None advocate estimation or pointing, and rather recommend spending any such time on other value-add activities.
What do you think? Please share your thoughts.
I used to use the term MLP
Minimal Loveable Product : it doesn't have to be viable, it has to have something useful for a user
True that the manifesto doesn't prescribe "pointing" as a practice, so I look at pointing as one method in meeting many of the manifesto principles.
Take the principle "Business people and developers must work together daily throughout the project."...if you don't have some common way to communicate how big a piece of work is, you might not be able to "work together" if each party has their own definition of size/complexity.
Or principle "Working software is the primary measure of progress." without some relative sizing measure agreed upon by the team, you might not have a way to assess what makes you faster or slower to deliver working software.
Sure pointing is not the silver bullet for all things Agile, but without some unit of measure in a working agile team, be it the traditional Fibonacci or modified Fibonacci, or t-shirts or <insert other creative things here> ... pointing (for me) represents another element of communication and team agreements essential to agile principles.
The principles are ideas to guide us in software delivery, but it is not outlining any one method for achieving the delivery.
Thanks for weighing in, @Jennifer Abbott
Those are nice clear examples. The greatest value I hear represented from teams trying to point has been "the conversation and understanding of the work to do are more valuable than the number". I find that to be the case.
If you haven't seen https://www.agilealliance.org/resources/videos/how-long-is-a-piece-of-string/ it is short, sweet and worth a good laugh!
I also have the privilege of working with one of them (as well as another three in the past, albeit one of them before the manifesto was written and the other two still over a decade ago).
Bear in mind that Scrum is a bit older than Agile, and Kanban a lot older, and I've spent most of my career working with Atlassian stuff which means there's a lot of Scrum and Kanban around.
As a consultant, and customer success advocate, most of my stories are not about so much about people claiming Scrum or Kanban are not Agile, or about how they do them, but about claiming that what they are doing is Agile when it really, really, really, is not.
Your screenshot is bang-on. "I do not think it means what you think it means" - most do not.
There is an easy number for me - about 90% of the scrum teams I've worked with, are not doing Scrum. And most of them are not Agile either. Scrum fits in well with Agile, but it does not mean you are Agile. Kanban does better in some ways, with only half not really doing Kanban, but most of them are still not Agile.
Agile is not "we do Scrum" or "we do Kanban". It's a way of thinking differently to "we need to deliver X by Y". Agile means delivering an X that people still need. X now is almost always not what X was 4 years ago.
To me, you need to ask two big questions. If you can't answer both of these with a "yes", then you're not Agile:
That is interesting, that the "most widely used agile framework" in the studies in experience is one of the least understood and well applied ...
And I hear something very lean in your last two "big questions"
Thanks for weighing in!
Great topic, @Mark Holmes (Adaptavist) 👍
Someone who also hangs out here on the community (I'll point him to this thread) once said to me "people need to consider, are they being an agilist, or a dogmatist."
His point was, following any methodology frequently (always?) requires compromises.
I.e, how does one balance the needs to the business to forecast business outcomes when no one knows when something will happen? How do we determine what kind of investment will be required to meet the peak of market demand? Think gaming software that needs to be ready in time for the Christmas buying season. Think car sharing company, that needs to open a new branch in city X by date Y in order to beat the competition to the punch. Those are just two real-world examples that I have been exposed to.
In my experience, nearly every company that is trying to be more agile struggles with these opposing needs and ultimately tries to strike a balance of some kind.
In fact, I would be hard pressed to name a single customer that is purely agile.
I'm not saying they're not out there. I'm only saying, I don't think I've met one. And I suspect this is why we often see story points, or some other method for estimation, in "agile" organizations.
@Dave Rosenlund _Trundl_ great point about compromise (or tradeoff).
The manifesto was for "Agile Software development" which was used as a qualitative adjective for that particular discipline. Timeless values and principles shared by practitioners learning and sharing together.
And if I recall correctly, James Shore who used pointing as a way to get away from the overly precise and unrealistic hours, eventually regretted mentioning them ;-)
To me points are tool to help you be more agile by
Most techniques in Agile are about ways of getting to the right behaviours in repeatable way - often they are used incorrectly when teams don't understand why they use them & therefore aren't using the output (or tool) for how it was intended. Always find retros help - people should question everything once it becomes rote/automatic - chances are it's time to change it up...
All techniques stop working when they become stale & teams mature
Overall @Katie Holroyd I have seen similar benefit with teams who try pointing for good reasons.
Eventually, the good teams seem to do away with it (no longer need it) as they learn to do those things as part of building strong, open planning, prioritizing, and negotiating in small, frequent cycles delivering each time.
For example, teams that use BDD well eventually find that Story or Example Mapping (https://cucumber.io/blog/bdd/example-mapping-introduction/) brings a greater understanding, and pointing is not really needed, once they have a shared "picture" of the work, they can begin automating and implementing tests.
Thanks for sharing!
Hi @Mark Holmes (Adaptavist) ,
Estimation and points will always remain a "point" of discussion. A few loose thoughts ...
- I find the baseline very important and not a bad idea to bring them up occasionaly during a refinement session when someone new is in the team.
- The points that are glued to a story are not that important for me ... what I find interesting is
- it gives a clear indication a story is too big and needs to be split up further
- The discussion that rises when one dev has 2SP and another 12 SP
- use of big T-Shirt sizing estimation very early on big epics to have an indication
@Frederik Vantroys I see what you did there ... "point" taken.
As I mentioned previously, I favor the point scale mentioned in https://www.agilealliance.org/resources/videos/how-long-is-a-piece-of-string/ when a team really makes a point of pointing ;-P
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Apply agile practices
Transform how you manage your work with agile practices, including kanban and scrum frameworks.
Learning Path
Configure agile boards for Jira projects
Learn how to create and configure agile Jira boards so you can plan, prioritize, and estimate upcoming work.
Jira Essentials with Agile Mindset
Suitable for beginners, this live instructor-led full-day course will set up your whole team to understand how to use Jira with an agile methodology.