Agile. You keep using that word.

[Mark Holmes (Adaptavist)]

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.

[Chris Iacovelli]

I have experience many a shop/company saying they are agile but that methodology (in their interpretation) looks very waterfall to me, e.g.:

• write all the requirements up front using epics and stories/
• review requirements en-masse and then the tech teams pick them up to further refine/elaborate on them again with the business teams.
• deliver one big bang to production.
• MVPs have various and multiple meanings (Minimum Viable Product, Maximum Value Product, Meet Vinny the Programmer :) )

No one will get agile right out of the gate as long as you incremental improve based on retros, lessons learned, team synergies, repeatable teams delivering, your journey will get you closer to the ideal.

I'll leave this here as $.02 from the l'idiot du village.

[Frederik Vantroys]

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

[Jennifer Abbott]

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.

[Mark Holmes (Adaptavist)]

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!

[Nic Brough -Adaptavist-]

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:

• Are you delivering improvement?  Not a "finished" product, but something your customers can look at and say "yes, that's better than the last iteration" or "oh, that's not what we thought, can you change it to ..." and your team listens and adopts.
• Is your team introspective?  Are they looking at how they can improve, and doing something to improve every time?  Or at least saying "we've checked and we simply can't improve".  (They need to be, at a minimum, looking at it)

[Mark Holmes (Adaptavist)]

@Nic Brough -Adaptavist-

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"

• Respect for people
• Continuous improvement toward perfection

Thanks for weighing in!

[Dave Rosenlund]

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.

[Mark Holmes (Adaptavist)]

@Dave Rosenlund 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 ;-)

[Katie Holroyd]

To me points are tool to help you be more agile by 

• using bingo to surface misunderstanding of what the story is you are building,
• help teams identify the story is too big for the sprint
• identify complexity or size to enable predictability for planning purposes
• give reason why you can push back
• or even identify that the story is not ready to play
• Helping identify WIP limits etc... 

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

[Mark Holmes (Adaptavist)]

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!

[Frederik Vantroys]

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

[Mark Holmes (Adaptavist)]

@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