Quora.com is a venue where people can submit questions on topics, and then experts on those topics, often people working in that industry, can submit answers. What makes Quora so brilliant is that you'll often find answers from some of the top names in an industry. It's a treasure trove of accurate information directly from the source.
For this article, we found five Killer quora answers on agile programming that users had submitted to Quora:
1. What are the differences between SCRUM, XP and Agile in general?
Jeff Sutherland, inventor and co-creator of scrum, explained that "the best Scrum teams implement XP engineering practices inside the Scrum. The best XP teams wrap Scrum around XP as it allows them to scale and take advantage of the high performance gains possible with Scrum."
In addition to this insight, Sutherland provides a detailed history on the development of agile programming and how scrum and XP fell into place in the context of that history. He notes that he started his first Scrum project in 1993 at Easel corporation, and he based their work on a book by Takeuchi and Nonaka called "The New New Product Development Game," published in 1986 by the Harvard Business Review. You can see his full answer, with all the fascinating historical details, here.
2. How many user stories are optimal for an Agile software project?
Cliff Gilley, an Agile practitioner for 15 years, explained that there is no magic number. User stories should reflect user goals, features, and functionality. He makes an important point: "however many of those [features, functionality, user goals] you need to document and execute is the number of stories that you're going to need." His personal preference, however, is no less than two: the story the team is currently working on and the next story that is in need of work, "ready to go as soon as the team finishes the current story," as he explains in his answer, which you can read in full here.
3. Can you recommend books which walk through a programming problem in an agile context?
Warren Wise gave the following insightful answer:
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin? It's an old book (2002), but it explains agile principles very well and provides a good working example of agile development practices (e.g., test driven development, refactoring). It also illuminates the SOLID principles of object-oriented development. Code examples are in Java (mind you, it's the version that was in use at the time).
As old as this book is, I recommend it because the author's fundamental understanding of agility is phenomenal. Also, when it comes to object orientation, I've found that may of the earlier books are actually the most enlightening.
4. Why do people choose Scrum over extreme programming when both are frameworks of Agile?
Gerry Claps, VP at Blossom.io, a Scrum master and product owner, wrote this in reply:
Comfort. Why? Scrum offers more 'standard' management artifacts and practices. For example:
- Meetings --> Daily standup, Sprint Review, Retrospective
- Documentation --> Product Backlog, Sprint Backlog
- Metrics --> Velocity, Burndown chart
Extreme Programming (XP) is focused around engineering practices, which work great in almost any software development context, but are less useful in managing the work itself.
5. How shall I adapt Scrum to be used in a multiple project/program environment?
Murray Robinson, Agile practitioner and evangelist, wrote the following answer:
The scrum view is that you work with your senior product owners and scrum masters to break your program of work up into independent chunks of functionality that deliver customer value and that can be progressively delivered by a cross functional scrum team of 4 to 8 people within 2 to 4 months (about $200k of work on average). You put these epics in a program back log, estimate them at a high level and assign them to scrum teams in order of priority. As the teams work through the back log you calculate program velocity and run a program burn up or burn down chart.
If you have a lot of work you have many scrum teams operating independently and delivering frequently so you get almost continuous delivery of functionality and business value into production. If the teams need to coordinate their work they do so through a daily scrum of scrums. In this approach the project manager steps up to the program manager role and has multiple scrum masters reporting to them. The big assumption underlying this model is that you can break the work up into many small independent chunks that can be delivered in a few months. This can be difficult to do in practice. The business may not be able to elaborate or prioritize epics or get funding until they can have completed an overall product, process and UI design; and the technical teams may not be able to estimate, prioritize or elaborate the epics until they have designed the system architecture they have in common.
Open Up Feed