2 Replies to ““It’s Just the First Slip””

  1. This article was written 20 years ago, but the problem it describes, for me, is so actual. 20 years ago the agile manifesto was not signed, so all the agile stuff was not the mainstream thing to do the work. Still, I find it actual because:

    “He claimed that your first project slip isn’t so bad; the third or fourth project slips are the bad ones.” -> lack of knowledge/awareness regarding complex adaptive systems. Is not needed to have a big cause to have a big effect. Small details are important also.

    -” The requirements weren’t done, but we had to get started, so we started designing without knowing all the requirements.” I read this text as if they started coding without knowing what to code. Even with agility, analysis is important, but I’m not thinking to business analysts, no no. We need to know what we will code not just say ” we will figure it afterwards, we already have something”.

    “How much testing did you plan for this project?” – > The same is happening now. It is not known how to do the testing and what guides that test planning. Testing, for me, is about finding problems guided by risks. And all the dominant thinking with test automation does not help either, because it shifts the attention of what testing is to just some “automation”.
    “Well, since the requirements weren’t done, we couldn’t finish the design on time. Since the design wasn’t done, the coding was a little late.” I read “requirements” word as use cases, or what Weinberg wrote about requirements. Architecture, design is guided by uses cases/activities/business. The same is now :(. The tech stuff prevails not the business which guides the tech thing. And yes, I say this with all the DDD, microservices hussle which is now. We, as industry, did not actually understood OOP at all… but we found the antidote:microservices, DDD. No matter the problem, the response is “microservices”.

    I liked a lot how the slips “talk” to the manager.

    1. Marius, thank you. At the time, I’d used a variety of incremental life cycles, either design-to-schedule or staged delivery. Those life cycles focus on finishing feature sets. (Not the way we do now in agile approaches where we iterate over a feature set. No, those life cycles assume you finish an entire feature set. They were quite useful for deliverable-based planning.)

      I like the way you talk about testing as “finding problems guided by risks.” Yup, that’s how I think about testing, too.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.