- Requirements engineers make decisions, they are not just documenters. Expect to see that product owners are the BAs. They will less often be called systems analysts, and more often called product owners. A few years ago, we shifted from calling our requirements team members “Business Analysts” and started calling them “Product Managers” because that’s really what they have to do – own the product, even if it’s just an internal IT system.
- BAs/Product Owners will be empowered to make decisions and not just sit around waiting on sign-off. They must be experts in the business. They must work with development, not just document for them. Once they do this, they can start to make very smart decisions about what should or should not make it in the product.
- Agile is not a fad, even NASA is doing it. That said, we will see variations on agile as it grows and evolves.
- The development team can add value about requirements, so collaborate with them. They don’t all just want to gold-plate scope or push back on what’s in or out – they love to build products, so use that to your advantage.
- The business is not always right, so you still need to ask questions. BAs/Product Owners must push back when something doesn’t make sense.
- Agile is actually seen to increase the value of requirements – just make them more solution focused, and not just about doing lots of documentation.
Using Agile Principles in Workflow Automation Organizations that implement workflow automation solutions typically attempt to automate the entire end-to-end workflow in one big deployment. This