What is Agile Project Release Planning?
Many years ago I used to work for a small quick print company. People would purchase letterheads, envelopes, business cards, brochures, forms, and other printed materials necessary to run their business. This was long before desktop publishing came into existence and we were able to keep up a pretty good base of clientele that would come back time and time again.
One of the things that people came back for frequently was our $9.95 Business Card Special. That’s right…$9.95 was all you had to pay for 500 business cards. Sure, there were certain conditions that came with the offer. You had to place your order by Wednesday in order to pick them up the following Monday. The business cards would come on either cream or white business card stock. And, you had your choice of three ink colors…black, black, or black.
The choice of 3 ink colors…black, black, or black…ensured that running the business cards would be a profitable endeavor for this small print shop. This would allow for twelve different 2 ½” x 3” business cards to be printed on one 8 ½ x 11 sheet of card stock.
It would take about 10-15 minutes to run 500 sheets of card stock through the printing press. We would do scores of $9.95 Business Card specials each week. Plus, this business card special would bring people into the print shop who also needed letterheads, envelopes, and additional printed items that resulted in additional revenue.
What made running these business cards profitable each week? Their inflexibility. The fact that you had to place your order by Wednesday, the fact that there were only two choices of paper, and the fact that you had only one choice of ink, made it worth the quick print shop’s time to keep running these week after week. There was no flexibility or agility in this special offer. There was no ability to change or make modifications if you wanted to take advantage of the $9.95 Business Card Special.
Inflexibility and the lack of agility may work in some environments. However, in other environments it doesn’t work quite as well. One of these areas is agile project management release planning. The days of staid and inflexible development schedules and project management methodologies are fading into the background. More and more companies, including large enterprises are adopting agile methodologies such as scrum.
What is Agile Project Management Release Planning?
Agile project management release planning is as its name implies: flexible. Agile project management is designed to be able to turn on a dime and pivot in real-time as needs and circumstances change. This is predicated on the fact that smaller releases executed over smaller time frames will ideally not change much. Then, as that release cycle is underway, feedback and adjustments can be made that will move into the next release.
This carries with it a number of benefits, such as smaller releases providing for new functionality faster and the end-users feedback constantly incorporated into the end product. This allows it to align closer with their final expectations.
Understanding agile project management release planning also carries with it some inherent downside and risks. These risks and downside are not typically present in conventional methodologies, such as the Waterfall Method of software development.
The very flexibility that makes an agile project management plan so appealing can also be the nemesis of project managers who are used to working with more structured and formal methodologies. Unfortunately, in the name of Agile, I’ve seen key pieces of functionality get dumped at the last minute because the team ran out of time. This is much to the chagrin of the project manager who now needs to go back to the client or end user and let them know that this key piece of functionality is missing.
Two Views of Agile Project Management Release Planning
What is agile project management release planning? There are two distinct views on how this is accomplished.
- Fixed Date: The fixed date approach draws a line in the sand when it comes to the date the project must be complete. There is no negotiation when it comes to the date being met. It may be that there is a trade show or event where a new product or service is being introduced and this project supports those efforts.The challenge with a fixed data approach is that the scope of the project may have some flexibility. The team can commit to a particular date, but they may not be able to commit to 100% of the functionality being requested to be complete. This flexibility in scope is typically understood in this type of agile environment.The goal should be to get as much as can possibly be done by the fixed date, and then roll whatever is left into the next development cycle. What should NOT be orphaned for the next development cycle, however, are large pieces of critical functionality that must be complete in order for the product to provide value.
- Fixed Scope: The fixed scope approach draws a line in the sand when it comes to the features and functionality that must be in the product. There is no negotiation when it comes to what is included, but there may be some flexibility around the time that the project is complete. This may be the case when there are only a handful, or one, new feature being introduced and releasing the product without that functionality would be meaningless.The flexibility in the timing of the project needs to be somewhat reasonable, however. For example, a 6-8 week development cycle that drags on another 6-8 weeks has totally missed the mark and the spirit of what is agile project management. It’s understood that schedules may slip days or a week on short development cycles, but it shouldn’t be much longer than that.
The Devil’s advocate may say “But, I have a fixed date and a fixed scope” when discussing agile project management. Welcome to one of the biggest challenges of project management…working within the triple constraint of scope, cost (we haven’t even talked about that one), and speed. Plus, project quality must be factored in as well.
It’s at this point that hard decisions and trade-offs will need to be made. You want to be as accommodating as you can as a project manager, but when requests become unreasonable and untenable then you need to raise your hand and say no.
A Word to Agile Methodology Developers
Please do yourself a favor when working within the agile project management methodology; say what you are going to do and then do what you said you would do.
Here’s an observation: Developers will push back and say a date or scope is not reasonable within a certain period of time. Fine, that’s certainly within their right to do so. They will then give an answer as to when they think it can be done. The project manager can respect that and go back to the client or end user with the realistic date. It may be longer than what the client would like, but “it is what it is”.
The new date approaches and the work is still not done for a multitude of reasons. This causes a new date to enter the picture. This results in a double-whammy to the client or end user who agreed upon a new date previously, and now they have to agree to another new date.
Unfortunately, I’ve seen that conversation take place up to 4-5 times! Bad project management? Perhaps. But, there needs to be a reality check on both sides when it comes to understanding agile project management.
The days of the $9.95 Business Card special are long gone and so is its inflexibility and lack of agility. There are so many choices out there now people can get whatever they want whenever they want it. Keep this sense of flexibility and agility within your agile project management release planning methodology and you’ll have scores of projects to work on for years to come!
Try ProjectManager.com FREE for 30 days and support whatever type of project management methodology you use. Our Web-based project management software allows you to customize your project plans for conventional or agile methodologies. Use our planning software to create a template establishing agile project management steps and use it as a starting point for each of your new projects. This will save you time and make sure all your projects are executed the same way