This Festive Season, enjoy 10% discount on all courses Use Coupon NY10 Click to Copy

Search

Establishing The Agile PMO

Long back, I posted an article on LinkedIn titled, Lessons Learned in Establishing a Project Management Office (PMO.) It centred around the discussion of plan-driven projects, typically manifested by the waterfall methodology.I subsequently spoke on this topic at a Project Management Institute (PMI®) chapter meeting and was asked to incorporate some thoughts on how the PMO might support adaptive or Agile methodologies. Having now helped establish several PMO’s, I’d like to share a few thoughts on this.Firstly, Agile is different philosophically in many ways than waterfall. One of the main tenets of the Agile Manifesto is "Working Software Over Comprehensive Documentation." This does not mean NO documentation; it just means that working software is valued more.Conversely, the plan-driven project typically relies heavily on documentation. And therefore, the waterfall-based PMO reflects this by having any number of templates, forms, and archived notes. So, for example, the well-stocked plan-driven PMO has templates for charters, risk registers, project management plans, etc.But in Agile, let's say specifically in the Scrum variant, the team requires artifacts such as product backlogs (essentially all the requirements), sprint backlogs (what activities you will perform during a sprint), and release plans (how many sprints you will need to perform). Often – outside of reporting – Agile teams don’t use much more than that.In the PMO’s in which I have been involved, we created these templates and put them in the repository, but, depending on the type of PMO it was, teams were free to use them or not as they decided.If teams in Agile are, by definition, self-organizing, what else besides templates might a PMO provide? Well, the best practices organizations will be able to provide Agile coaches to kick-start a project. As one Agile coach advised me, this helps create a mindset in the team right from the start. And of course, the PMO can then provide ongoing mentoring and training.This same coach advised that not all projects should be Agile. If a product that the team is creating is well-understood or the culture of that division does not support the Agile philosophy, the PMO can advise as to whether a project should be Agile. It should not impose its philosophy on every project.You might argue that the “world is going Agile.” In a very real sense, yes, it is. But there are any number of projects that have lent themselves for years to the waterfall methodology and continue to do so. A colleague of mine works for a telecommunications company and they are always rolling out new networks. This is such a well-understood technique that classic waterfall works quite well for them.One area in which the Agile PMO can assist is in gathering metrics. Since Agile is all about delivering value, how well teams deliver that value might be of interest. You can track and measure such things as a team's velocity, burn-up or burn-down rate.Since the Agile PMO has visibility across the organization, it has the unique ability to coordinate resources and best practices among teams. In a sense, it is an overseer of quality and resource management. Some organizations employ the concept of Scrum of Scrums, wherein Scrum Masters who are "ambassadors" from other teams regularly convene. The PMO could facilitate this get-together to share ideas, especially if teams are siloed.And while it is by no means known as an exemplar of agility, PMI recently published an Agile Practice Guide1. They noted three things about the Agile PMO that I agree are worthy of note:An Agile PMO is value-driven. It provides the right value at the right time, not imposing on its customers but working with them in a consultative fashion.An Agile PMO is invitation-oriented. A corollary of the first precept, the PMO is available to all in the organization but especially invites in those who find the concept and its services of value. Their interest makes them much more likely to engage.An Agile PMO is multidisciplinary. Not all PMOs are created equal. The more successful ones are centers of excellence and provide not only project management-related expertise but also advice in disciplines such as change management.Key point - if you're introducing Agile into a more traditional organization, try to do it in such a way that management is comfortable with the tools you're using. In one company that I consulted to, we made sure to use recognizable formats and templates wherever possible. People ask for change but nobody really likes it very much.These are just a few of the ideas that we (it's a team endeavor to set up a PMO), considered. In the instances where I've done this work, I've kept a copy of the Agile Manifesto handy. The takeaway here is to make sure that the Agile PMO is ....Agile!1. Agile Practice Guide, p. 81. ©2017, Project Management Institute, Inc.© Jim Stewart, PMP, CSM 2018
Rated 4.0/5 based on 59 customer reviews

Establishing The Agile PMO

421
  • by Jim Stewart
  • 29th May, 2018
  • Last updated on 21st Jan, 2019
  • 3 mins read
Establishing The Agile PMO

Long back, I posted an article on LinkedIn titled, Lessons Learned in Establishing a Project Management Office (PMO.) It centred around the discussion of plan-driven projects, typically manifested by the waterfall methodology.

I subsequently spoke on this topic at a Project Management Institute (PMI®) chapter meeting and was asked to incorporate some thoughts on how the PMO might support adaptive or Agile methodologies. Having now helped establish several PMO’s, I’d like to share a few thoughts on this.

Firstly, Agile is different philosophically in many ways than waterfall. One of the main tenets of the Agile Manifesto is "Working Software Over Comprehensive Documentation." This does not mean NO documentation; it just means that working software is valued more.

Conversely, the plan-driven project typically relies heavily on documentation. And therefore, the waterfall-based PMO reflects this by having any number of templates, forms, and archived notes. So, for example, the well-stocked plan-driven PMO has templates for charters, risk registers, project management plans, etc.

But in Agile, let's say specifically in the Scrum variant, the team requires artifacts such as product backlogs (essentially all the requirements), sprint backlogs (what activities you will perform during a sprint), and release plans (how many sprints you will need to perform). Often – outside of reporting – Agile teams don’t use much more than that.

In the PMO’s in which I have been involved, we created these templates and put them in the repository, but, depending on the type of PMO it was, teams were free to use them or not as they decided.

If teams in Agile are, by definition, self-organizing, what else besides templates might a PMO provide? Well, the best practices organizations will be able to provide Agile coaches to kick-start a project. As one Agile coach advised me, this helps create a mindset in the team right from the start. And of course, the PMO can then provide ongoing mentoring and training.

This same coach advised that not all projects should be Agile. If a product that the team is creating is well-understood or the culture of that division does not support the Agile philosophy, the PMO can advise as to whether a project should be Agile. It should not impose its philosophy on every project.

You might argue that the “world is going Agile.” In a very real sense, yes, it is. But there are any number of projects that have lent themselves for years to the waterfall methodology and continue to do so. A colleague of mine works for a telecommunications company and they are always rolling out new networks. This is such a well-understood technique that classic waterfall works quite well for them.

One area in which the Agile PMO can assist is in gathering metrics. Since Agile is all about delivering value, how well teams deliver that value might be of interest. You can track and measure such things as a team's velocity, burn-up or burn-down rate.

Since the Agile PMO has visibility across the organization, it has the unique ability to coordinate resources and best practices among teams. In a sense, it is an overseer of quality and resource management. Some organizations employ the concept of Scrum of Scrums, wherein Scrum Masters who are "ambassadors" from other teams regularly convene. The PMO could facilitate this get-together to share ideas, especially if teams are siloed.

And while it is by no means known as an exemplar of agility, PMI recently published an Agile Practice Guide1. They noted three things about the Agile PMO that I agree are worthy of note:

  1. An Agile PMO is value-driven. It provides the right value at the right time, not imposing on its customers but working with them in a consultative fashion.
  2. An Agile PMO is invitation-oriented. A corollary of the first precept, the PMO is available to all in the organization but especially invites in those who find the concept and its services of value. Their interest makes them much more likely to engage.
  3. An Agile PMO is multidisciplinary. Not all PMOs are created equal. The more successful ones are centers of excellence and provide not only project management-related expertise but also advice in disciplines such as change management.

Agile PMO things

Key point - if you're introducing Agile into a more traditional organization, try to do it in such a way that management is comfortable with the tools you're using. In one company that I consulted to, we made sure to use recognizable formats and templates wherever possible. People ask for change but nobody really likes it very much.

These are just a few of the ideas that we (it's a team endeavor to set up a PMO), considered. In the instances where I've done this work, I've kept a copy of the Agile Manifesto handy. The takeaway here is to make sure that the Agile PMO is ....

Agile!
1. Agile Practice Guide, p. 81. ©2017, Project Management Institute, Inc.
© Jim Stewart, PMP, CSM 2018

Jim

Jim Stewart

Blog author

Since 2003, as a principal of JP Stewart Associates, Jim has been engaged in multiple endeavors including consulting, training and mentoring. A PMP since 2001 and Certified Scrum Master since 2013, he provides PMP Prep training both in public and private in-house sessions. In consulting, he frequently contributes by helping organizations increase their project maturity. He recently consulted to a financial services firm to help them set up a project management office. Jim is on the PM advisory board of MindEdge, Inc. and is co-author of the upcoming book, “Facilitating Project Planning Meetings: A Practical Guide to Ensuring Project Success.”

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Agile Project Management Vs. Traditional Project Management

In this fast-moving world, project management has become one of the most important pillars that are helping businesses run without any glitch in their processes. Both small and large scale organizations around the world are exploiting technology and depending on project management systems to deliver the software development project successfully. Whether it is team workflow management or timing, these tools help to ensure that everything is going well without any obstacles. While there are tens of different project management approaches, Agile is considered one of the most practical and flexible software development mechanism that exist today. It is capable of executing a variety of tasks, but what sets it apart from others? Let’s find it out. Here’s a brief comparison of Agile management and traditional project management software:                                                                                                                    Traditional vs Agile Project Management Overview of Agile and Traditional Project Management What is Traditional Project Management? The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in sequence. Its concept depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure above. The entire project is planned upfront without any scope for changing requirements. This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues. What is Agile Project Management? When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility. It is an iterative approach that focuses more on incorporating customer feedback and continuous releases with every iteration of software development project. The basic concept behind Agile software development is that it delves into evolving changes and collaborative effort to bring out results rather than a predefined process. Adaptive planning is perhaps the biggest feature of Agile and one that makes it a crowd favorite among project managers. Scrum and Kanban are two of the most widely used Agile frameworks. They are very well known for encouraging decision-making and preventing time consumption on variables that are bound to change. It stresses customer satisfaction and uses available teams to fast-track software development at every stage. The table below shows the major differences between Agile project management and traditional project management.                                                                                Table: Agile project management vs traditional project management Why is Agile Preferred and why not the traditional project management? Agile is preferred by most developers and managers because of a variety of reasons. Let’s have a look at the most common ones: Project complexity Traditional: This method is the best fit for small or less complex projects as it follows linear approach. Sudden changes in the project or any other complexities can block the entire process and make the team go back to step one and start all over again. Agile: This is the best methodology to follow in case of complex projects. A complex project may have various interconnected phases and each stage may be dependent on many others rather than a single one as in simple projects. So, Agile methods are preferred for large complex projects, as they can respond better to such structures. Adaptability Traditional: This approach works with a belief that once a phase is done, it will not be reviewed again. So, it is not adaptable to rapid changes in the work plan. In case if any sudden situation arises or any change in the requirements from the client’s side, traditional approach fails to adapt to the new change. The only choice is to start from the very beginning once again. This wastes a lot of effort and time in the process. Agile: The adaptability factor is very high in this methodology since it is not linear. Complex projects consist of several interconnected stages, where a change in one stage can cause an effect on another. And the project managers can take calculated risks in such scenario, as there is a chance of high adaptability.  Scope for feedback and changes Traditional Each and every process is clearly detailed and defined at the start of the project in the traditional approach. It cannot deal with any big change or feedback that might require a change in the process. Mostly, the project delivery time and budget are fixed, allows change very rarely. Agile There is a high acceptance for feedback and change in this method. The process is very flexible and allows constant feedback that can help to provide better output within the fixed project delivery time. The main reason that managers or developers choose agile direction is for the flexibility it offers. Developers working with Agile management are able to respond to customer requests quickly as they are only addressing small parts of the project at a time and the customer validates each iteration or sprint before finalizing.   Some of the important characteristics of Agile development Breaks project into parts Agile divides a project into parts (called iterations) where the release is sent to the customer after every single iteration. Additionally, the success of the project can be easily foreseen through the success of these iterations. This removes the need for upfront planning completely. Self-organized As mentioned above, Agile uses a parallel mode of management. Employees of a company are not managed by a central line of control, but by groups. For example, in Agile, there may be eight teams working on a single project. Each team is managed by itself without external guidance. The teams only interact with each other for project discussion and process linking as they are otherwise not self-sufficient. Generally speaking, an Agile project consists of three parts: The product owner – the expert on the project (for which the product is being developed) and is the main person who oversees the projects The scrum master – this person manages the process involved in Agile. He/she looks after the iterations and its completion The team – individuals who play significant and minor roles in the software development process Customer Engagement In Agile, customer engagement is at the very top. The customer is regarded highly in its frameworks as after every iteration, feedback is generated and acted upon. Overall, Agile is clearly the winner among project management systems. When compared with other traditional approaches, Agile’s features come to the fore and reiterate why it is one of the top software used by companies globally. Can Agile Coexist with Other Approaches? This is a question asked by many project managers, and opinions of experts seem to be divided. While some say it is possible for Agile to coexist with traditional project management systems, they suggest being cautious and using them for different terms. For example, using two different approaches on the same project can be counter-productive and highly explosive. As Agile and most other frameworks are totally contrasting to each other, the projects may go for a toss. On the other hand, some experts believe that it is not possible for Agile and other tools to co-exist because of their contrast. Using them together can cause disorder in the entire company system, making the productivity to go for a toss. Agile vs Traditional- Adoption Growth According to a recent online survey of 601 IT and development professionals, it is proved that Agile is the new typical formula for project success. The majority of projects and development teams are now adopting this methodology, while the traditional waterfall approaches have many flaws.    Traditional organizations vs. #Agile organizations #SALC16 pic.twitter.com/bBgxkQB1fI — Scrum Alliance (@ScrumAlliance) January 20, 2016 Agile was first introduced about 15 years ago as a substitute for traditional software development approaches. Many people considered it as challenging to implement traditional approach practices and Agile adopters stated that this new style of software development improves team collaboration and is more customer-centric.  Though Agile method was present more than a decade ago, the vast majority of organizations have adopted the practice in the last 5 years. Moreover, the survey reported that agile adoption saw an inflection point between the year 2009-2010. As shown in the above figure, agile adoption seems to have slow incremental growth till 2008 and then its growth was accelerated after gaining traction in the market. Reasons for the transition to Agile Most of the organizations who transitioned from traditional to agile project management have listed the following reasons: Improves collaboration between teams- 54% Enhances the quality level of software in organizations- 52% Results in enhanced customer satisfaction- 49% Speeds time to market- 43% Reduces development cost- 42% The Verdict In the traditional software development, the customer involves only before the start of the development process. So, there might be a number of mistakes and a large amount of money needs to be spent to rework on them. Since in the Agile software development, the customer involves at each stage, the corrections can be made once the defects are detected. This helps us in saving cost. As we can see, Agile project management is really in-demand for teams. It helps the team to work on the top priority ones at the right time and allows them to walk through the risks much faster than they would with traditional project management tools.  
Rated 4.0/5 based on 2 customer reviews
8128
Agile Project Management Vs. Traditional Project M...

In this fast-moving world, project management has ... Read More

Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Product Backlog Grooming, is a method for keeping the backlog updated, clean and orderly. It is a basic process in Scrum. PBR is a collaborative discussion process which starts at the end of one sprint to confirm whether the backlog is ready for the next sprint. Backlog can be defined as a set of user stories which are not present in the current sprint that defines project’s scope context. The stories which are left unattended, may interfere with the functioning of the development team.When this happens, the status of user stories will not be clear, and even the team can lose focus and fail to deliver within the project completion date. The backlog grooming meeting is attended by the scrum master, who facilitates everything for team members, the team and the product owner. They decide among the top items from the product backlog. The team comprises mainly of Developers, testers and Scrum Masters. The team can raise queries during the sprint planning session if they find any unresolved issue. The expected doubts can arise in the following forms : How to handle the situation if the user enters invalid data? Which part of the system are the users authorized to operate on? For the product owner, it will be easy to get the conclusion over the queries, by asking these questions in the early stages. If there is a question which is unanswered by too many people, it is time to make some changes in your backlog items by curating higher priority items to the top of the list and assigning highest priority to the unanswered questions. The Objective of PBR meeting: A lot of time is saved at sprint planning meetings, if the backlogs are well maintained. If the backlog item is clearly specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding stories. Why is PBR important?  PBR and its sessions are important mainly due to the following features- It increases the efficiency of the team by reducing uncertainty Properly refined stories are easy to estimate, test and implement. PBR session increases the efficiency of the team due to the knowledge shared among the team members. If PBR meeting is maintained properly, it helps reduce the time for a Sprint planning meeting. The Product Backlog grooming can be made effective if the following aspects are considered- Do not schedule backlog refinement meeting during the first and last 20% of the Sprint Planning session. Backlog refinement meeting should be considered as the first part of Sprint Planning. The backlog items’ list should be well understood by the PO, or development team member to work well in the meeting. Make sure that the set of predefined acceptance tests are present. Keep an eye on the meeting goals. Make sure to assign action items for any unknown thing. Do remember that the backlog items are a collaboration between the PO and the team. Feel free to break the product backlog items during the meeting. After the product backlog refinement meeting, the team can update the Product Backlog items in line, based on the discussions held. Finally, you can get a potentially shippable product, ready to be deployed in the market.
Rated 4.0/5 based on 20 customer reviews
2249
Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Pr... Read More

Agile Scrum Roles And Responsibilities

Agile, Scrum, Waterfall, Kanban are different project management frameworks which are helping the companies to increase the productivity. These frameworks were created by the IT companies and especially web and application development companies because they needed a path but on which each and every employee can perform his daily tasks. However, out of these four frameworks, the Scrum is the most widely used framework in all the companies despite their nature of work. That is why in this article we are going to discuss the Scrum in detail to give you a better idea about this iterative framework which is making easier for the companies to complete their project. Scrum Objective: The basic objective of the Scrum is to keep the entire team on the same page throughout the project. The scrum framework allows the cross-functional work of the team of 4 to 10 members to provide the regular details and information sharing liberty so they can produce the best result. Scrum is a more like philosophical than the technical. It is a framework that can only be used as the guidance and there is no constant in it. All the success of the Scrum depends on the interactions among the stakeholders as it does the process. Scrum roles and responsibilities: The techniques of Scrum has become very popular and now considered to be the most important thing to do before starting any project. That is why the demand of the scrum masters and other professions related to the scrum has also increased, and people now are searching about the term scrum more. The scrum is a very specific and précised framework that is why it comprised on the following roles. Scrum Master Product Owner Scrum Team Stakeholders   Because the term Agile is often get associated with the project managers that is why many people believe that the Scrum Master is also a term for the project managers. However, the Scrum Master serves very different purposes than the project manager. The Scrum Master works as a facilitator rather than the authoritative person who is responsible for the project delivery. The Scrum Master is a coach, motivator and problem solver who can only assist the team by using all his experience of Scrum framework. According to many Scrum Masters, applying Scrum within an organization is not the actual scrum process. You have to make the organization to accept your new role and then change its culture which is the most difficult thing to do in any company. The prominent role of every Scrum Master should be to enhance the power of the team by committing them to the sprint goals without any interference from the management. Let’s discuss the major roles of all the above points separately. Scrum Master: The Scrum Master is considered to be the top-dog in every organization because companies usually hire them and don’t treat them as permanent employ that is why they are with no authority. It is their duty to remove all the hindrance or obstruction in the way of achieving any goal. It is also their role to enforce scrum ceremonies and processes. They are the ones who commit to goals and deadlines on behalf of the team. Product Owner: The product owner is responsible for conveying the vision of the stakeholders to the team. They have the authority to alter the scope. The Product Owners are responsible for the return on investment (ROI) that is why they occupy an authoritative position in the firm. Because they convey the vision of the stakeholders that is why they are the voice of the stakeholders. Not only with the team, but they also communicate with the stakeholders about progress and problems. Scrum Team: The Scrum Team is responsible for all the activities that lead them towards their sprint goals. They have to work with the Scrum Master to prioritize the items from the product backlog in the sprint planning. Once committed, it is their responsibility to fulfil the commitment and deliver the agreed results on time with great quality. The Scrum Master is not responsible for keeping his team organized that is they it is the duty of the Scrum Team to get self-organized. They have to be agile in the office and have to attend every standup and other ceremonies. They have to participate in all the meetings despite their nature and have to ensure that all the findings of the meetings are getting practically addressed in the project. Stakeholders: The Stakeholder has to keep a healthy relationship with the Product Owner in order to share every detail regarding his project. The Stakeholder is responsible for conveying his wishes and concerns to the product owner or else the product owner would not be responsible for his project quality and time duration. The Stakeholder has to provide regular input to queries from the Product Owner. Prioritizing the work affectively with the Product Owner is another job that the Stakeholder has to do to ensure his project development. Keep taking updates or keep giving updates regarding any change in the plans.
Rated 4.0/5 based on 1 customer reviews
9418
Agile Scrum Roles And Responsibilities

Agile, Scrum, Waterfall, Kanban are different proj... Read More

other Blogs