Project management discipline is out here used by many people around the world for many years in different ways depending on the body of knowledge of every person — I’m sure that there are a lot of cases when the practice has been the main reason for achieving great results even if the name wasn’t defined. It happened to me most times, like for example applying the SCRUM framework in over 80% of software development projects, but I didn’t know that this framework even exists. But what is Agile Project Management?
There is no role defined in Agile frameworks as Project Management but even so, the practice should happen in projects even if it’s covered by other roles like a Business Analyst or a Product Owner. Still, Agile Project Management is a new approach for an old practice.
In 1969, after WW2, when a lot of large-scale projects emerge, the first institute that standardise the discipline is born and named “The Project Management Institute” (PMI).
Managing any project is a challenging activity. There are many reasons projects could fail - but one of the main reasons is because of the misalignment between the business strategy and the project goals that conduct to building the wrong product or service!
The term ‘Agile’ was first created in the early 2000s when 14 high-tech leaders from around the world gathered to share their ideas and theories of frameworks to help allay business frustration and meet the demands of the rising customer market.
Even if in the Agile Manifesto (you can learn more about Agile here) or in Agile frameworks, the Agile Project Management discipline is not specified but the term still emerged from a higher number of fails rate (for example in the software industry in early 2000 over 64% of projects were failures).
Failure. Failure. Failure... in people's mindsets. Agile project management changed from the ground up to how we approach projects or products. A new paradigm (Waterfall vs. Agile)
Which photo do you think it represents, an Agile approach?
To answer this, let's find out more about the Agile approach/mindset:
So, which photo summarises an Agile approach? Please comment below.
Difference between Agile and Traditional development.
Traditional - everything is predictable, and we can build it through extensive plans.
Agile - it offers the tech advantage into the market by giving first high value and by addressing risks from the beginning
Traditional: individual — specialized in a profession.
Agile: self-organizing teams — people are free to gain new skills in the team, and so roles become interchangeable
And the winner is...
A customer is a company with an understanding of both the business needs and the operational constraints for a project which provides guidance during product or service development.
A story is reflecting a problem. It helps all the team members to have a good understanding of what the product or service is doing. This is a vast topic with more information here.
An iteration is a single development cycle, usually measured throughout a week or two. The length of the iteration depending on the project types (for example, there is a difference between a hardware and a software project) and the experience of team members.
A daily progress meeting (literally every stand-up and meet to keep engaged, motivated and accountable only to team members).
We must accomplish a quantity of defined work in a finite period.
It confirms that a story is complete by matching a user action scenario with the desired outcome. Acceptance testing is part of a story, but it is optional.
The application domain is responsible for creating a shared language between business and IT. Both “teams” are having a shared common understanding.
Used to track the progress of an agile development project. After the Sprint Iteration Planning ceremony, we write stories on cards and pinned up in priority order on a planning board.
A planning game is a meeting attended by both tech and business teams that have a clear focus on choosing stories for a new iteration.
It is a great practice to end every iteration with a potentially shippable product.
An evolving flowchart (that could transform depending on the business' competitive advantage) that describes which features the team will deliver in the upcoming releases.
An iteration can have along with different debts, technical or at a business level which we cannot estimate it. We address a lack of estimation with a time-boxed investigation to understand what we need to address with the new requirements.
How many stories a team can deliver in iterations based on empirical measurements.
Some (final) thoughts
This article is part of a bigger topic called: