4 ms·

I really like Dave Thomas’ talk Agile is dead long live agile. Dave’s name is listed as one of the creators of the agile manifesto. Basically, agile is an adje

• ethbr1 3y ago
  There should be a saying, to the effect of: no enterprise idea can survive intact if it doesn't include a space for consultants. Agile probably would have ended a lot better if it had been as designed... plus a requirement that you had to hire an agile specialist to sit in a closet. The agile specialist doesn't do anything but sit in the closet. ... but on the plus side, the agile specialist doesn't do anything but sit in the closet.
• h335ian 3y ago
  Been using ShapeUp for nearly a year now in an org of ~50 engineers. Let me start by saying, if you intend to adopt ShapeUp, spend a great deal of time reading and buying into their structure of teams. Aside from SIP/QA & KTLO work, they flatten the “Core Product team” and build ad-hoc teams for a pitch that has won at the betting table - for that cycle. Trying to maintain standing teams with domains of ownership is a very challenging way to adopt this process. In my experience, unless the entire org is drinking the kool-aid - hard - you end up with 6w cycles of waterfall. Pitches morph quickly from “present your idea that we bet against” to “write up a detailed design doc, along with an Epic, backlog and all projected work” - then the org will just do the work they want (betting or no). Now your team is committed to delivering on your pitch - any other work just gets dumped on the wayside - unless you’re on-call of course. As with any other incantation of an agile process, you can bastardize it to confusion, thinking you’re smarter, or “we’re adapting this to fit our org”. Folks, this stuff is a discipline. You have to buy in, you have to learn the principles, you have to practice them - as described - until you attain some degree of mastery that you can adapt. This is not an individuals game, this is at the org level. The individuals must commit with the org to gaining mastery before customizing to your liking. In spirit - there’s nothing fundamentally broken with Scrum or Kanban or ShapeUp or whatever. It’s really how you hold it - and yes you can shoot yourself and others in the face by holding it wrong.
  • andrei_says_ 3y ago
    Thank you for this. My sense is that shapeup requires more trust than what a large org is used to. Eliminates the micromanagement and limits the risk to n weeks.
• h335ian 3y ago
  Doubling down on my comments about ShapeUp (et al) as I reflect. Engineering management, in my experience, has an allergy to agility. They can and do take any methodology, turn it into a process with a rigor (they love that) and strip agility from the mix. They are addicted to well defined requirements, some degree of estimation and being able to predict/project things like delivery, velocity, contributor performance, etc. We engineers love the principles of agility, so engineering management tries over and over to find that happy medium where they have a well defined process that gives them what they want but imposes the least friction against the agility your engineers crave. Custom solutions win the day. I have lived through all of the above. I remember when Agile was introduced, do you? Do you recall how violently reactive engineering managers were to this concept? It goes against everything they are supposed to do - manage. Agility inherently means they lose some degree of management ability. It means they lose their precious waterfall where things are meticulously (ridiculously, inaccurately, elegantly, uselessly) pre-planned on paper. IMHO this is why we see every methodology that supports being Agile - bastardized to the point of confusion, academic arguments based on (not having actually learned, practiced, or gotten good at anything) gut feelings of “how we should do it here”. Leading, managing work, organizing resources and getting shit done is a skillset that encompassing multiple disciplines. All are documented and practicable - we apparently don’t have the discipline to actually read and practice. We’re like a bunch of yokels on YouTube commenting on who’s a better MMA fighter, telling Joe Rogan he’s wrong - but only a select handful of us actually speak from authority. Only a small handful will actually take on the RISK of trying to understand the literature and practice a methodology like a beginner - without questioning the teacher or the teachings. All that said. I have seen both Kanban and Scrum be wildly successful. The key ingredient in each of these was a shared humility and curiosity between engineers and managers and an environment that celebrated learnings and put no penalty on getting it wrong. The lack of hubris was absolutely the ticket to an agile environment where shit just got done, engineers had a GOOD TIME, we built meaningful product and we weren’t worried about blasting time in meetings because it never impeded our ability to get shit done. Once the engineering org can demonstrate its key metric (getting shit done) the battles with product cease!!! Product can trust that engineering will get shit done - without handwringing on “when” - and they can properly focus on “what” shit to get done. When engineering is flailing around on their methodology, process or agility - they lose trust. That’s when product starts thrashing. That’s when you start to see initiatives/projects start and never finish, along with shifting priorities. ShapeUp does an excellent job of giving product a tool to direct what work we’re doing - hopefully making sure we’re working on the right thing. However, if you’re trying to bastardize ShapeUp to fit your engineering org structure - it’s VERY difficult to demonstrate and project “well get this done”. Further, if you think you’re gonna keep your teams intact and do pitches per team - you’re already broken, committing to more than the org can deliver, creating conflict between teams on how to do the work, leading you right back to waterfall. Rather than building the right team of resources for the pitch/cycle - you now force all your teams to produce design docs, plans, backlogs - which have to go through review, get picked apart by other engineers, only to find your assumptions were wrong and the deliverable looks quite different than the design (shocker!!) I’ll conclude to say we’re likely all doing some degree of waterfall++, branded as some form of “agile” methodology. If you wish to see that change, encourage your peers and your managers to start with your team, pick a methodology, go exactly by the book, get “good” at it with practice over an extended period, collectively enjoy and DOCUMENT the many “aha!” moments along the way, the proliferate that out to the rest of the org. High performing teams are hard to ignore and at some point the org will ask why - simply be prepared with HOW you adopted and your learnings. Good luck out there