Agile Project Management: The Step by Step Guide that You Must Have to Learn Project Management Correctly from the Beginning to the End

By: Eric Thompson

Narrated by: Jason Belvill

Length: 3 hrs and 7 mins

Publisher's summary

Do you want to learn how to conduct every single step of your project effectively to obtain the best results? Are you tired of guides that teach you inapplicable concepts? Are you looking for an efficient method to complete your project? If the answer is yes, then keep reading.

Organization is required to complete a project successfully, and almost no one knows how to organize everything to complete a project and obtain high results.

When you start a project, there are many phases that they must be conducted in the right way to complete it.

If one phase of the project goes wrong, the whole infrastructure could be compromised (and this is certainly what we don't want to happen).

For this reason, this guide's main goal is to teach you how to conduct the entire process of your project correctly to obtain the results that you want and the satisfaction of your client - through the Agile project management system.

The main goal of the Agile method is to split a hard project into many little pieces to make the entire execution of it much simpler and deliver quality work for the client.

In this guide, you’ll learn:

• What the Agile method is and how it works
• The 10 advantages of the Agile method
• All the steps necessary to carry out a project in the right way
• The main principles of Agile project management
• How to set up the environment, and team composition
• How to apply the Agile method effectively
• And much much more...

This guide is structured in a step-by-step way, and it's composed with practical information to make it possible to apply all instructions concretely.

If you are looking for the right information to allow you to conduct your project with success, this guide is highly recommended.

©2019 Eric Thompson (P)2019 Eric Thompson

Book content and real experience

I used to work in an organisation where mainly waterfall approach was used. We tried to implement an agile approach. It was really difficult with an organisation that had such history. I completely agree with the content how author describe this situation and it is completely true that if there is no willingness to change from top to down, meaning the support is missing by project sponsors, then as much as you want to implement an agile methodology, unfortunately it will be very hard and you may ending to go back to waterfall. So what options are there for a PM or team leader that would like to change the path? Actually not many, either to change the job, or wait till H-L new management arrives which will support the agile PM. So I took the first option and I am now in a company where agile approach is supported. Now from my current experience and what I I heard in the book, I can say that the author have perfectly captured the essentials. Yet I have some observations that I would like to share. One of my concern, and yes it may have the root of waterfall approach, is the requirement description. I am not saying that the author undermine the requirement description but often this my be understood by agile as overhead. Well there is a good reason why the requirements and expectation need to be provided and well described/reviewed. First of all, by poor requirement description team may underestimate or overestimate the complexity and effort. Secondly, although delivery cycle is shorter and we are implementing demos, yet we may face additional rework which is then additional cost. Yet, ask QA team to test and perform the application acceptance testing if the requirement is poorly defined. How many additional meetings you will need to hold with either dev team or reporting party that defined the requirement.. I would like to stress here that agile teams should still make sure that requirements are properly understood by all stakeholders. Next observation that I noticed and was as well mentioned by the author is documentation. True, documentation is something that is another overhead. I am not saying that we should spend time write a new documentation with every small release, but we should have up to date references about the product - well organised library that the team can refer to - project repository - sources, infrastructure, functional specification... Teams and team structure is changing. If we are well organised, we are a self-organized team and we maintain the documentation up to date, we can still be agile. There won't be any frustration for any newcomer to join the team, organisation can involve other teams to help with product development and deliveries. I am mentioning these observations because team members sometimes wrongly exchange agileness for disorganisation and chaos.