Category Archives: Agile Project Management

Product Development versus Project Development

Agile has been most widely used in “product” development environments and less widely used in “project” development environments.  The difference between product development versus project development is not widely recognized.  Of course, this is not a totally universal, black-and-white distinction; but, in general:

  • Products are less deterministic and the business model is usually a little more open-ended.  For example, a company might say that we want to develop a product to satisfy “X” market need (where that market need may only be generally defined and might need to be validated) and we’re going to invest $X to fund a team for ongoing development to support that product development initiative.

For many products, it’s an effort that simply goes on-and-on without end to provide ongoing support and enhancements for the life of the product.  Products are generally somewhat speculative and might require a significant amount of innovation particularly if it is something that has never been done before.  For that reason, a product development effort is very well-suited to an Agile development process.

The business model behind a product development effort is typically based on a projected return on investment (ROI) that the decision to invest $X in the ongoing development effort will provide an acceptable return from the profitability that the product will generate over a period of time.

The decision process associated with a  product development effort is generally focused on prioritizing what features should be added to the product to provide the highest level of customer satisfaction and profitability.  That decision process is ideally suited to an agile development process.

  • Projects are typically more deterministic and less speculative.  Very few development teams are given a “blank check” to do some kind of project without having some expectations of what the project will accomplish, what it’s going to cost, and what the schedule will be.

The business model behind projects is also typically very different.  A company typically has a given amount of funding to invest in projects and some kind of project portfolio management approach is generally needed to determine the appropriate mix of projects that will provide the greatest overall benefit.  In order to make that decision, something must be known about the expected results, costs, and schedules of the projects in that portfolio and there is an ongoing need to monitor the performance of those projects to see if they really are going in the right direction to provide the return that was expected.

The process associated with managing a “project” is also typically different…the general nature of the features the “project” will provide would generally be much more well-defined prior to the start of the project, there would typically be some expectations about what the cost and schedule of the project would be, and it probably wouldn’t be completely open-ended to add features as a “product” might be.   These are key reasons why it is more difficult to apply an Agile development model to projects than it is to products.

Applying Agile principles and practices in a “project” development environment rather than a “product” development environment can be a bit more challenging but it definitely can be done.  Agile works best where there are no constraints on costs and schedules and the primary goal is to add features to maximize customer satisfaction (product model).  When you introduce constraints on costs and schedules (project model), this is the area where it is many times appropriate to use some kind of hybrid managed agile approach to meet the competing demands of a highly flexible and adaptive development approach and the predictability of meeting cost and schedule constraints that is often demanded in a project environment.

The Hybrid Agile Development Approach I’ve described in one of my other posts is an example of how this can be done.  It involves wrapping a “shell” around an Agile development process that can be as thick or thin as you want it to be to provide a sufficient level of planning and predictability to meet the needs of the business environment while retaining a lot of flexibility and adaptivity within the development process.

 

Agile Project Manager Job Description

I was recently asked by a company I am working with to create an Agile Project Manager job description. Here’s what I came up with:

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 users. The APM may be responsible for managing several concurrent high visibility projects using agile methods in a fast-paced environment that may cross multiple business divisions. The APM may play a number of different roles in actual practice:

  • At an enterprise level, leading and managing large, complex enterprise-level projects consisting of multiple Agile teams and/or requiring integration with other activities outside the scope of the Agile teams
  • At a team level, playing a consultative role to help put in place the appropriate people, process, and tools and coaching members of the team as needed to optimize the efficiency of the project team
  • In situations that require a hybrid Agile approach, using good judgment and skill to develop a project management approach that is suitable for planning and managing the effort to achieve the project goals within designated project constraints

In performing these roles, 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 with the appropriate level of 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

To understand the context of this and for more insight into the role of an Agile Project Manager, check out my online training course:

“Mastering Agile Project Management”

Managed Agile Development Framework

I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That presumes that this is a binary, all-or-nothing choice that you have to choose one or the other and not both. It excludes the possibility that there is a hybrid approach that provides the benefits of both approaches. The Managed Agile Development Framework is an example of a hybrid approach that is very easy to implement

A few years ago I was responsible for managing a large government project that required meeting some defined cost and schedule milestones but the customer wanted to take an Agile approach to defining the requirements. In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals.

  • We were able to successfully build a partnership with the government client in which we did a very professional job of managing overall contractual requirements at the “macro-level”, and
  • Within that “macro level” envelope, we were still able to implement a fairly Agile development approach at the “micro-level”

Managed Agile Development Framework

I’m providing a brief description of how it works here (refer to my book for more details). There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.

  • The macro-level framework is a plan-driven approach, designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
  • Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile Scrum approach that is designed to be adaptive to user needs

Naturally, there are tradeoffs between the level of agility and flexibility to adapt to change at the “micro-level” and the level of predictability and control at the “macro-level”. It is important that both the client or business sponsor and the development team need to agree on those tradeoffs. The framework provides a mechanism for making those tradeoffs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.

  • Increasing the level of predictability and control requires beefing up the macro-level and providing more detailed requirements at that level and implementing at least a limited amount of change control
  • To increase the level of agility, you can simply eliminate the macro-level altogether or limit it to only very high-level requirements
  • Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors

A question that often comes up is “How do you handle change control?”. The answer to that question is that you have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level. However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones. This general approach can be used on almost any project.

Check out my online training courses to learn more about developing a hybrid Agile approach and some case studies that show how it has been used successfully.

Agile and Lessons Learned From the Martial Arts

I was engaged in a discussion on LinkedIn that made me think about the relationship of Agile and lessons learned from the martial arts like Karate – in theory, there should be a lot of similarity:

  • Techniques – There are a wide range of Martial Arts techniques that can be applied in different situations
  • Finesse and Skill – Most Martial Arts require finesse and skill; it’s not just a brute force approach
  • Levels of Skill – There are different levels of skill associated with Martial Arts and it is an ongoing journey to become a “master”

In actual practice; however, I think that Agile principles and practices are at a very low level of maturity compared to Martial Arts (that’s perfectly understandable given that Martial Arts have been around for thousands of years); however, there is a lot we can learn from martial arts that can be applied to Agile:

  • Techniques – Agile has become synonymous with Scrum as the primary methodology for implementing Agile and our knowledge of implementing Agile successfully is heavily defined by the “mechanics” of how to implement Scrum. Surely, there must be more to Agile than that. That’s equivalent to saying that Karate is the only Martial Arts practice when there are many, many others.
  • Finesse and Skill – I’ve seen many companies take a very superficial approach to Agile. They will do a few Agile practices like holding Daily Standups and putting up Kanban Boards and call it Agile. In many cases, if you look under the surface, it’s still just a brute force approach to get things done. They haven’t really fully implemented Agile principles and practices and they haven’t mastered the skill and finesse needed to do it well.
    • People may not be dedicated to Agile teams
    • The company may still rely on overtime, weekend work, and pressure to meet unrealistic deadlines
    • There may be no Product Owner role and the business side may not be well-integrated with the project
  • Levels of Skill – Many people don’t seem to realize that there are different levels of skill associated with Agile (some of those levels aren’t even fully understood yet).
    • There is a wealth of knowledge about how to do almost every aspect of Scrum at the team level but very little is understood about how to scale Agile to an enterprise level and how to integrate it with a business environment that isn’t necessarily well-suited to Agile.
    • There are also still very wide gaps in our understanding of how to blend Agile principles and practices with more traditional project management principles and practices which are often seen as competitive rather than complementary with Agile.

There’s a particular concept from Martial Arts that is helpful to understand the level of maturity we are at in Agile. The concept of “Shu-ha-ri” is a Japanese concept to define different levels of proficiency in Martial Arts:

    • “Shu” means to keep, protect, keep or maintain. During the “Shu” phase, the student builds the technical foundation of the art.
      In “Shu”, the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher. In this way, a lasting technical foundation is built on which the deeper understanding of the art can be based
    • “Ha” is the second stage of the process. “Ha” means to detach and means that the student breaks free from traditions to some extent.
      In the “Ha” stage, the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.
    • “Ri” means to go beyond or transcend. In this stage, the student is no longer a student in the normal sense, but a practitioner.
      The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life. In the Ri stage, the art truly becomes the practitioner’s own and to some extent his or her own creation.

(Source: Shu-Ha-Ri http://www.aikidofaq.com/essays/tin/shuhari.html)

If you think about our current level of knowledge of Agile as it exists today, I think many people are still struggling with the “Shu” level to understand the mechanics of how to do Scrum and have a long way to go to really get to higher levels of mastery. I’m not sure how many people realize how big this gap is between where we are now and where we need to get to. I think there are many people who seem to think that all there is to know is the mechanics of how to do Scrum at the team level and I think we have hardly scratched the surface of the knowledge that is needed to be known about how to successfully do Agile Project Management.

Martial Arts have been around for thousands of years and there’s still a lot to be learned so its very understandable that our level of knowledge about Agile is at a fairly low level of maturity. For example, here is a very good article written by Patti Gilchrist on the innovations that Bruce Lee has brought to Martial Arts that has some similar thoughts to this article that I really liked: http://www.projectmanagement.com/articles/278838/Of-Martial-Arts-and-Methodology

The Impact of Wishful Thinking in Agile Projects

Have you ever been in an Agile project that was so badly under-staffed that it had no hope of success in any reasonable time? I’ve seen that situation more than once…what seems to happen is that people launch an Agile project without a lot of planning to understand the scope, without doing a schedule estimate to see how long it will take with the current team, and without determining if it is even feasible at all with the current resources. There seems to be a feeling based on a lot of wishful thinking in Agile projects, that an Agile team can do anything given enough time.

There are a couple of things that are typically missing in many Agile projects. One is upfront planning…a lot of people may think doing upfront planning to estimate the scope, costs, and schedule and to explore resource tradeoffs is inconsistent with Agile. I don’t believe it is, but you can do as much or as little of it as you want. At one extreme, you can start an Agile project with little or no defined Product Backlog, completely define the requirements as you go along, and have no idea what the overall cost and schedule will be. Or, at the other extreme, you could have a much more well-defined Product Backlog with story point estimates to estimate the costs and schedule, a defined Product Road Map for completing the project, and a reasonably good idea of when it will finish. I am amazed at the number of people who just launch into an Agile development effort without even realizing that is a choice they can make.

There is also typically such a sense of unbridled optimism and wishful thinking that everything will just somehow come out right that permeates Agile projects. Project Managers develop kind of a sixth sense about projects. It’s kind of a sense of smell you develop after you’ve been a PM for a while that you learn to recognize when a project just “smells” bad and is doomed for failure. You develop that sense of smell more rapidly if you’ve been burned a few times in projects that have failed. A good PM learns to recognize those symptoms of failure early.

That sense of impending doom seems to be missing from many Agile projects that are on a path to failure. What seems to happen is that from sprint-to-sprint; the project may be producing good stuff but without an overall plan, no one steps back to see if the project is really going to finish in a reasonable amount of time.

There’s seems to be an opportunity here to integrate some good, old-fashioned, traditional project management thinking with a modern Agile development approach.

What Are the Symptoms of Methodology Myopia?

Have you ever met someone who has “Methodology Myopia”? The symptoms of this problem are that the person thinks that there is one particular methodology (whatever it might be – Agile, Waterfall, or something else) that is a universal solution for any kind of project you might have. This “one size fits all” approach many times results in people force-fitting a project to a methodology whether it fits or not and practicing that methodology rigidly without necessarily tailoring it to fit the situation. I believe that a better approach is to fit the methodology to the project and sometimes that might require blending elements of different methodologies together to fit the situation.

Why does this problem exist?

  • Sometimes people only know one methodology. For example, for many years, project managers were heavily schooled in the Waterfall approach and there was no need to learn any other methodology.
  • It takes a lot more skill to know how to tailor a methodology and/or mix-and-match elements of different methodologies to fit a situation. It requires knowledge of a broader range of methodologies and a deeper understanding of the principles behind the methodology rather than just the mechanics of how it is implemented.
  • Sometimes people get so over-zealous about a particular methodology that they lose their objectivity and forget that any methodology has limitations and needs to be applied intelligently and tailored as necessary to fit a situation. For example, there are some agilists who are so zealous about Scrum that they completely reject any kind of more traditional plan-driven approach as obsolete and no longer relevant.
  • Consultants often fan the flames of this fire by building the frenzy about a particular methodology or approach being the best thing possible because they are selling their services based on a particular approach or methodology.

In my book, I use the analogy of a Project Manager as a “Cook” versus a Project Manager as a “Chef” (credit for this original idea is due to Bob Wysocki). A “Cook” knows how to prepare a limited number of recipes and do it by the book – a “Chef” knows how to prepare a much broader range of recipes with different and more exotic ingredients and also knows how to create entirely new recipes when required. This is a major challenge for the Project Management profession today…we need more Project Managers who are “Chefs”, who know how fit a methodology or combination of methodologies to a given situation. Many times this will require learning how to blend seemingly disparate approaches like Agile and plan-driven methodologies in the right proportions to fit the situation. Any Project Manager who only knows how to do a traditional plan-driven project management approach based on Waterfall may be severely limited in their career options in the future.

This is a difficult challenge to take on because I don’t believe anyone has all the answers of how to go about blending Agile and traditional plan-driven principles and practices together in the right proportions to fit a given situation. That takes a lot of skill, there is no “canned” solution, and the knowledge of how to do that as well as what works and what doesn’t work in different environments is constantly evolving at this time. However, even though this is a difficult challenge to take on, it’s important to recognize that this problem does exists and begin to take action to resolve it.

For many Project Managers, this requires developing a very broad and deep knowledge of both Agile and traditional plan-driven project management approaches as well as some actual experience in to blending them together that goes well beyond what is covered in the PMI-ACP certification. And, for both Project Managers and agilists, it requires getting past many of the stereotypes, myths, and misconceptions that have polarized these two communities to begin to see how these seemingly disparate approaches can be complementary to each other rather than competitive with each other.

The Agile Project Management Pendulum

The original Agile movement started out as a revolution against the traditional Waterfall methodology which was viewed as very cumbersome, bureaucratic, and inflexible. The need for that revolution was absolutely correct – an Agile approach does offer many advantages where a more adaptive approach is needed; particularly in environments where the requirements are very uncertain and subject to change. However, as in many other revolutions, there’s often a tendency for The Agile Project Management Pendulum to swing too far in the opposite direction to make a correction.

Agile Project Management Pendulum

In particular, a lot of polarization has developed between some people in the Agile community and people in the more traditional project management community.

  • There are many agilists who are entrenched in their perspective that the only way to be “agile” is strictly “by the book” and that there is no need for project management at all – they see project management as a role rather than a set of principles that can be adapted to a broad range of different environments, just as the agile principles can also be applied to a broad range of different environments
  • There are some project managers who are equally entrenched in thinking that traditional, plan-driven, control-oriented approaches are the only way to do project management and have not learned how to integrate an Agile approach into their overall toolkit

The pendulum has begun to swing back towards the middle a bit and there’s less polarization today than there was several years ago, but some of that bias still does exist on both sides of this fence. Some of the progress that has been made over the past few years has been:

  • PMI has recognized the need for integrating an Agile approach with a traditional project management approach and has begun moving in that direction with the PMI-ACP (Agile Certified Practitioner) certification. Although it is a step in the right direction, it doesn’t go far enough, in my opinion. It doesn’t really address the larger question of how a project manager would go about blending together Agile and traditional plan-driven principles and practices in a real-world situation and what role a Project Manager would play in an Agile project to use this knowledge.Is the PMI-ACP certification PMI’s answer to the Agile CSM certification? That would imply that the goal of the PMI-ACP exam would be to compete with CSM and train project managers for the Scrum Master role and I don’t believe that makes sense at all. The only way it makes sense, in my opinion, is for a Project Manager to take on a higher-level role in larger projects that require blending together some traditional plan-driven and Agile principles and practices in the right proportions to fit the situation, but that role is somewhat undefined at this point and also not necessarily widely understood and accepted.

     

  • As Agile begins to be utilized for larger and more complex, enterprise-level projects; there is an increased recognition in the Agile community that an Agile development process like Scrum that works very well at the team level doesn’t necessarily scale very well without some kind of overall management framework and several different frameworks have been developed to fill this need.
    1. The Scaled Agile Framework developed by Dean Leffingwell is an example of a relatively complete approach that incorporates higher levels of project and program management as well as project portfolio management into an overall framework that is fairly Agile from top-to-bottom; however, it is not easy to implement and would typically require a very major transformation for a company to adopt that kind of approach.
    2. For companies who want to integrate an Agile development approach at the team level into a more traditional management framework, the Managed Agile Development approach defined in my latest book and Scott Ambler’s Disciplined Agile Delivery framework are both alternatives that can be used in a more traditional management environment.

It’s time to get past the polarization that has existed in the past and begin to see Agile and plan-driven approaches as complementary to each other, rather than competitive. It’s not an “either-or”, “black-and-white” alternative to adopt an Agile or Waterfall approach as some people have portrayed it; it’s more of a continuous spectrum of alternatives offering different levels of control and adaptivity as needed to fit a given situation. That’s the challenge I’ve tried to take on in my two books on this subject.

People, Process, and Tools in an Agile Project

The inter-relationship of people, process, and tools in an Agile project is important to understand. On several occasions, I’ve been brought in to rescue a project that was in trouble. In many cases, there is an expectation that, as a Project Manager, I will re-plan the project, get it on the right track, and perhaps also”ram-rod” the effort to get it moving through to completion if necessary. That’s the typical expectation of what a traditional Project Manager might do. I think the Agile environment is different…I’ve certainly seen a need to re-plan projects and get them on the right track and it often takes some strong leadership skills to do that; however, a more critical role in many cases in an Agile project is working on developing the right people, process, and tools to make the Agile project teams more effective and self-sufficient. The irony is that if you do that successfully, you might practically eliminate the need for a Project Manager and put yourself out of a job, but that’s the right thing to do. I think that’s a key difference in an Agile project – in a traditional project, the role of the Project Manager might normally be expected to continue all the way to the end in order to push the project on to completion.

I’ve seen several Agile projects that got into trouble because they didn’t have an adequate amount of upfront planning and, as a result didn’t have the right people, process, and tools to do the project successfully – this happens frequently in larger, enterprise-level projects because many people don’t understand or appreciate what it takes to scale an Agile development approach to an enterprise level. Here are a few examples of typical problem areas I’ve seen:

  • People – It takes a lot more skill to organize a large, enterprise-level Agile project because the number and different types of people involved are typically a lot more numerous and complex. It can be a real challenge to figure out how to organize all of the people (both inside and outside of the project teams) to get the effort done successfully. For example, I’ve seen projects get in trouble because there was no Project Governance model defined to provide overall direction to the project. In many cases at an enterprise level, its not as simple as having a single Product Owner to provide direction and without a plan for how all of the stakeholders and decision-makers will participate in the project as it moves forward, it’s very easy for a project to go off-course and get in trouble.
  • Process – In many cases, there’s also not a clear understanding of what it takes to scale an Agile process like Scrum to enterprise levels. There are typically layers of management needed above the team level and it has to be well-integrated with the company’s primary management structure. It may not be as simple as layering a Scrum-of-Scrums approach on top of a couple of Agile teams. There is also often a need to define a hybrid process that blends together some amount of traditional plan-driven project management at a higher level with an Agile development approach like Scrum at the team level.
  • Tools – Tools also can be a major problem area. The tools that people many times use for small, simple Agile projects, just don’t necessarily scale well to larger, more complex, enterprise-level projects. For example, people might use physical story cards and white-boards for tracking progress of small, single-team Agile projects but those methods start to fall short very rapidly as you to try to scale the effort to larger, enterprise-level projects with multiple teams that need to coordinate with each other and may not be collocated. Managing that type of situation typically requires more sophisticated, on-line electronic tools.

I’ve been in situations where clients might not have the patience to address some of these more systemic issues involving people, process, and tools. In some cases, there might be an expectation that the Project Manager will just somehow “ram-rod” the project to get it moving and get it back on the right track but taking that kind of approach and ignoring the more systemic factors associated with people, process, and tools is not likely to be very successful. That’s equivalent to just putting pressure on a broken process to make it work better. A more effective approach in most cases is to fix the broken process.