Methodology, managers, and projects


When working on a project there are a few different ways to manage those projects. One is the traditional waterfall approach, which is your top down project where you have to use Gantt charts to figure out how long you think it’s going to take up front, where you’re given a set date that can’t change without a lot of effort to do a certain amount of poorly defined requirements, and a set amount of money to do the project. This approach has been how Windows and many video games have been produced in the past. It’s not really extremely effective and really no one really likes working a project conducted using Waterfall methodologies. There are risks, projects get cancelled and the project management can seem to be capricious and opaque. This leads to lack of trust and belief that management has the best interest in mind for both the project and the employees on the project.

To address these concerns a group of people created the Agile project management methodology. The goal was to value working software over documentation. Which means that each bit of software is broken down into the minimum viable feature, or the smallest piece of working software that could be packaged and used by a customer. The goal is to manage the project through adjusting how many of these features are going to be finished by the go live date. Effectively you build small bits of work instead of finishing one giant massive piece of software.

This approach is effective for other types of technology that have a modular architecture. There’s some minimum viable product, where you need a minimum set of features for the product to actually work. For example a cell phone needs to have a combination of features to function properly. Things like bendable screens would not be in the minimum viable product, but an excellent touch screen would be. These minimum viable features can be modulated based on the Kano model – which is useful for determining if a specific feature is basic, a pleaser, or a delighter. If the feature falls into basic, you must include that feature if you’d like it to be a success. However, those minimum features don’t guarantee a successful product, you’ll need to include pleasers as well as delighters. Those are the pieces of scope that you will be able to eliminate to make sure you actually launch the product on time.

Issues with these projects come whenever there is a mixture of methodologies. When management believes projects must be managed through waterfall through a central project results office while the development team believes the project is being managed through the agile methodology. This creates serious issues whenever there is miscommunication, lack of information, or lack of understanding the real status of the agile team’s approach. This is exacerbated by the required openness in the agile approach (where you are supposed to continually learn from your mistakes and have a conversation about all the problems you’ve had – to fix them) while in waterfall it is better for people to hide and place blame elsewhere whenever things are not going well. Not because people are bad, but the incentives are in place to behave this way. With a single option of go/no go, it’s better to minimize the known risks as if things are misunderstood as going poorly it will drive management to take action. While in an Agile team, discussing the true status of the project is vital through self policing and partnering with other agile teams to address the problem. The greater the likelihood of success of the projects.

This conflict and a switch from governance in the agile methodology can and will destroy the trust the various agile teams have developed. An organization needs to fully commit to a single project management methodology or it will struggle to complete any project within scope and budget and will demoralize the leaders of projects being worked in agile, as waterfall would likely be the methodology that management selects. Leaders of Agile projects should leave organizations that undercut the agile teams, as it will not stop and will have dramatic impacts on their careers in the long run.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s