3 ms·

I'd love to see someone come up with a checklist of where you should/shouldn't agile. If you can get Gartner to publish it, we'd end this whole top down agile

I'd love to see someone come up with a checklist of where you should/shouldn't agile. If you can get Gartner to publish it, we'd end this whole top down agile charade. Things like * max team size * type of application * type of user * geographic distribution A) Agile may work for a team of 5 sitting in the same office working on the latest dating app to MVP their way from text to sending dicks pics to sending xxx videos as they A/B test on their large userbase, iterating the UI design with color/font/button/wording changes along the way. You MVP because you aren't sure what the users want and have an easy way to measure it as you go, so there's no need for 6-12 month roadmaps, maybe, or at least you an convince yourself of that. B) Agile may NOT work on a team of 25 sitting in 5 countries, working on replacing a legacy infrastructure application that say, moves your money from one financial institution to another. The users are.. other applications interacting with your infra, you can't A/B test moving real money, and you internally have had to derive a set of requirements based on existing processes/flows, and can lay down a 6-12 month roadmap with your project manager. There's no MVP of "well first we will work on sending integer dollar values, then we'll work on sending decimal dollar values". There's no UI so theres no buttons to add/remove or change the color, font and wording of the text forms. Etc Many of us are a lot closer to working on Type B software than we are on Type A software.

jdlshore 5y ago
I have exactly that in my book, in chapter 4. The chapter outline is online and will give you a good idea of what to look for: https://www.jamesshore.com/v2/books/aoad2/invest_in_agility https://www.jamesshore.com/v2/books/aoad2/invest_in_agility
deleted 5y ago
[deleted]
corpMaverick 5y ago
Agile is much more than Scrum. There many different ways to do Agile. Just as an example Scott McConnell has a great book called Rapid Application Development (1996) where he documents many best practices and approaches that are essentially Agile, but that book predates the signing of "The Agile Manifesto"(2001). One of the practices is that you should carefully select the project life cycle model. Among the options that are documented in the book: - Pure Waterfall - Code-and-Fix. - Spiral. - Modified Waterfalls. - Staged Delivery. - Design-to-Schedule. - Evolutionary Delivery. - Design-to-Tools. - Commercial Off-the-Shelf Software. McConnell gives you enough information to help you make a choice. On the other hand Scrum tells you to treat every project the same way and most people do not know why things are done in certain way. They just parrot the same phrases they heard in their two weeks Scrum training and typically the Scrum Master knows nothing about software development him/her self.
- steveBK123 5y ago
  Thanks for the reference, this will make for some interesting reading. Agreed, I think the problem is the agile industrial complex has settled on scrum training, so when your CTO buys into agile, that is what you get. The consultants and training programs are all the same orthodoxy. Further, whatever flavor they decide on at the top ends up being applied to a wide range of teams below, which otherwise would naturally have different project life cycle models... A firm I was at not only had agile scrum firm-wide, but mandated we all have same length sprints ending on the same day of the week. This way we would all be "aligned". Also it meant it was impossible to book a conference room as they were 200% subscribed on sprintmas day by all teams... After 6 months they at least decided we could at least start/end on different days.
Zigurd 5y ago
Start with why Agile was created in the first place: The formalisms of critical path analysis and waterfall project planning did not work well for most software projects. Why? Because software is often entirely new, contains no repeating tasks, Therefore schedule risk is high compared to other kinds of projects. Agile gives a team flexibility to assign tasks to team members for each iteration. While legacy project management styles entail frequent replanning because you can't do a proper resource-leveled critical path analysis without a plan for resource deployment. Agile is not as precise about projections of project completion, but you know that precise scheduling is not possible for a lot of software development. Agile gets slagged for wireframe-driven development. If your view of Agile is colored by people drawing pictures instead of understanding data and functional requirements, that's not why Agile was created.

jdlshore 5y ago

I have exactly that in my book, in chapter 4. The chapter outline is online and will give you a good idea of what to look for: https://www.jamesshore.com/v2/books/aoad2/invest_in_agility https://www.jamesshore.com/v2/books/aoad2/invest_in_agility

deleted 5y ago

[deleted]

corpMaverick 5y ago

Agile is much more than Scrum. There many different ways to do Agile. Just as an example Scott McConnell has a great book called Rapid Application Development (1996) where he documents many best practices and approaches that are essentially Agile, but that book predates the signing of "The Agile Manifesto"(2001). One of the practices is that you should carefully select the project life cycle model. Among the options that are documented in the book: - Pure Waterfall - Code-and-Fix. - Spiral. - Modified Waterfalls. - Staged Delivery. - Design-to-Schedule. - Evolutionary Delivery. - Design-to-Tools. - Commercial Off-the-Shelf Software. McConnell gives you enough information to help you make a choice. On the other hand Scrum tells you to treat every project the same way and most people do not know why things are done in certain way. They just parrot the same phrases they heard in their two weeks Scrum training and typically the Scrum Master knows nothing about software development him/her self.

steveBK123 5y ago
Thanks for the reference, this will make for some interesting reading. Agreed, I think the problem is the agile industrial complex has settled on scrum training, so when your CTO buys into agile, that is what you get. The consultants and training programs are all the same orthodoxy. Further, whatever flavor they decide on at the top ends up being applied to a wide range of teams below, which otherwise would naturally have different project life cycle models... A firm I was at not only had agile scrum firm-wide, but mandated we all have same length sprints ending on the same day of the week. This way we would all be "aligned". Also it meant it was impossible to book a conference room as they were 200% subscribed on sprintmas day by all teams... After 6 months they at least decided we could at least start/end on different days.

Zigurd 5y ago

Start with why Agile was created in the first place: The formalisms of critical path analysis and waterfall project planning did not work well for most software projects. Why? Because software is often entirely new, contains no repeating tasks, Therefore schedule risk is high compared to other kinds of projects. Agile gives a team flexibility to assign tasks to team members for each iteration. While legacy project management styles entail frequent replanning because you can't do a proper resource-leveled critical path analysis without a plan for resource deployment. Agile is not as precise about projections of project completion, but you know that precise scheduling is not possible for a lot of software development. Agile gets slagged for wireframe-driven development. If your view of Agile is colored by people drawing pictures instead of understanding data and functional requirements, that's not why Agile was created.