Slashdot Mirror
The State of Agile Software in 2018 (martinfowler.com)
On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles, writes programmer Martin Fowler. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects), he added. An anonymous reader shares his post: Now agile is everywhere, it's popular, but there's been an important shift. It was summed up quite nicely by a colleague of mine who said, "In the old days when we talked about doing agile, there was always this pushback right from the beginning from a client, and that would bring out some important conversations that we would have. Now, they say, 'Oh, yeah, we're doing agile already,' but you go in there and you suddenly find there's some very big differences to what we expect to be doing. As ThoughtWorks, we like to think we're very deeply steeped in agile notions, and yet we're going to a company that says, "Yeah, we're doing agile, it's no problem," and we find a very different world to what we expect.
Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile," or specifically "Dark Scrum." This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird. So that's our current battle. It's not about getting agile respectable enough to have a crowd like this come to a conference like this, it's realizing that a lot of what people are doing and calling agile, just isn't. We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile,' we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for.
Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile," or specifically "Dark Scrum." This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird. So that's our current battle. It's not about getting agile respectable enough to have a crowd like this come to a conference like this, it's realizing that a lot of what people are doing and calling agile, just isn't. We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile,' we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for.
If I learned one thing from experience with "agile development", it is how totally different from the IT-perspective it is seen from non-IT people, especially customers and managers:
Customers: "Agile is great, because now we can change requirements whenever we like, and don't even need to think of what we really need in the beginning. Ah, and by the way: We don't have time to sit in your sprint-planning meetings. We just expect you to deliver."
Managers: "Agile is great, because now none of those IT wisenheimers can obstruct our great vision by telling us how time and effort consuming our projects will be before implementation starts. Once it becomes too obvious how much more work it will take to turn the software into something useful, it's too late to cancel the project as a whole, and we'll just demand long hours from the programmers."
Agile is judged by its own metrics. Of course it is done "correctly". Whether they laugh at others' implementation of Agile is irrelevant.
Yes, I have read the manifesto. Unfortunately, extracting my commentary on it from my plain-text document will not look good, and I wrote it a long time ago without fully reviewing what I wrote, but I don't care, since nobody will read it anyway.
Here's the Agile Manefesto, with commentary by me:
> We are uncovering better ways of developing software by doing it and
> helping others do it. Through this work we have come to value:
> Individuals and interactions over processes and tools
Processes and tools empower individuals to get their jobs done
without uncertainty and with great efficiency. Also, many agile
shops insist on using certain methodoligies that require certain
tools (e.g. Rational Rose, Microsoft Visual Studio), so this is
clearly not a shared value.
Valuing individuals is good. The proper way to do this is to
adjust the processes and tools to meet the needs of the
individuals, rather than dictacting what sounds best to
everyone without feedback.
Wikipedia provides elaborations:
> ... self-organization and motivation are important, as are
> interactions like co-location and pair programming.
What does this even mean? Are you saying non-"agile" methods
do not encourage self-organization and motivation? Motivation
in particular is completely dependent on the individual.
Agile methods do not motivate me, for example. Self-organization
sounds a lot like "we have no clue how to manage this, so we'll
rely on you to, even though you probably have no clue, either".
ISO 9001 compliance, which was popular for a time, requires
that every task an indivdual performs be written down. This
prevents management from inventing new tasks outside of the
employees scope, helps orient new employees, and when it
comes time for status reporting and performance reviews, it
gives the employee a reference against which to evaluate.
Self-organization can be part of that, by not forcing
procedures that dictate organization, but I don't see a lot
of that coming from the "agile" programming folks. Instead,
a new set of rules is forced on people, claiming that they
are somehow superior.
Co-location is fine, and sa
When done right, it lets managers get out of the way of developers, because it replaces the boss being in charge with the team being self-led, with the "boss" clearing the path and facilitating when things get stuck, and you empower the product owners with real authority to make decisions, empower teams to do real estimation, etc. When I've seen agile fail, it's because the management couldn't give up control to the team, so they basically ran waterfall development using agile terminology. That is, when you make fixed scope and fixed time commitments, because the boss (or product owner) says so, you're waterfall - it doesn't matter if you use story points and sprints to implement your waterfall product, because you've missed the fundamental point of agile.
Call it Scrum, XP, Kanban, etc. - it's all about measuring and optimizing a process by empowering the people who do the work to improve how they do the work. Everything else is just a means to that end. The techniques work, which is why companies who do them tend to outperform the companies who don't. But a bad team with bad management who uses the form of agile without the substance is still screwed.
Enable 3D printed prosthetics!