Videos on Scrum and Agile Project Management
In 2001 a group of programmers proposed the word “agile” to describe a set of values they shared. Several of these programmers had already developed methods based on these values. The values are universal, that’s how they were chosen. The methodologies, however, were designed for the technology landscape of the 1990s. Think of all the changes in technology and business practise in the last 25 years. If that seems too daunting just think about the last five years. In taking “Agile” mainstream, we adopt these ancient practises on faith while losing sight of the values that inspired them.
As Agile matures and learns from experience, it is clear that the Agile business analyst has a significant role to play. This interactive and musical session will explore the relationship between Product Owner and Business Analyst, their responsibilities and the skills needed. I’m an Alien … I’m a Business Analyst in an Agile world!”
Making decisions in groups like Scrum teams is our daily bread. Together we ponder over the right architecture, we select tools and set rules that we should follow as a software development team. In case of errors we discuss and decide how to get rid of them once and for all. We discuss, exchange point of views, bring arguments… or even yell at each other.
Agile is a now mainstream method used in IT project management. Yes, Agile and Scrum are now considered as a method and no longer as a philosophy. Everyone wants to “do” Agile and thus want to “be” Agile as well, but what are the common mistakes in applying Agile?
There’s a debate raging in the Agile world around the #NoEstimate concept: should we estimate, or not? Lost in the noise are more important questions: When should we estimate, and why? When should we not estimate, and why not?
How much does one story point cost? Is Sprint 0 an expense or an asset? Can you run Scrum with a fixed-cost contract? Agile challenges the existing approach to financial aspects of running projects, that is budgeting, forecasting, financial planning and vendor contracts.
One might wonder why it’s not so easy to adopt agile engineering practices and to achieve technical excellence. When we think of practices, we tend to think of simple things: sticking a shopping list on the fridge with a magnet, having a clear and prioritized list of things to do, and doing them in that order. Why is it then that with Agile practices, things don’t work out quite so well?
