Re: What is agile?

Hi Rafael.

I am actually tired of hearing or reading this "oh, all that agile stuff
was there before Agile". Yes, it was there, but

  a) nobody did it consequently in the combination that comprises Agile
     (not even the practices, not to mention principles and values
     underneath) and

  b) it is still not done by many organisations today which claim to be
     agile.

Oh, and BTW: You cannot "do Agile", only be agile.

Disclaimer: I do understand that you embrace the Agile Manifesto in its
full beauty, so this is not to say that I think you don't "get it". I am
just saying I am tired of this line of rationale. ;-)

Kind regards
-- 
Alexander Kriegisch
https://scrum-master.de


[email protected] [SCRUMDEVELOPMENT] schrieb am 03.05.2018 19:58:
> 
> 
> Hi everyone,
> 
> 
> Firstly, I have to say that we see a lot of trivialisation regarding this
> matter. It seems like everything that is good fall into the "Agile-box"
> and what is not good in the "traditional-waterfall-box". At least here in
> Brazil.
> 
> 
> When we ask people what Agile is, we usually get answers around
> "adaptative", "easy to change", "small feedback loops", "fit to purpose",
> "collaboration", "understand the customer" and some others more passionate
> ones. But all of these properties was already there before Agile was born.
> 
> 
> So, I was wondering how a scientist would measure whether Agile is been
> effective. How to set the boundaries and not fall into ambiguity or in
> particular perceptions.
> 
> 
> Then I sketched out a particular understanding about what Agile is, and
> what makes Agile unique, for me, is the sum of those properties, that is
> represented on the manifesto. So, Agile would be to seek the Agile
> manifesto values and principles. And that could be measure against actions
> toward this goal. What bring us to consider that might also exist levels
> of intensity using and seeking Agile.
> 
> 
> If Agile is to adapt to customers, we already had that before. If it is to
> deliver value or respond to change, also. But if the context is seeking
> actively to address all the 4 values of the manifesto, using particular
> practices and techniques, that is a different approach that we can call
> Agile.
> 
> 
> I recognize, though, that is easier to say that someone or some company is
> doing Agile, even if they don't follow what I said before. And I have no
> problems with that. The Agile movement spread some good practices and made
> them popular and took the credit. That is apparently doing good to the
> practicioners.
> 
> 
> ***
> 
> 
> Another concern that arises from this rational is whether any context
> could be Agile. And the way I see, it couldn't. Applying Agile to some
> deterministic nature works might result in waste. The contexts that
> benefits from experimentation, that ones, would be eligible to be and use
> Agile.
> 
> 
> Bests,
> 
> Rafael Buzon
> 
> 
> ---In [email protected], <yahoo@...> wrote :
> 
> 
> Fair enough, Dave. This was not to replace the Manifesto or for training
> in any way. This was to explain to professional friends what we are doing,
> in simple business terms. It’s my distillation. As a distillation, it’s a
> lossy compression algorithm. But I thought it communicated the nature of
> the domain in a way that many professionals I know can easily grasp. I’m
> not sure, though, that I agree with you that the implications of the
> Manifesto are obvious. If that were true, the glaring delta between the
> manifesto and what most companies are really doing wrote be a whole lot
> more apparent to them. IMO. I like the phrasing you have of “working
> software to interact with,” and I may incorporate that. It is still people
> collaborating to discover what the product wants to be.
> 
> 
>>> On May 2, 2018, at 9:15 AM, dave.barrett@...
>>> <mailto:dave.barrett@...> [SCRUMDEVELOPMENT]
>>> <[email protected]
>>> <mailto:[email protected]> > wrote:
>>> 
>>> 
>>> I'm struggling to see value in this definition beyond the content
>>> contained in the two pages on Agile Manifesto website. I had to go back
>>> and look at it, which I recommend that everyone do from time to time,
>>> and it really does seem complete and clear even after all of these
>>> years.
>>> 
>>> 
>>> Items that aren't included on the Manifesto site, like "creating
>>> cross-functional teams", aren't really part of Agile, IMHO. This one in
>>> particular seems like a bit of a pipe dream, really. People aren't
>>> fungible resources and shouldn't be organized like they are. And, surely
>>> the principle that, "The best architectures, requirements, and designs
>>> emerge from self-organizing teams.", would win out if the team decided
>>> that it wanted to work in a very siloed manner?
>>> 
>>> 
>>> I'm not trying to be hyper-critical, but one of the big issues we have
>>> in the Agile/Scrum world seems be competing definitions about
>>> fundamental concepts. Here we have 4 main clauses in the Manifesto, and
>>> 12 underlying principles. It's short, simple and the implications are
>>> fairly obvious.
>>> 
>>> If there was one explanatory item that I'd ever feel was needed it would
>>> be this: Users never really fully engage in the software design process
>>> until you give them working software to interact with. Requirements,
>>> white-board diagrams, meetings, demos, mock-ups, prototypes or any other
>>> aid you can try will not elicit the input that you need from the
>>> customer to build the right software. The only defense against this is
>>> write a minimal amount of working software and get it into the customers
>>> hands as soon as possible, then listen to what they say.
>>> 
>>> It's clear to me that the authors of the manifesto completely understood
>>> this. The first 4 principles are all about making that happen.
>>> 
>>> dave
>>> 
>>> 
>>> \
>>> 
>>> 
> 
>



------------------------------------
Posted by: "Alexander Kriegisch" <[email protected]>
------------------------------------

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected]