{"id":14887,"date":"2015-11-13T08:00:09","date_gmt":"2015-11-13T13:00:09","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=14887"},"modified":"2018-04-13T12:08:02","modified_gmt":"2018-04-13T16:08:02","slug":"dont-go-chasing-waterfall","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/dont-go-chasing-waterfall\/","title":{"rendered":"Don’t Go Chasing Waterfall"},"content":{"rendered":"

Working in software, you\u2019ll find three general models for process workflow: SDLC\/Waterfall, Kanban, and Scrum. If you\u2019re on a Waterfall project, stop what you\u2019re doing and go jump out a window. (Kidding. Mostly. Use a parachute\u2026.) If you have a good management team and a good set of colleagues, even if you\u2019re on an SDLC\/Waterfall project, the idea would be to move the operational strategy more in the direction of agile development processes. But which one is the right one? Why doesn\u2019t Waterfall work in software?\\n\\nIf you\u2019re on an agile project, you should note that there\u2019s no such thing as a cookie-cutter development process. That\u2019s what makes it agile; it\u2019s flexible and malleable so that as the engineering team evolves to meet the needs of the customers, the process can evolve with them. One of Waterfall\u2019s biggest weaknesses is its extreme rigidity, making it ill-suited for any agile project you\u2019re doing.\\n\\nIn truth, Waterfall works for certain kinds of projects, but those projects don\u2019t tend to move software around, and they tend to have a predictable process. Nothing about software is ever predictable, and this is generally why Waterfall does not work in software. Waterfall thrives on predictability.\\n\\nRegardless, for any solid process to work, a crucial foundational point has to be in place. For instance, Kanban works to limit Work in Progress. Scrum works to limit Scope. Both work to tighten feedback loops between idea and production.\\n\\n<\/p>\n

Waterfall: Not For Programmer Consumption<\/h1>\n

\\n\\n\"youngDon\u2019t get me wrong, I\u2019m sure some programmer somewhere got to participate in a Waterfall project, and everything was amazingly well done. Probably. Waterfall as a project management discipline works pretty well in fields where you have a good idea of the estimated time going into the work. If you\u2019re building a house, Waterfall is probably OK, and even preferred, because you want to get the plumber on site at the right time\u2014plumbers are expensive.\\n\\nOn a software project, the unpredictability of doing something brand new that was likely never done before makes it very difficult for Waterfall to work. Since this article is directed at more advanced programmers, I\u2019m not going to spend time explaining how it works, so if you really want to know you can look here.<\/a>\\n\\nThe reasons why Waterfall doesn\u2019t work well for software include:\\n\\n<\/p>\n

    \\n <\/p>\n
  1. Rigid timelines that make adjusting for unknowns impossible.<\/li>\n

    \\n <\/p>\n

  2. An inflexible scope that doesn\u2019t respond to changing customer needs.<\/li>\n

    \\n <\/p>\n

  3. A long feedback loop between idea and measurement.<\/li>\n

    \\n <\/p>\n

  4. Not being amenable to measurements\/adjustments\/reactions.<\/li>\n

    \\n<\/ol>\n

    \\n\\n<\/p>\n

    Agile: A Multifaceted Spectrum<\/h1>\n

    \\n\\nOn the other end of the engineering spectrum is the agile development concept. There\u2019s two general mechanisms for this: Kanban and Scrum.\\n\\n<\/p>\n

    What’s a Kanban?<\/h1>\n

    \\n\\nAccording to Google\u2019s dictionary, the literal definition of Kanban<\/a> helps explain how the mechanism works and is stated as \u201ca Japanese manufacturing system in which the supply of components is regulated through the use of a card displaying a sequence of specifications and instructions, sent along the production line.\u201d Also, Google tells us the origin derives from \u201cBillboard\u201d or \u201cSign.\u201d\\n\\n<\/p>\n

    Car Manufacturing?<\/h2>\n

    \\n\\n\"KanbanThe general idea of Kanban is that you have different columns on a board that represent issue statuses. And your whole team works to limit WIP (Work in Progress) in any one of those columns.\\n\\nThe Kanban process centers around bottleneck identification and elimination. Each lane on a Kanban board serves as a single step in the production process. If any one lane starts to fill up, the entire team stops and figures out what’s causing the blockage. This was adopted directly from car manufacturing. If one station in the output becomes a bottleneck, everyone works together to eliminate that bottleneck to optimize throughput.\\n\\nIf you have ever used Trello for team or personal management, it\u2019s Kanban in a nutshell. You put cards on a board, and follow them to completion. Even though Trello is pretty darned simple, I actually prefer an even simpler setup using OneNote.\\n\\nHere\u2019s my personal Kanban board on OneNote. It has a few more than those three statuses in it, and it combines home life and work life, but it\u2019s still simple to use and understand:\\n\\n

    \"OneNoteKanban\"<\/a>
    (Click to view full size image – it’s less blurry!)<\/figcaption><\/figure>\\n\\n\"OneNoteKanban\"<\/a>\\n\\n<\/p>\n

    That’s Oversimplified<\/h2>\n

    \\n\\nWhile Kanban depends on the specific nuances of the team you’re on in order to work, in general it operates best in a fully-automated, continuous delivery environment. It’s much more difficult to run Kanban on a team that depends on manual deployment because one of the columns would be deployment, and everything would get stuck there.\\n\\nAnd a column with 300 cards in it is hardly easy to keep track of.\\n\\nIf you want more information about how Kanban can work effectively, there\u2019s an almost non-fiction book called The Phoenix Project<\/i><\/a> that does a really good job explaining how to transition from a Waterfall mindset to a continuous delivery mindset. It\u2019s fun, and a bit silly\u2014but it definitely teaches the lessons of the continuous delivery concept well.\\n\\n<\/p>\n

    We Can\u2019t Really Kanban: Scrum to the Rescue?<\/h1>\n

    \\n\\nIf you absolutely cannot build continuous deployment into your process, you’re going to have better luck attacking your project using Scrum.\\n\\nIf you want to spend time understanding how Scrum is supposed to work, these guys did a fine job explaining the concept.<\/a>\\n\\nThe most important takeaway for making Scrum work is frozen scope. After you plan a sprint, nothing else gets in until the next sprint. That makes the sprint-planning meeting one of the most essential days in a Scrum sprint. Get the sprint scope right, and then don\u2019t let anybody change it. Period.\\n\\n<\/p>\n

    What About Fires?<\/h2>\n

    \\n\\n\"BigThe best analogy I can come up with for Scrum\/Kanban<\/a> is putting out a large forest fire.\\n\\nYou have to have two (or more) teams. One focuses on the parts of the forest that are already burning (Kanban) until the fire is out. The other focuses on the long term plan for preventing an as yet un-burnt forest from ignition (Scrum). The latter takes a different kind of planning and is proactive instead of reactive.\\n\\nThe best blend I see working well is a Kanban team dedicated to putting out the spot fires of escalated support, and a Scrum team dedicated to moving new scope and bug fixes forward by integrating product management into the single backlog.\\n\\nMore than anything else, for agile development to work in the general sense, you\u2019ll need to work with your peers and your product team to have a single, unified, and prioritized backlog. As long as the people managing your project get to decide what gets worked on first, the engineers get to decide how. A well governed backlog is critical for agile of any kind to work.\\n\\n<\/p>\n

    Should We Try Estimation?<\/h2>\n

    \\n\\nPlanning poker is a pretty critical part of how Scrum operates if you take the process literally. Getting the right amount of scope planned into a sprint takes a pretty delicate balance. Whether or not you include estimation as part of this process, the general idea is to get better at planning out each sprint so that you only put as much into it as you can get done during the sprint timeline.\\n\\nAnd, if you do decide to use estimation, by all means focus on complexity. Estimating based on time will only give you an aneurysm. And you\u2019ll always be wrong.\\n\\nHonestly, the most agile places I\u2019ve worked don\u2019t really pay too much attention to actually estimating the timeline for getting much of anything done. Instead, it\u2019s wiser to focus on the most important stuff that goes at the top of the priority list, and work on it until it’s done. Then move on to the most important next thing. If it\u2019s important, it doesn\u2019t matter how long it takes.<\/a> Granted, this takes continuous delivery to the ultimate extreme and really is a Kanban-only approach.\\n\\n<\/p>\n

    Keep It Simple<\/h1>\n

    \\n\\nAfter all, this is Simple Programmer<\/a>, right? The most important thing to do when you start making adjustments in your workflow is simplification. Start with a simple board that has three statuses on it: To Do, In Progress, Done. Hopefully, that workflow is painfully obvious, but if not:\\n\\nTo Do: You (or your team) haven\u2019t started on these things yet. The most important stuff is at the top.\\n\\n<\/p>\n