Videos on Scrum and Agile Project Management
Many organisations operate in highly regulated environments, such as healthcare, have concluded that in order to achieve the next level of product quality and safety improvements, not to mention enhanced competitiveness, adoption of a more Agile approach is required. In this presentation, you will learn how the Agile software development approach for high assurance systems addresses many of the challenges found in many highly regulated enterprise environments.
In Agile and Scrum, we spend a lot of time talking about how to better manage software development teams using processes, methods, prescriptions and other rules of thumb. We spend very little time talking about the largest and most important ingredient of any agile team: the team and people themselves
Just imagine that you come to a different country and get a team of consultants with whom you need to do their first Scrum implementation project. On top of that, you are not managing the communication with the client, as you are only a sub-contractor. Not enough? You don’t speak official project language, which makes communication with the client VERY difficult. Want to know how it goes so far?
The Mikado Method is a simple straight forward methodology for large scale refactoring. We’ve all been there; tasked with a change, which as optimistic developers we say won’t take us long, weeks later we’re still fighting the system. Enter the Mikado Method, a way to peel the layers of complexity away from any system. Systematically attack refactoring, in the knowledge that every change you make will be for the better of the system, rather than hoping it will be.
Runners find that they can go faster with a lower perceived effort when they exercise in a pack. The same thing happens when our software teams gel, and when our management teams decide to work together for mutual benefit. We are, by nature, social beings—but culture teaches us to hold back and avoid deep connection.
How do agile projects accurately forecast their budget when they are typically just a bunch of hippies coding without requirements or documentation? Waterfall projects are obviously much better at budgeting with all of the traditional up front design and planning, right? Anyone who has been on a waterfall project can see that this is a complete fallacy.
It would be so easy if everyone at our companies just used Scrum or at least Agile. No one would lean on the team for dates and deadlines, and everyone would know that change is a good thing. It’d be one great big happy project management family. But let’s face it: an all-Agile organization isn’t always possible.
