Yes we do. I view Agile largely as TDD/BDD and the principles in the Manifesto…
And btw I love Dave’s talk. I think part of it is also generational. I was studying Computer Science in the late 90’s when TDD was not really a thaang yet. Two snaaps…
From my experience TDD if done right, gives us an opportunity to think about the problem outside of the problem versus being swamped in all the details and considerations. It allows us to get some separation. If you’ve developed great cognitive muscles to do this without the need for separation than by all means you’re lucky.
I’ve also found that it cuts down on uncertainty because it forces you to think about situations upfront or atleast have a list of things you need to think about potentially. So that when biz/prod dev approaches you for example you don’t have this wide-eyed glare. To which protoyping is also great…
I think the point is not to abuse agile but stay true to its spirit, its principles. Generally most people would agree that flexibility, clarity, good design and trust but verify are all worthwhile.
When I was learning Elixir and OTP sort of at the same time. (LOL). I intentionally performed some constraint relaxation - in the form of Lagragian Relaxation. Meaning I focused on a simpler problem while incurring a bit of a penalty which I would resolve later.
I clearly had a lot to learn, and so I deferred doing some of the tests upfront until I was more comfortable with the platform. I did incur a bit of a penalty to focus on perhaps a “simpler” problem by reducing the number of things to learn.
However now its quite easy for me to TDD with Elixir and then drive code…
Sometimes you have to pick your battles and I’ve found agile generally very helpful.
A pattern of practice is a technique that is understood to work with an understanding of why it works and why it might not work and in what context it works and in what context it does not work and the problem here is that we sometimes get so hung up on the mechanics of something that we forget that we’re actually supposed to use these as channels for thinking instead of replacements for thinking.
And here’s Uncle Bob again (I want you for the TDD armee!), episode 99.000: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html
Discussions about episode 99.000 are easy to find with google for those interested.
For those not having read a former thread: BDD / TDD criticized
Moreover, on guru-driven (Uncle Bob is one of the gurus I find) agile development:
We observe a rising scepticism towards Agile Methods:
practitioners are not able to use them in an efficient and
effective way since the underlying assumptions are hidden
by gurus. This missing knowledge is furthermore used by
agile zealots to indeed legitimize hacker behaviour. The
reputation of Agile is at stake.
To avoid that Agile Methods become obsolete, we think
it is necessary to understand software development process
tactics, i.e., knowledge about when to use which practice,
knowing its advantages, its disadvantages, and how to
apply it.
Therefore, we propose the use an approach to collect
falsifiable knowledge about agile methods, for example
using the Quality Improvement Paradigm.
To change this attitude, i.e., to switch from believing a
guru to adopt a scientific approach requires educational,
cultural, and managerial changes. To study how to accomplish
these, will be the challenge of the future.
TDD is useful mostly because it makes you think before you implement. Tests are
"a piss-poor way of trying to specify something." (certainly hard algorithms)
In this regard, Clojure.Spec is a great feature, to me is on par of dependent type systems, but more pragmatic. There is a implementation similar from @vic for Elixir. I’m planning to experiment with it soon.
very interesting discussion about if we need agile software development or not.
We are researchers from the department of Information Systems & Electronic Services at the University of Technology Darmstadt, Germany.
Our intention is to investigate the use of agile methodological practices commonly used by software developers and especially the negative impact of agile method’s application on them.
The topic is currently of major interest in science, because so far only positive effects were at the center of the investigation.
By participating in our research and sharing insights of your daily work experience and procedures you could contribute to a modern
research topic, and help us build better theoretical models that allow your future managers to design more appropriate work environments for you.
To express your mind, we have designed a questionnaire which aims at your personal perception, there is no right nor wrong. It is your personal opinion that matters.
Furthermore, the information that you provide by completing the questionnaire will be collected anonymously and we will not ask you to give any contact details,
except you explicitly want this.
Dear Stefan,
thanks alot for your input. I understand your denial of this multiple choice questions. A lot of them are inspired by pychological researchers whose findings about psychological strain were adapted to to get insights about the emotional feeling of information system developers in agile project groups.
I can understand your desire to express your ideas more elaborately. At the moment, we are thinking about making some interviews. Would you be interested to participate?
I ensure you that the interview would be written, you have all kind of freedom to express your mind, you can review it beforehand and there would be no censorship guaranteed with probability 1.
I am going to discuss with my colleagues how we might organize such an interview questionnaire.
Here is another well written piece http://www.elegantcoding.com/2017/04/the-problem-with-todays-software.html with some interesting links for your investigations. Another tip: learn yourself by experience. You only learn to hate agile (yes, I hate it, to the bone!) by participating. Not at the uni. Combine experience and theory, improve agile itself “in an iterative way”. It could be like learning to teach in practice while you’re doing didactics at the end of an msc study.
This is a pretty old dream and I sadly never seen it working at all. Back when I started coding for a living (late 2001) stuff like IBM Rational and UML diagrams / interpreters were selling as hot cakes yet nobody in the company I was in ever managed to extract a value out of them. And believe me, they tried and tried and then tried some more, for 5 years, and were still trying by the time I left.
I agree that a business engineer must model processes in a similar fashion as you showed here, however:
This is too specialized a position for most small-to-medium businesses to even know exists. Only huge corps where the mid-tier manager has to justify their spendings so as not to face budget cuts would really turn to such people.
Most businesses have no idea that they might need such an expert and they haven’t realized their need for it yet (most likely never will).
Most businesses would be skeptical of the real value such expert would eventually deliver and would most likely never hire them on this basis alone.
It doesn’t stop bureaucracy; it merely redirects it somewhere else – namely forces the programmer(s) to know yet another methodology and be shoehorned into communicating through it instead of, you know, plain old human conversations with a paper and a pen on the table.
Many managers just cannot breathe if they don’t put their finger on the process often – if you give them these cryptic (to them) diagrams they’ll dismiss you and just hand-wave their way to their familiar business lingo and you are back at square one where nobody pays attention to the diagrams. So using such tooling and processes requires tons of discipline and a realized need in the organization that these are actually needed and will contribute value.
Most stakeholders could be business engineers because they hold critically important information about business rules and processes that they want encoded in a computer system but every single one I knew was hesitant or downright sabotaging to the idea of learning specialized terminology and tooling to be able to project their insights to the lower-level executors (the programmers).
I have a lot of respect for the people who manage to make all of this work – and you’re apparently one of them. So hats off to you! You’re a rare breed of a serious engineer.
Truthfully though, and back to the main topic, 2-3 day iterations and then touching base and correcting course is all that 90% of my projects ever needed. Everything else was unnecessary red tape that only annoyed everybody in the chain to no end and made productive work near impossible.
The original “Agile” meaning has been hijacked to hell and back, several times, and it’s a practically meaningless buzzword in the IT area for a while now.
And the so-called “Scrum Masters” are basically overseers that the mid/high managers hire so as to have a more intimate knowledge on the internal workings of the team and be able to scorn people more successfully. That’s all I’ve ever seen from them. They’re basically the king’s executors. Like Hela in “Thor: Ragnarok” said: “They not only executed the king’s enemies, but also executed the king’s vision… [pause] …but they mostly executed people.” – I think that captures the essence of the Scrum Masters pretty well.
I find the agile manifesto not a very interesting paper. Just a couple of statements put together by a couple of guru’s (see the guru problem: http://darkagilemanifesto.org/dark-side-of-agile-janes-succi-splash-2012.pdf ). What I find important is making your software agile. When your software is not agile you can sprint and talk your heads off on endless scrum meetings, but all you do is push an elephant (hear this great presentation by Hickey: https://www.youtube.com/watch?v=rI8tNMsozo0). Another one you will like (it’s in line with your remarks about the scrum master role: https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church).
On your remarks about bpm as I showed (a couple of things): I do not find that processes should be modelled in this way (did I write that?) perse. It is a choice that you have. If you do not choose to use it, the many years of research and development and use in practice of bpm can learn you a couple of things. Last time I showed my small (very very incomplete) bpms to a productmgr at the company where I’m doing a contactorjob at the moment, this mgr noticed a lot that is lacking in their homegrown workflowsolution. Maybe you have not seen working solutions, but they exist, in abundance. F. e. the bpmn and dmn modelers I use are open source from camunda, you can find them on github. Zalando works with camunda bpm https://camunda.com/case-studies/zalando/. Scepticism is good, I f.e. recently put messages about external dsl’s like bpmn on this forum. But it is good to inform oneself also, even about things that nauseate sometimes, to be able to construct opinions that are well grounded and eventually learn a couple of things that might prove of use.
I fully agree we must all keep an open mind at all times. I’ve dug myself into such a hole in terms of career and thinking before I discovered Elixir, Go and Clojure (LISP) that I cannot even begin to describe how narrow-minded and stupid I was. What divides great programmers from mediocre ones is the ability of the former to constantly self-improve, be curious and never settle for “good enough”.
To that end, I also agree that ideas and tools like BPMN and DMN are useful and practical. And that they might open up new perspectives in front of their students. All of this is true.
What I find myself in some disagreement with you though is the necessity of these ideas and tools; the criticality of their presence in a given project. Even though we must always strive for being better, we only have so much time to work (or even live). I am currently in the process of working the depth of my new skills (before going wide again, namely learning other languages / frameworks) and maybe this is why I somewhat degrade the value of process modelling tooling. Excuse me for that, I am trying very hard not to be biased. Just trying to combine having a lot of culture plus getting work done. It’s a tough balance.
As for the links, I already read all that you pasted in this thread. Awesome reading! I am very thankful for your sharing them.
Scrum, Agile
agile
