Agile Project Manager Job Description

I was recently asked by a company I am working with to create a job description for an “Agile Project Manager”. Here’s what I came up with (I searched all over the web and combined what I thought were the best job descriptions for Agile Project Managers with my own experience):

Introduction
The Agile Project Manager (APM) is responsible for planning, leading, organizing, and motivating agile project teams to achieve a high level of performance and quality in delivering agile projects that provide exceptional business value to our users. The APM will be responsible for managing several concurrent high visibility projects, using agile methods, in a fast-paced environment that may cross multiple business divisions. In performing that role, the APM will be expected to use a high level of knowledge and experience in blending traditional project management principles and practices with an Agile development approach in the right proportions to fit large, complex, mission-critical, enterprise-level projects and planning and provide the right balance of agility and predictability.

Essential Job Requirements:

  • Project Planning and Management – Define project scope and schedule while focusing on regular and timely delivery of value; organize and lead project status and working meetings; prepare and distribute progress reports; manage risks and issues; correct deviations from plans; and perform delivery planning for assigned projects
  • Team Management – Assist in team development while holding teams accountable for their commitments, removing roadblocks to their work; leveraging organizational resources to improve capacity for project work; and mentoring and developing team members
  • Product Owner Support – Support the Product Owner in managing customer expectations for project deliverables, managing stakeholder communications, and helping to implement an effective system of project governance
  • Process Management and Improvement – Define and manage a well-defined project management process and champion ongoing process improvement initiatives to implement best practices for Agile Project Management
  • Team building – promote empowerment of the team, ensure that each team member is fully engaged in the project and making a meaningful contribution, and encourage a sustainable pace with high-levels of quality for the team

Qualifications:

  • Solid understanding of software development life cycle models as well as expert knowledge of both Agile and traditional project management principles and practices and the ability to blend them together in the right proportions to fit a project and business environment
  • A proven track record of successfully implementing software or web development projects using Agile methodologies including 8+ years of experience as a Project Manager managing large, complex projects in a high-tech development environment with multi-function teams. PMP preferred
  • Prior experience with SCRUM/Agile methodologies with enterprise-level application development projects. PMI-ACP, CSM, or equivalent preferred
  • Experience overseeing multi-function project teams with at least 10-15 team members including Developers, Business Analysts, and QA Personnel
  • Balanced business/technical background:
    • Sufficient level of technical background to provide highly-credible leadership to development teams and to be able to accurately and objectively evaluate complex project risks and issues
    • Ability to provide leadership to business analysts and collaborate with customers and develop strategies and solutions of high business value

Skills Required:

  • BA or BS or equivalent experience is required; MA or MS is a plus
  • Strong interpersonal skills including mentoring, coaching, collaborating, and team building
  • Strong analytical, planning, and organizational skills with an ability to manage competing demands
  • Strong knowledge and understanding of business needs with the ability to establish/maintain high level of customer trust and confidence
  • Proven ability to lead software development projects and ensure objectives, goals, and commitments are met
  • Solid understanding of and demonstrated experience in using appropriate tools:
    • Agile Project Management tools such as Jira/Greenhopper, Rally, VersionOne or equivalent
    • Microsoft Project, Visio, and all Office Tools
  • Excellent oral and written communications skills and experience interacting with both business and IT individuals at all levels including the executive level
  • Creative approach to problem-solving with the ability to focus on details while maintaining the “big picture” view

Scrum Master Training Thoughts and Recommendations

This is not a plug for a Scrum Master training course… I was recently asked to provide some training recommendations for a person who was new to the Scrum Master role. This particular individual knew the basic mechanics of how to do Scrum but needed to take the performance of the team to the next level. I want to share my recommendations with you because I think this is a fairly common situation.

  • The biggest problem is that many people don’t understand the full scope of the Scrum Master role. They see it as a passive facilitator role and all you need to know is the mechanics of how to do Scrum. If that’s the way you see it, you can get the standard CSM certificate and call it “done”; I think it is much more than that. (See my recent post on the Scrum Master role):

    https://managedagile.wordpress.com/2013/08/17/scrum-master-role

  • I thought that the standard Certified Scrum Master (CSM) course would be a waste of time and money for this individual unless it is taught by someone really good who goes beyond the basics. Most CSM courses only cover the basic mechanics of Daily Standups, Sprint Reviews, Retrospectives, etc. and that’s a very small fraction of what a good Scrum Master needs to know, in my opinion.
  • However, I did think it would be worthwhile for this individual to take an assessment of Scrum Master knowledge without going through the standard CSM course – an assessment exam is relatively inexpensive ($100) and that exam will help validate that the individual has the basic Scrum Master knowledge or not and will help to highlight any areas of weakness. Here’s a link for registering to take the Professional Scrum Master Self-Assessment:

    http://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments/PSM-I-Assessment

What is needed in many cases is an Advanced Scrum Master training course, but there are very few of those offered. Standard CSM courses are available all over the place, but very few people offer an Advanced Scrum Master course that goes beyond the basics because so many people seem to be content to get the CSM certificate and call it “done”.

A good Scrum Master, in my opinion, is passionate about Agile and doing it with a level of excellence. He/she should be somewhat of an evangelist to help others thoroughly integrate Agile/Scrum values, principles, and practices into the way that they work. That’s what is needed, in my opinion. There are many situations like the one I was in where the company was doing the “mechanics” at a basic level and what’s needed is to go beyond that basic level to really dramatically improve the performance of the team. In that kind of situation, you’ve really got to become somewhat of an Agile “zealot” to do it well and one CSM course is not likely to do that.

It requires a strong commitment to ongoing learning and development to become a really good Scrum Master. Essentially, you need to commit yourself to becoming an “Agile Expert”. There are a lot of regularly scheduled Agile events sponsored by Agile groups throughout the world where people share knowledge of what works and what doesn’t work in the real world. Don’t forget that Agile is based on very empirical knowledge… beyond a certain point, there is no textbook that I’m aware of to tell you exactly what to do.

Another course and certification that I think is worthwhile to consider (but not necessarily the first thing to do) would be to get the PMI-ACP certification. ACP stands for “Agile Certified Practitioner” and is a new PMI certification designed primarily for project managers who work in an Agile environment. I have that certification and I think it is worthwhile. Here’s what I like about it:

  • I think the PMI-ACP exam is more rigorous than the CSM exam and the certification has some more rigorous experience requirements that the CSM certification doesn’t require
  • The PMI-ACP certification takes a broader view of Agile not limited to Scrum and covers other related knowledge areas such as Lean and helps you see the “Big picture” of what Agile is all about; where CSM is really focused on Scrum and the mechanics of how to do Scrum
  • Both have value…you do need to know the mechanics of how to do Scrum, but it’s also worthwhile to see the “big picture” of Agile as well to better understand the principles and practices at a higher level. You will find information on the PMI-ACP certification here:

    http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx

    I think certifications have value if they’re used in the right way. Some people seem to use them to “punch a ticket” and call it done. I see certifications as part of a program of ongoing learning. They can be useful to calibrate what you know and don’t know, particularly if you do a lot of self-study as I do; but getting a particular certification should rarely be an end in itself.

Scrum Master Role

I was asked to put together a clear definition of a Scrum Master role for a company I am working with that is new to Agile. I think the standard “textbook” definition of what a Scrum Master does is limited and needs some interpretation and elaboration. It also needs to be expanded with some best practices for Scrum Masters from a variety of sources (see below). Here is what I came up with:

  1. Team Management – A commonly held view of Scrum Masters is that they are only passive facilitators because the team is supposed to be self-organizing. That may be true in an ideal world, but very few teams are really at that level from my experience and even teams that are at a high-level of proficiency can slip back. In my opinion, Scrum Masters have to use what I call “Adaptive Leadership” – if a Scrum Master is only a passive facilitator, he/she is not doing the job effectively in my opinion. He/she has to provide a sufficient level of leadership to help the team get to a self-organizing level and then sustain it without over-managing the team. “Adaptive leadership means providing just enough leadership to fit the situation and nothing more. Here are some specific components of that role:
    • Team Productivity
      • Ensures that the team is fully functional and productive including having the right tools, training, and process flows to maximize team productivity
      • Coaching the Development Team in self-organization and cross-functionality
      • Helping the Development Team to create high-value products
      • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood
      • Constantly help to improve tools and practices used by the team so that the efficiency is always maintained
    • Remove Impediments
      The Scrum Master should resolve all the impediments so that the team can concentrate on the engineering tasks to be done.
    • Performance Appraisal & Feedback
      The Scrum Master will provide necessary feedback to the team members to help them improve their performance.
    • Resolve Conflicts
      The Scrum Master should be in touch with the team members to sense any conflicts early and resolve them
  2. Process Management – A good Scrum Master, in my opinion, is passionate about Agile and doing it with a level of excellence. He/she should be somewhat of an evangelist to help others thoroughly integrate Agile/Scrum values, principles, and practices into the way that they work.
    • Meeting Facilitator
      Facilitates Daily Scrums and Other Scrum Events to ensure that they are well-organized, time-boxed and productive.
    • Process Master
      The Scrum Master will typically serve as the scrum expert on the team. This means they are responsible for helping the team optimize the use of scrum as the methodology they have chosen to build their software.
      The Scrum Master creates the scrum rules for the project and then coaches the team to follow Agile principles and practices. At the end of the sprint, he needs to ensure that every user story is completed as per the definition of done.
    • Team Interface
      Serves as the primary interface to the team to manage communications with the team and shield the team from disruptive external influences.
    • Planning and Estimation
      Coach the team on estimation practices, lead the team in estimation during the planning meeting, and work with the team to improve estimation and planning process
    • Continuous Improvement
      Leads and facilitates retrospective meetings and champions efforts to improve on the quality, velocity, value to the business
  3. Project Management – The Scrum Master is not really a Project Manager; however, there are some project management skills that are useful in the role. The Product Owner should really own responsibility for the overall success or failure of the project; however, a Scrum Master plays a number of roles in support of the Product Owner in performing the program/project management function.
    • Support the Product Owner
      • Assists the Product Owner with various activities including assisting with backlog as well as project-level and release-level planning
      • Helping to ensure that the items in the backlog are clear and concise
      • Working with the Product Owner to prioritize the items in the backlog
    • Organizational Transformation
      • Leading and coaching the organization in its Scrum adoption;
      • Planning Scrum implementations within the organization;
      • Helping employees and stakeholders understand and enact Scrum and empirical product development;
      • Causing change that increases the productivity of the Scrum Team; and,
      • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
    • Radiate Information
      Radiate information or ensure that a team’s progress and successes are highly visible to all stakeholders, including the team itself.

In addition to my own personal experience, I have used the following sources to compile this list:

  1. Scrum Guide – http://www.scrum.org/scrum-guides/
  2. Scrum Master Roles & Responsibilities by Amit Malik – http://amitsinghmalik.blogspot.com/2013/06/scrum-master-roles-responsibilities.html

Developing an Agile Company Culture

Corporate culture can be a major obstacle to successfully implementing an Agile development approach; however, it doesn’t have to be that difficult. Some people make the mistake of thinking that you have to change the entire culture of a company in order to adopt an Agile development approach. I don’t believe that is either necessary or appropriate in many cases; a company’s culture should be designed around whatever business they are in and that may or may not be well-aligned with implementing an Agile development approach. See my previous blog post on “Agile and Corporate Culture” for more discussion on this:

https://managedagile.wordpress.com/2013/03/30/adapting-an-agile-development-process-to-a-corporate-culture/

Agile works best in companies that are in the business of developing products or where software product development is somehow very directly related to their primary business. In other companies where the relationship is more indirect, it can be much more difficult to implement an Agile development approach because it may not be as well-aligned with the company’s primary business objectives. An example is Walmart…Walmart’s primary business is driven by reducing costs. I’m sure that software development plays some role in that but it is much more indirect than a company like Amazon.com whose business is very directly leveraged by software development. It should be very easy for a company like Amazon.com to implement an Agile development approach and far more difficult for a company like Walmart to do the same thing.

The key point is that since Walmart’s primary business is through conventional brick-and-mortar retail stores, they have to develop a culture that is well-aligned with squeezing costs out of every area of their operations and managing a large number of retail stores very efficiently and effectively. Those are the primary drivers of their business and that may not align very well with an Agile development approach. If you were to set out to implement an Agile development process inside of a company like Walmart, would you try to get them to give up their entire corporate culture and adopt a different corporate culture that is more suitable for hosting an Agile development process? I don’t think so, but there are some fundamental aspects of any company’s culture that can be dysfunctional are most critical to adopting an Agile development approach. Here are a few of what I think are the most important factors:

  • Transparency and Trust – In many large corporations, there is somewhat of a contractual relationship between the business users and the people who deliver Information Technology solutions. The business users may be under intense pressure to reduce costs and want to get firm commitments from the solution providers on the costs and schedules of projects. That is one of the major factors that has can be a big obstacle to implementing an Agile development approach – sometimes it even creates somewhat of an adversarial relationship between the two organizations. The key to getting past that obstacle is:
    1. Companies need to realize that this is not an “all-or-nothing” proposition to totally give up all control of projects to become Agile. There are many ways to blend traditional project management principles and practices with Agile principles and practices to develop the right balance of agility and control. See my blog post on a Hybrid Agile framework here:

      https://managedagile.wordpress.com/2013/07/22/a-hybrid-agile-development-framework/

    2. Developing a spirit of trust, partnership, and collaboration between the two organizations can require some strong executive-level leadership to break down some of the traditional barriers that exist inside of companies. The strongest driving force for making that happen is that it requires a more collaborative partnership approach to focus on rapid innovation.
  • Focus on Continuous Improvement and Innovation – A focus on process improvement and continuous innovation is certainly not new to Agile. It has been around a long time and many companies have successfully adopted continuous improvement approaches based on Six Sigma and other methodologies. I published my first book in that area called “From Quality to Business Excellence” in 2003. What I found was that in the companies that did Six Sigma well, it may not even be noticeable that it was Six Sigma. They may not have a lot of the hoopla like black belts and green belts that are normally associated with Six Sigma and it was so deeply engrained into the way the company did business, that it may not even have been called Six Sigma.

    The companies that did it well took a systems thinking approach to adapt it to their business while the more superficial companies simply did it mechanically “by the book” and treated it as just another “Program du jour”. I think a similar thing is happening today with Agile. Companies who take the time and effort to understand Agile at a deeper level and adapt it to their business are probably more likely to do it successfully.

  • Respect for People and Self-organizing Teams – This principle is also not new to Agile. It was a key element of Dr. Deming’s principles that form the basis of the Total Quality Management (TQM) approach and I can remember a strong focus on this when I worked at Motorola in the early 1990’s. It’s another thing like Six Sigma that some companies forget about when the pressure gets intense to deliver business results. They sometimes take a superficial, brute-force approach to try to drive business results rather than taking a systems-thinking approach to understanding the factors that drive business results and the role that people play in achieving those goals.

If you only focus on those three things about a company’s culture, I think you will have a pretty good foundation for implementing an Agile development approach and those three things are somewhat common to all companies regardless of what business they’re in.

By the way, here’s an interesting footnote to this article: Walmart has recognized the importance of e-commerce to their business and has formed a new division called “Walmart Labs” to address that challenge. Here’s an interesting article on that topic:

http://www.technologyreview.com/news/429589/walmarts-new-high-tech-labs-youre-not-in-arkansas-anymore/

Agile Versus Waterfall

How many times have you heard people compare “Agile versus Waterfall”? It happens a lot, I do it myself, and I keep hearing presentations that talk about how Agile has displaced “Waterfall”. But, if you really think about it, I don’t think that’s a very meaningful comparison and it’s out-of-date – true “Waterfall”, as a methodology, died a long time ago for most projects yet people continue to make that comparison.

The problem is that the word “Waterfall” is used very loosely and indiscriminately. In many cases, when people use the word “Waterfall”, they’re not using it to refer to the specific “Waterfall” methodology, they’re using it loosely to refer to a general style of project management that obsessively emphasizes predictability and control over agility. The word “Waterfall” actually has some fairly specific connotations. For example, a true “Waterfall” project is broken up into phases based on functional activities (design, develop, test, etc.) that typically happen sequentially with phase gates that control the progression from one phase to the next. I think the usage of that methodology for software development today is practically zero, yet people continue to compare Agile to “Waterfall”.

A more meaningful comparison is between an “adaptive” approach to project management and a “plan-driven” approach to project management. “Plan-driven project management” is a style of project management that is applied to projects where the requirements and plan for completing the project can be defined to some extent prior to implementing the project. In contrast, an “adaptive” style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented and the requirements and plan for the project are expected to evolve as the project progresses.

No project is ever totally plan-driven or totally adaptive; you won’t find many projects that start out with an absolutely rigid plan that is not expected to change at all, and you won’t find many projects that have no plan whatsoever of how the project will be done. There is a broad range of alternative approaches between those two extremes. It is a matter of choosing the right level of upfront planning to be applied to a project based on the level of uncertainty and other factors in the project and it takes some skill to do that. If I was building a bridge across a river, it would probably call for a more plan-driven approach. If I set out to find a cure for cancer, it would probably call for a more adaptive approach.

There is nothing inherently wrong with either of these approaches (adaptive or plan-driven), the problem comes about when people try to force-fit a project to one of these approaches rather than selecting and tailoring the approach to fit the project. For example, if I were to set out to try to find a cure for cancer and I attempted to apply a highly plan-driven approach to that project, the results would probably be very dismal. Why does that happen?

  • People many times see this as a binary choice – the perception is that a project is either Agile or Waterfall and there’s nothing in between. As a result, people feel like they are forced to choose one extreme or the other. They don’t see that there is actually a spectrum of approaches from totally adaptive at one extreme to totally plan-driven at the other extreme. (See my recent blog post on a Hybrid Agile approach for an example of a blended approach):


    https://managedagile.wordpress.com/2013/07/22/a-hybrid-agile-development-framework/

  • It takes much more skill to fit a methodology (or combination of methodologies) to a project – you have to know a broader range of methodologies and you have to understand the principles behind the methodologies at a deeper level to know how to tailor the methodology and blend different methodologies together to fit a given situation. Some people are primarily skilled in one particular methodology and tend to implement that methodology mechanically “by the book”. It’s like being a carpenter and the only tool in your tool bag is a hammer.

The impact of misusing the word “Waterfall” is significant:

  • It causes people to “throw out the baby with the bath water”. By misusing the word “Waterfall” and categorizing all plan-driven approaches as “Waterfall”, people tend to dismiss any form of plan-driven approach and to regard any kind of upfront planning as inconsistent with an Agile project.
  • It has caused a lot of polarization between the traditional project management community and the agile community. The perception is that project managers are associated with the Waterfall approach and, as a result, project management skills are not needed because the Waterfall approach is an out-of-date approach for many projects.

The Waterfall approach has been obsolete for many projects for a long time (the exception being some selected industries like construction where it is still very useful and relevant). Even prior to Agile, many people were widely using iterative approaches like RUP for software development in place of Waterfall. So, I don’t think comparing Agile to Waterfall is very meaningful any more, but its very difficult to get people to stop thinking in those terms because it has been so prevalent for a long time. However, I think it’s useful to understand that when people in the Agile community criticize “Waterfall”, in many cases they are not talking about the specific “Waterfall” methodology, they are really talking about a style of project management that obsessively applies a plan-driven and control-oriented project management approach to projects whether it fits or not.

The problem is really in obsessively force-fitting a project to a given approach (whatever it might be) whether it fits or not. And its just as bad to obsessively force-fit a project to highly adaptive agile approach without any upfront planning if that approach doesn’t fit with the project. For example, I’ve seen an Agile project that has gone for two years without an end in sight before discovering that the scope of the project was much too large for a single Agile team to finish in a reasonable amount of time and the whole project had to be re-planned around multiple Agile teams. Some upfront planning to better define the scope and level of the effort required for the project might have prevented a lot of lost time.

Very few Agile projects are given a “blank check” to do something without any expectations of what the cost and schedule of that effort might be and there is absolutely nothing in the Agile principles and practices that says you shouldn’t do some level of upfront planning for an Agile project. The difference between a highly adaptive project and a highly plan-driven project is how much of that planning is done upfront in the project rather than being deferred till later. It’s not a black-and-white decision to have a totally plan-driven approach or a totally adaptive approach and it requires some skill and judgment to determine what level of upfront planning makes sense in a given project. When people present this decision as “Agile versus Waterfall” it distorts what the real decision is and makes it look like a binary, all-or-nothing choice and that’s not the case.