4 Aspects of Agile Project Management • Slash

Before I jump into the tools for agile management, let me first begin with some background to set the scene. Roughly 10~15 years ago, the software industry was nearly exclusively using waterfall style project management. Waterfall method being the client gives the tech vendor a scope of work, together they break it down to a granular level, define milestones, time and cost it will take and at that point, part ways. The client wouldn’t come back into the picture until most often the first milestone; this could be months down the road.

During the meeting at that first milestone point, the client would meet with the team to see the expected progress. They would discuss development and give feedback. If everything checked out okay, they would continue or adapt as needed based on the initial agreements. It all sounds good, but all too often these were exhaustingly difficult conversations. Frequently there was no written record of what had been agreed upon, verbal specs and generalized wants; somewhat akin to walking through your house and verbally telling the contractor what you want while he simply listens and nods his head signaling, “sure, okay.”

At that time, software project management was run like a construction project; that is, they ran late, above budget, and were chock-full of power dynamics and aggressive negotiations. This naturally does not paint a pretty picture of collaboration between vendor and client, and it certainly wasn’t. For the client, success often was measured by how completely you could dominate your tech vendor to get them to do what you wanted as fast and as cheap as you wanted.

However, today the software industry has evolved, developing its own unique project management processes. Essentially the industry began setting boundaries to protect itself, boundaries that many of those outside of the industry have yet to encounter or even fully understand. Top management at companies still dictate to their subordinates unrealistic demands, like fixed timelines & budgets, in regards to digital solution development. If management wants a new proprietary digital product for the company, allots a fixed budget of $50US and delegates the task to their IT department… Let’s just say this won’t get them much of anything.

So the industry has fought tirelessly to be taken seriously for the digital products, services & solutions they create & provide. For one thing, they create complex products & solutions which are demanding to scope and ultimately will never be finished as maintenance and regular updates are necessary. These products and solutions become a part of the company, and the direct operating overhead in some cases.

Every great tech vendor knows for the project to succeed, right practices and project management must be followed. Therefore, tech vendors sell what the client wants, but ultimately treat every project internally as an agile project. A good vendor will always push for collaboration & flexibility, an iterative and incremental development, etc. That said, let’s get into some of the key tools for agile project management and what makes them so vital.

Table of Contents

From Specs to a Roadmap

The first tool which agile empowers projects with is the ability to turn specs into a roadmap. A roadmap will define a sequence of themes or features that will be added to the product over a certain period of time. Therefore, the timeline becomes a goal in a sense even though any number of things can happen and change during this timeline; ultimately, the sequence of features to be added is king.

When you roadmap, you have to consider a variety of strategic elements. First you have to build a strong foundation from the onset. The initial stages of an agile project often leave the client feeling as though they are not getting much value if any at all. That’s a reflection of building the foundation as in the project infrastructure, development environments, automation, etc. Once these elements are set within the system, you can truly begin to deliver value to the client by focusing on the features outlined in the roadmap.

Your roadmap will provide something akin to a common diagram displaying time and effort allowing you to better prioritize your development and know how to deliver value to the client. For example, the feature that requires the least amount of time and provides the most value is something you can start with; barring no dependency on other items. The sooner you reach your first MVP, the sooner the client can test with certain users, get feedback & know more about their product in reality.

Therein lies the value that the roadmap tool brings to your agile project, prioritizing features based on value delivered to the client. So the client’s scope based project now becomes a strategic partner based relationship; one where yours and the client’s interests are aligned. This, of course, is best for all parties involved, and is the first step for the client in understanding the value of the agile process.

Better understanding users, their behaviors and how they use the interface will allow you to design and build a better product. A roadmap in agile project management will allow the client through iterative & incremental development to narrow down the design and build the product that users want to use. All this simply leads to increasing the success of the product the client is looking to build and the roadmap is the plan to get you there!

Project Goals

Now we realize having project goals is not unique to any specific project management methodology. However, in reference to agile goals, there are both external and internal goals; external being client goals and internal being those of the tech vendor.

Traditionally, client goals were ones like budget, building the right product, keeping to a timeline and so on. Now with today’s agile mindset in the industry, client goals are beginning to evolve so to speak. For example, clients now make finding a trusted partner a clear goal; they want a tech vendor who is more of a partner. One who serves as a trusted advisor through development of their product and beyond, helping to steer them in the direction that is most beneficial for their organization rather than just complete the project and go their separate ways.

It’s about understanding. Clients want a tech partner who understands their business and its situation; for example, when times are tough, the client most desires flexibility from their tech partner. It’s that, “Hey, could we put the development on hold for a couple months while I sort out internal funding?” They are hoping for a positive, supportive response to this. A partner who is willing to help the client rather than treat them as simply a transaction.

You may be thinking, “What do you mean, a trusted partner?” Well simply put, one who does not shy away from being transparent about how they do business. Clients are looking for the chance to partner with a tech vendor who is clear about their working practices, how they do business and what they bring to the table. This is not just a goal of clients, but ironically one of agile management. Your agile project will benefit exponentially from the collaboration born of the partnership.

External goals for the client can take many forms. For example, the project in itself presents an additional workload for them which they may not be able to carry alone; partnering with the right tech vendor therefore, is a goal they are looking to achieve. Additionally, the client may have the goal of learning and gaining the ability to build their own tech team, and doing so together with the tech vendor will give them the knowledge needed and help them to ultimately achieve this goal.

Internal goals need attention as well; the tech vendor has a business to run rather than an NPO. The client has budget, scope & timeline goals while the tech vendor has profit. The development team has goals as well, building their careers and furthering their coding skills are a given. Relationship goals too are present between team members, between client and team, client and vendor management, etc.

Waterfall is about selling a one off, agile is about selling the value of relationships. Goal setting is all about building relationships with clients, building trust & respect long-term. Profit is naturally important for any business, but the value of relationships cannot and should never be lessened by the need for profit. Never discredit the driving power of goals, both internal & external.

RAID – Risks, Assumptions, Issues, Dependencies

Full disclosure, I used to work for a helicopter manufacturer years ago in Europe. It was there that I was first introduced to the army of individuals dedicated to risk & change management within an organization. Calculating potential risks and considering scope changes is a project of its own; one that demands a ton of resources and attention.

That may work when building helicopters, but it’s not how software development works. That being said, an agile project will always include a RAID analysis as change is the norm. Risks are inherent in creating digital products & solutions; seeing & acknowledging them is the first step to dealing with them appropriately. Instead of creating a separate entity for managing risks and changes that plugs into the main project, with agile it’s a driver so it needs to be baked into the whole.

Therefore, the development team must be aware of all the risks, assumptions, issues and dependencies within the project so they can adapt and pivot when they come up against those elements. Developers operate in this environment with these elements so open, honest conversation is necessary to manage them. Hence, RAID becomes a tool which drives the development toward success rather than something to fear. It’s a team effort, no one individual must face the four challenges alone!

Changelog

Finally we come to the changelog. When a client opts for a fixed scope project, you’re already giving them initial approval to change things if they want. This provides immediate upfront value to the client; however, you must preemptively assign some limitations to this ability to change. If the client’s changes interfere with the vendor achieving its internal goals, naturally some backstops to prevent this need to be put into place.

The changelog is the tool you need to keep track of, a history of sorts, all the changes which were made per the client’s behest. This will show clearly how far the project has perhaps drifted away from the original scope. For example, if you order a custom dining set with four standard chairs, but in the end the chairs have changed into two rocking chairs and two swivel chairs with armrests. Well anyone can see how this is no longer what the original scope and cost were based on. Therefore, in this case, some tough negotiations will take place once the changes begin to take the project further and further from that original scope.

A changelog that shows small alterations that bend the scope rather than break it is going to be the most tenable for all involved. Agile allows for considerable changes, but the client needs to be aware of where the line is. The changelog helps keep track of how close you’re coming to line!

Ultimately, Agile project management is beneficial for all parties involved, and is not just one sided. The processes therein looks to allow both client and vendor to develop a trust relationship, one with mutual respect where values and goals are aligned resulting in the best possible product or solution being built. For guaranteed success in agile: follow the roadmap, focus on the internal & external goals, allow the RAID to be a driver, and be mindful of the changelog.