Agile Fundamentals Online Learning
The course is part of these learning paths
This course takes a look at how you can work in an agile way. It will help you to understand what value is, how to measure progress and what Kanban is, and what a project is. You will also learn more about iterative development, how to estimate, and reflect on your own agile journey.
The objectives of this course are to provide you with and understanding of:
- What value is
- How to measure progress
- What Kanban is
- What agile pm/ DSDM is
- How to delivery in an iterative way
- How to estimate
- Growth through mastery
This course is suitable for anyone with no prior knowledge of agile who is considering, evaluating or involved in a move towards working in (or with) an agile environment.
There are no prerequisites for this course, however, participants should be familiar with the content and rationale in the agile manifesto (http://agilemanifesto.org/ )
We welcome all feedback and suggestions - please contact us at email@example.com if you are unsure about where to start or if would like help getting started.
Hi, everyone. In this video, we'll discuss the AgilePM DSDM approach to project management to help you get an overview of what it is and when it's useful. The first thing you need to know about AgilePM DSDM is that it is really all about project management and not just product delivery. This means it takes into account the higher-level strategic thinking organizations need to do to make sure that the products and services they're delivering are in line with the more general goals of the organization, as well as a way to deliver them.
The second thing you need to remember is that projects are temporary, unique endeavors with specific outcomes and outputs with a clear start and end date. Because this is a project management framework, it's only concerned with the exact life-cycle of projects. Simply put, AgilePM DSDM is all about setting up and working through a project life-cycle.
The Agile PM DSDM life-cycle kicks off with the pre-project phase. This normally happens as a simple meeting between the business sponsor and the business visionary where they discuss the idea for the project and see if they feel it links in well with the general ethos and portfolio of the organization. If they feel it does, they will push the project into the next phase, the feasibility stage.
The feasibility stage should last no more than a few days and a few more people are pulled into the project. These generally include a project manager, a business analyst, and a technical coordinator, and they will work with the original business sponsor and the business visionary to create a bunch of management products. Obviously, this is still early days so the project will still be pretty high level. The first thing they will look to create is a product requirements list, which should have less than ten items in it, which should always be outcome- and not output-based. In other words, they should focus on what the product or service must do, not exactly how they should be achieved.
The outcomes in the product requirements list also need to have acceptance criteria included, as these can then be used to create a business case. The business case is an important output of the feasibility stage because it outlines the vision for the project and it will create value for the organization. Once the team have created a business case, they can also start to think about a delivery plan for the next phase. At this point, the delivery plan will probably be pretty high level and more of a guestimation. This should also include a rough estimation of the time and cost of doing the project.
There are a couple of other things that should come out of the feasibility stage. You'll need to create a solution architecture definition (SAD), which basically just tells us what the solution is we are working towards and includes both the technical and the business levels of the solution. You'll also need to create a development approach definition (DAD), which just makes sure that everyone in the team understands what best practice looks like, any standards for everyone to adhere to, testing, and strategy. Last up, we need to create a management approach definition (MAD), which just makes sure we know who our stakeholders are and what everyone's roles and responsibilities are.
That's it for the feasibility phase of this process. I appreciate there was quite a bit to take in there, so to recap, during this phase, we'll expand the project team, set out the basic project requirements list, create a business case and delivery plan, and also, make sure that we have the solution architecture, development approach, and management approach definitions all in place. With this all done, there will be a go or no-go decision, and if the business visionary and business sponsor think the project is viable, they will go ahead into the next phase: the foundation stage.
The first thing we need to do during the foundation stage is to create a solution development team. In it, we will need a business analyst, solution developer, solution tester, a team leader, and the business ambassador. Now, with the expanded team on board, we'll be able to update the business case to really make sure it's as detailed as possible. We also need to update our project requirements list. It should be no more than 100 items at this stage but that is still ten times larger than the original project requirements list, so again, more detail really. We can use our normal MoSCoW prioritizing here to make sure that each item is understood in terms of must have, should have, could have, and won't haves, and, of course, they need to be estimated for effort to create, and we recommend using story points for that.
Just like the other management products, we will need to update our SAD, DAD, MAD, and delivery plan to make sure they have as much detail as they need during this stage, as we will be using this stage to launch into full development. The development plan should be broken up into increments with deployment at the end of each.
Once we've updated everything, we'll be ready to move out of the foundation stage and into the evolutionary development. This is the stage where we will work through our predefined increments and deliver the project. In simple language, this is the stage where we will be creating the work in the project requirements list.
At the end of each increment, we'll release whatever is done through the deployment stage. This is important so that we can get training, testing and end-to-end testing done and just get it live. Once we've completed deployment, we will move back into evolutionary development and work until we get through that increment and back into deployment. At the end of this process and all the work is done, the team will disband and the project will be over.
Normally at this time, the business sponsor and visionary will go into the post-project process to capture lessons learned, etc. One final thing to think about here is why you would use this project management framework. Well, a great reason is that it maps really well against the cone of uncertainty. The cone is always a reality regardless of how you decide to approach a project, but this project management framework takes it into account so that we don't have any weird surprises about what we are doing when we get to the end.
At the start of the project, we understand that we're pretty far away from understanding exactly what we need to make, so we keep it deliberately vague. As we move through feasibility, then into foundation, and finally into evolutionary development, we get closer and closer to being able to see exactly what the final outcomes and outputs of the project will be.
So that's it for this video. I hope we've managed to demystify AgilePM DSDM for you a little. Basically, it's a process to manage projects. There are a few stages which map really well against the cone of uncertainty. There are also a few management products we will need to create and update as the project goes on to make sure that we can use this project management process to successfully deliver our project.
About the Author
Tony has over 20 years’ experience in Business Development, Business Change, Consulting and Project/Programme Management working with public, private and third sector organisations.
He has helped organisations to design and create process and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider utilising a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.
As a confident and self-motivated professional with excellent communication skills Tony is able to bring people together and get them working as a team quickly.
Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Programme and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers and worked at Director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.