Uncharted Waters

Jun 21 2017   2:54PM GMT

Why is Agile shaped Like a Waterfall

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
agile management
Agile Methodologies
Agile Software

I have worked in several agile projects over the years and they overwhelmingly look like a phased waterfall project got squished into two weeks. Take each phase of a waterfall project — planning, design, coding, testing, delivery/maintenance — put them into a two week delivery cycle, and that is my experience of agile. I suspect that is the agile experience for a lot of other people as well.

I went to another local tech meetup yesterday. This was an introductory agile talk for people that didn’t have much exposure, but the content was driven mostly by audience questions. The content was very good. The speaker started drawing models of what a waterfall project looks like, what an agile project looks like, and then some process we like to wrap around modern software development.

That is when it clicked for me.

After the speaker went over basic models of software development he described two groups of people in the agile world. He described process people that take what a company is doing now, jam some process wrappers on top like Scrum and Kanban, and then leave for the next gig. The other group consisted of life coach type people that come in and “unleash the awesome”. The coaches observe and help amplify the good things that are happening, and starve the aspects of the development group that are making software worse or development slower.

Most agile implementations look like waterfall for two reasons: the common process tools looks exactly like a waterfall, and software craftsmanship is usually missing.

Take a look at kanban for example. This tool was designed at Toyota in the 1940s as a way to visualize work and limit work in progress. Over the past 10 years or so, kanban has become pervasive in software, but it is missing its soul. Instead of having three columns — to do, doing, and done — there is one for most phases of a waterfall. I usually see the columns todo, in development, ready to build, in test, ready to demo, and done. Also, instead of reducing work in progress, each column on the board is tall enough to require a head tilt to get a full view. Every piece and phase of work in a waterfall project are thrown into these kanban boards.

agilefall

The important piece missing though is code and software craftsmanship. Traditional development methods are slow. We would write software in batches and then push to a test environment….eventually. Someone might write unit tests if they felt like going the extra mile. Testers were mostly separated from the development process and had their own special slow way of handing their job. The software craftsmanship people took a look at this and said “this is dumb, we have to change” They focused on changing how they work with technology by introducing collaborative methods like XP, making TDD popular, and creating fast build and deploy tools.

The bad agile projects I have worked on still deliver software in batches, just in two weeks instead of 6 months. They still have phases for development, testing, and so on. And they still struggle to get the right software to market, on time. Despite all of that, they can check all of the “we’re agile” boxes for process and method.

The software craftsmanship people are successful regardless of what process tools they are given, because they are defining their own process.

Agile is still shaped like a waterfall because, at some point code still has to be written. Jamming a new process on top of archaic ways of developing new software doesn’t change anything. The DevOps and Continuous Delivery people are winning right now because they are willing to actually change how they work. Popular agile tools and coaches seem to be holding software development in the past.

4  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Matt Heusser
    One of the big insights I took from the original Royce paper is that testing, programming, analysis, these sorts of things are /activities/ not phases. A healthy project does all of them at the same time -- which I think is part of what you are getting at with your references to KanBan boards getting /wider/ with more columns.

    For most teams, moving from 2-month phases to 2-day phases in a 10-day sprint is probably an improvement. Is there a magic world of continuous collaboration that is possible beyond that? For many teams, I think so. It's just rare that I see someone really try to reach for it ...
    3,695 pointsBadges:
    report
  • spintreebob
    My Systems Analysis and Design class in 1983 described project management quite simply (my words, their concepts):
    Everything is repeatable iterations.  Iterations can be small or big.  Iterations can exist within iterations or overlap other iterations in the same way sets can be supersets, subsets, intersecting sets, etc.

    The iterations of Requirement Gathering can be large or small.
    The iterations of design can be large or small.
    The iterations of coding can be large or small.
    The iterations of testing can be large or small.
    The iterations of implementation can be large or small.
    The iterations of maintenance can be large or small.

    The iterations of one activity may or may not be concurrent, or overlap, or be a sequential process.  Iterations of the backend requirements, design, code, test, implement, maintenance may be different from those of middle ware, or those of the front end.

    Different vendors and languages traditions have different names for the same thing and waste time arguing over terminology.

    There is nothing new under the sun.
    60 pointsBadges:
    report
  • cMEYER1
    Agile focusses on one thing, that disappeared some 20 years ago for lack of availability of key users: the focus on business requirements. As such we must remember why and for what purpose we are developing code.
    Plus business cycles have accelerated, and technology has greatly improved so we should be able to code quicker with a good level of quality to reach business expectations. BUT you are right, while we re-emphasized the business requirements, we still need code craftmanship as well as secure infrastructure. Agile cycles must be phased in a well defined IT environment with clear discipline. This is not "I code as I want under pretext that I must be quick ;o)".
    Agile also means more testing effort, as we iterate more with key users. So one must understand what is really the value of agile, and not underestimate the necessary IT expertise around it.
    20 pointsBadges:
    report
  • appmakery
    This is true, it depends on the team size, budget, innovation and other such factors I guess. If you are a 2 team startup sitting in an apartment without much to lose, you can develop awesome apps sometimes because you test and release every day and every hour!
    150 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: