19 ms·

It's interesting because "agile" can fail on both sides. This lampoons the enterprise side, in which you adopt "agile" practices inside rigorous change control

by asolove 13y ago

It's interesting because "agile" can fail on both sides. This lampoons the enterprise side, in which you adopt "agile" practices inside rigorous change control and long requirements documents. But there is also the cowboy/ninja failure mode, in which "agile" is used to rule out any strategic thinking, technical design, or requirements gathering. Not only can you fail on both sides, but you can be too far on one side and think that you haven't gone far enough. I've had startups tell me they were doing Scrum, but it had gotten so hard to estimate their work that they had "broken agile" by having "grooming sessions" to talk to stakeholders about upcoming work before it got into sprint. They were shocked to learn this was a required part of Scrum and that many books recommended that being up to 10% of the team's time. Another company I talked with was so concerned about their developers "continuously delivering" code that they were fighting to be "more Scrum" by changing their QA folks to be in a staggered sprint one week after the developers. They were shocked to learn that this was a widely-tried and widely-panned approach that was philosophically opposed to the roots of Scrum. Now, I remember hearing examples like these before I had really dived into Scrum, and assuming it was a "no true Scotsman" where, whatever you did, someone would find a way to say it wasn't Scrum. But after some very good books and talking with experienced people (who were involved in the early stages, not bandwagon consultants), I now feel like I actually understand what Scrum is for and when it works, and can quickly spot people who don't understand the philosophy. Has anyone else experienced this? I wonder whether it is real experience or just an illusion my brain has created to give meaning to many months of painful trial and error. Nowadays I think of scrum as being about holistic product creation, about building a team that can deliver what customers will pay you for over the long-term. That requires breaking down most "process" to get "one-piece flow" on a complete team working as one to deliver new features. But it also includes the team building its own processes to make sure they are building the right thing to a high level of quality. That vision is anathema to cultures that value technical prowess, or pure speed, or meeting corporate objectives, or anything else other than building a team that can deliver value to customers over the long term. It's a challenge and a priority change for both corporate political environments and built-to-flip startups. And it's surprisingly hard to find a company that wants to pay you to build things their customers like, rather than using some other metric.

UK-AL 13y ago
Normally a good User Story, with 5 - 20 lines of acceptance criteria are optimal size for change/feature request.
- wpietri 13y ago
  Personally, I now consider that too long. I have built entire products using index cards with nothing more than 3-8 words on them, plus occasional temporary artifacts (whiteboard sketches, mocks, etc). In my view, stories are tokens for conversation. Now when I deal with teams who are writing down more than a few words, I look for barriers to conversation. E.g., not all the right people sitting together, or too much work in process.
tieTYT 13y ago
> Now, I remember hearing examples like these before I had really dived into Scrum, and assuming it was a "no true Scotsman" where, whatever you did, someone would find a way to say it wasn't Scrum. But after some very good books and talking with experienced people (who were involved in the early stages, not bandwagon consultants), I now feel like I actually understand what Scrum is for and when it works I get the "no true Scotsman" sense myself. What book(s) was most helpful in pinning down what scrum is and isn't?
- dragonwriter 13y ago
  > What book(s) was most helpful in pinning down what scrum is and isn't? By definition, I think that would have to be the Scrum Guide [1]. "Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum." [1] https://www.scrum.org/Scrum-Guide https://www.scrum.org/Scrum-Guide
- asolove 13y ago
  I recommend "The Scrum guide" and "Extreme Programming Explained" as ways to learn about the systems themselves. Thinking about it, the book that actually taught me to understand what the early agile people thought was Christopher Alexander's book "The timeless way of building." The book is about architecture rather than software, but the underlying idea is right on. It starts by addressing what is the point of building? Some people try to optimize speed, or predictability, or how good the building looks. But Alexander says the point of a building is to be lived/worked in, and it should be measured by how it improves the human lives of people around it. This implies doing the design and building in a whole different way, and thinking about the relationships between builders and users in a different way. The "agile" idea is similar. People who try to "use agile" to accomplish their goal of just making software really fast, or making lots of money, are missing the point. Agile is actually about building software that is good, in a way that is sustainable for users, builders, and a company, and makes everyone involved better. If you use Scrum in the context of those values, you may succeed. But the vast majority of people who adopt scrum, and perhaps the majority of consultants and explanations trying to "sell" Scrum, just use it to wring every ounce of effort out of your employees, or to ship something crummy fast. That ends up not really working, and in my experience making environments even worse than they were before.

by asolove 13y ago

UK-AL 13y ago

Normally a good User Story, with 5 - 20 lines of acceptance criteria are optimal size for change/feature request.

wpietri 13y ago
Personally, I now consider that too long. I have built entire products using index cards with nothing more than 3-8 words on them, plus occasional temporary artifacts (whiteboard sketches, mocks, etc). In my view, stories are tokens for conversation. Now when I deal with teams who are writing down more than a few words, I look for barriers to conversation. E.g., not all the right people sitting together, or too much work in process.

tieTYT 13y ago

> Now, I remember hearing examples like these before I had really dived into Scrum, and assuming it was a "no true Scotsman" where, whatever you did, someone would find a way to say it wasn't Scrum. But after some very good books and talking with experienced people (who were involved in the early stages, not bandwagon consultants), I now feel like I actually understand what Scrum is for and when it works I get the "no true Scotsman" sense myself. What book(s) was most helpful in pinning down what scrum is and isn't?

dragonwriter 13y ago
> What book(s) was most helpful in pinning down what scrum is and isn't? By definition, I think that would have to be the Scrum Guide [1]. "Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum." [1] https://www.scrum.org/Scrum-Guide https://www.scrum.org/Scrum-Guide
asolove 13y ago
I recommend "The Scrum guide" and "Extreme Programming Explained" as ways to learn about the systems themselves. Thinking about it, the book that actually taught me to understand what the early agile people thought was Christopher Alexander's book "The timeless way of building." The book is about architecture rather than software, but the underlying idea is right on. It starts by addressing what is the point of building? Some people try to optimize speed, or predictability, or how good the building looks. But Alexander says the point of a building is to be lived/worked in, and it should be measured by how it improves the human lives of people around it. This implies doing the design and building in a whole different way, and thinking about the relationships between builders and users in a different way. The "agile" idea is similar. People who try to "use agile" to accomplish their goal of just making software really fast, or making lots of money, are missing the point. Agile is actually about building software that is good, in a way that is sustainable for users, builders, and a company, and makes everyone involved better. If you use Scrum in the context of those values, you may succeed. But the vast majority of people who adopt scrum, and perhaps the majority of consultants and explanations trying to "sell" Scrum, just use it to wring every ounce of effort out of your employees, or to ship something crummy fast. That ends up not really working, and in my experience making environments even worse than they were before.