What do you do when models collide? Every team has their own mental model of how things are supposed to work. We often call these “processes” or “methodologies”, but they are really just a shared understanding of how things get done by a team. Sometimes, however, problems can’t be tackled by just one team because of size, company structure, diversity of required skill sets, or any number of other reasons.
Videos on Scrum and Agile Project Management
There is a tendency to use agile software development approaches and all their practices simply because it is in the book. Why don’t we select the tools based on the context of the task we are trying to complete?
The nice metaphor of technical debt introduced some 18 years ago by Ward Cunningham has slowly taken roots in our collective conceptual toolbox, as a nice way to express some of the pains that software projects suffer from. Most software developers who have had some experience with significant, long-lived projects can feel it, sometimes point to it, but more than often can’t do much about it. In most cases, technical debt is seen as something very negative, burdening projects forever under increasing amount of interests. But some technical debt can be deliberate, more akin to borrowing to make an strategic investment, and this is especially the case for architectural-level debt.
Sometimes, user documentation is not a nice to have but a legal requirement or a requirement to meet a standard like the FDA. But more important, quality user documentation improves the usability of the product and enhances the credibility of the company.
Pair programming is sometimes the norm, and some developers really enjoy the collaboration, experiencing enhanced productivity. In other teams, pairing is shunned, avoided, or… faked. Angela Harms did a short survey about pairing attitudes and compared successful and unsuccessful pairing experiences.
Learn how you can improve your business analysis with Agile story mapping, a technique that maps your stories back to business value. Thus you will be able to know if they make or save the company money and you will learn the benefits of bi-directional requirements traceability .
Planning Poker is an Agile practice that harnesses the “wisdom of the crowd”. The goal of planning poker is not to derive an exact and accurate estimate that would stand all future scrutiny, but rather, to obtain a group estimate in a fast, cost effective and collaborative way.