Agile-Project-Management-Agile-Scrum

Agile Project Management for Non-Agile Professionals

 Part 1: 12 Agile Principles or Agile Philosophy

Has your boss just told you that you’re going to go through Agile Project Management certification or has a professional suggested that your company should adopt Agile principles? No matter how you’ve come across it, hints of change management and the term ‘Agile’ can initially incite fear and uncertainty in any worker and organization.

But never fear, we’ve compiled a ‘cheat sheet’ for beginners with Agile or a short overview of what you can expect when you’re being put through the Agile filter—so you can come out with a new system and renewed vigor for your company or organization.

According to Agile Project Management for Dummies, here are the 12 Agile principles that every person on the project must keep in mind—even more than the developers!

    1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    4. Business people and developers must work together daily throughout the project.
    5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    7. Working software is the primary measure of progress.
    8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    9. Continuous attention to technical excellence and good design enhances agility.
    10. Simplicity — the art of maximizing the amount of work not done — is essential.
    11. The best architectures, requirements, and designs emerge from self-organizing teams.
    12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Part 2: 7 Agile Stages

So now you know the basic principles of Agile Project Management philosophy. But how are the project managers going to get it done? What can you expect? Here’s a short overview of the stages of Agile and how it’s implemented across different cases:

  • In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is, how it will support your company or organization’s strategy, and who will use the product.
  • In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements.
  • In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first.
  • In Stage 4, the product owner, the master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration.
  • In Stage 5, during each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have.
  • In Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product created during the sprint to the product stakeholders.
  • In Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint went and plans for improvements in the next sprint.

Here is a short overview of what I just told you:

Agile-Project-Management-PM-Belgium-Bruxelles

 

Is everything still alright? Is it clear? Yes of course! Now check out part 2 of this article to see what role you can take in an Agile project and what are the important artefacts and documents that you and your team should always be looking at.

Part 3: Team Roles

In the two first part of this article, we dealt with the 12 principles of Agile and how it can be implemented in 7 stages. Essentially, Agile Project Management is a highly-responsive, intense and high-level approach that’s most useful with product, software and systems development.

With constant sprints and deadlines that always have a working prototype on hand to present instead of boring documentation, Agile has become the benchmark for all successful project teams.

In this part, we deal with the focal persons in a project team and what role you can take up when the project is launched. Keep in mind that each role must be filled by someone, aside from the actual developers, according to Agile for Dummies:

  •  Development team. The group of people who do the work of creating a product. Programmers, testers, designers, writers, and anyone else who has a hands-on role in product development is a member of the development team.
  • Product owner. The person responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert of the product and the customer’s needs and priorities. The product owner works with the development team daily to help clarify requirements. The product owner is sometimes called a customer representative.
  • Scrum master. The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator.
  • Stakeholders. Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project’s outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies.
  • Agile mentor. Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level.

Each of these roles must be filled at all times—if someone is unavailable, someone else must take on these roles lightning-fast.

Part 3: Artifacts

Since Agile is so responsive and intense, with everyone scrambling through a sprint to meet a deadline or add new features for the next Scrum, some documents and artifacts must be visible and in place at all times for each member of the team to keep track of progress and eyes on the prize:

  • Product vision statement. An elevator pitch, or a quick summary, to communicate how your product supports the company’s or organization’s strategies. The vision statement must articulate the goals for the product.
  • Product backlog. The full list of what is in the scope for your project, ordered by priority. Once you have your first requirement, you have a product backlog. You can look at your backlog as what you’ve achieved so far while your working prototype is the combination of all these backlogs.
  • Product roadmap. The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. Think of this as the timeline for the project with included achievements.
  • Release plan. A high-level timetable for the release of working software. This is what your prototype should have at given times. A release plan helps you determine your priorities.
  • Sprint backlog. The goal, user stories, and tasks associated with the current sprint. Stories are important in Agile so that improvements can be made to the project at all times based on what’s happened before. Lessons here are learned quickly and applied immediately to avoid mistakes.
  • Increment. The working product functionality at the end of each sprint. This shows how different the working product is from one sprint to the next.

What-is-agile-software-development-Agile-Scrum-Belgium

There you have it, a short overview of Agile Project Management principles and how sprints work within the context of roles and artefacts that people value in a project. If you want to continue to develop your Agile knowledge we invite you to read our other articles. You can also join us in one of our trainings.

I you like this article please share it. Thank you for your time and attention.

 

Discover our trainings in :

English:

Français

 

Please follow and like us: