To Be or Not To Be Agile

By Sabrina Schindler

three-341441_1280

The concept of Agile Project Management (APM) has been turning the heads of management teams across industries lately. This isn’t particularly surprising; who wouldn’t be interested in a business approach that promotes high speed, high quality, and high impact results? But before everyone jumps on the agile bandwagon, let’s take a look at what agile really is and decipher if it is truly the most effective solution for your organization.

Agile Is…

First and foremost, agile is a project methodology originally designed for software development projects that promotes value-driven, iterative deliverables accomplished over short 2-4 week periods, dubbed sprints. The objectives and requirements are defined at the beginning of a sprint, and those are the only items addressed during that sprint. If new requirements arise, they go into a work-in-progress (WIP) backlog to be assigned and executed in a future sprint. The appeal of agile lies in the “sellable” product resulting from a short timeframe that is consistently improved and built upon until all the stakeholders needs are met.

Agile has ultimately become the new buzzword for getting things done. It allows flexibility and continuous improvement throughout the entirety of a project, focusing on collaboration and personal accountability in order to achieve a high quality end-product. Daily “stand-ups” are at the heart of agile which allows any issues to be identified immediately and resolved quickly, making for more effective forward progress.

One of the biggest draws to utilizing APM is the fluidity of project requirements. In the traditional waterfall project management approach, requirements are fully defined during the planning phase and set in the stone with a scope document. It is then the project manager’s job to protect the defined scope with all the severity and aggressiveness of a Secret Service agent. In a true APM style project, however, requirements are never rigid, eliminating the need for a scope document (yay!). But before you get on with your happy dance and jump on the agile train, let me point out that an agile project is still a project, which by definition must have a clear start and finish. Even with agile, you must define the basic requirements to be met, in turn allowing other requirements to be repeatedly added during each sprint.

Agile Is Not…

Agile is not an excuse to avoid planning and/or documenting throughout a project. While the overall project requirements are fluid and continuously identified, APM is not a license for scope creep. Scope in the agile world is a moving target and will morph and evolve throughout the lifecycle of a project, but scope changes still need to be controlled. An agile scope is defined more so at the sprint level rather than the project level; if there are scope changes, it needs to go into the WIP backlog to be reviewed in an upcoming sprint.

Agile is not the best solution for every project. For APM to be value added in your organization there must be dedicated, knowledgeable resources that are readily able to make on-the-fly decisions. This is where a number of organizations fall short. The majority of organizational structures are functional, meaning they are organized into teams based solely on function; the ideal structure for APM is project-focused where the organization is divided into project teams with team members reporting directly to a project manager. In order for a functional organization to fully adopt agile, project resources would need to be pulled from their functional roles and be dedicated to a single project – which, let’s face it, is sometimes easier said than done.

The pace of agile requires quick, definitive decision making. If there are approval processes or multiple decision makers outside the project team that need to have the final say, agile will not work within your organization. At APM’s core is constant progress, and waiting for decisions to be made throws off the entire development and balance of the project. APM also relies heavily on constant communication between project team members. Therefore, ideally, the project team should be in the same location or, at the least, in the same time zone. As previously mentioned, a key element of APM is the daily “stand-up” scrum where team members conduct progress reports at least once daily to identify issues early and make any necessary adjustments to successfully accomplish the requirements of the current sprint. Global or virtual teams have a tendency to reduce communication and minimize accountability, two pillars of agile without which the project will fall apart.

To Be or Not To Be {Agile}, That Is the Question

According to research done by the Project Management Institute (PMI), roughly two-thirds of organizations are using Agile Project Management to some degree. The question becomes to what degree are they truly agile? It is in my experience that many organizations call themselves an agile business, but in reality, they are only utilizing a couple tools out of the agile toolbox. And there’s nothing wrong with that. In fact, it may be better for an organization to adopt a marriage of waterfall and agile philosophies, as each has its strengths and neither is a one-size-fits-all solution.

To identify which methodology to use for a given project, there are a couple key considerations that will tip the scales in the right direction:

  • What are the project restraints? Projects that have a triple constraint – time, budget, and scope – are more effectively managed through traditional waterfall practices because of its strict scope management. Agile is better suited for projects that have fluid requirements that are iteratively defined.
  • What are the stakeholder reporting requirements? If stakeholders are expecting a detailed project plan and regular percent complete reports, they would likely be more comfortable with a waterfall approach.
  • What are the commitment and decision making capabilities of the project team? If you have the luxury of having fully dedicated resources that are empowered to take decisive action on the project, agile would be a great fit.

When it comes to project management, you do not need to be rigid in your requirements, and there is no rule that states you have to stick to just one methodology. Customization is not the enemy in this case; project management is a buffet! Take what you like and put together your own personalized project management system. If you don’t like it, change it. If it isn’t working, modify it. Every organization is unique, and the management of your projects can be too.

About the Author

Sabrina Schindler is a technology consultant with Eide Bailly Technology Consulting. She is a certified Project Management Professional (PMP) with more than 7 years of experience managing software application implementation and optimization projects covering scope, timelines, and resources.

Article source: http://www.pmhut.com/to-be-or-not-to-be-agile

Comments

Powered by Facebook Comments

Leave a Reply

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