Agile Project Management
Some say if you are agile, there should be no mention of the word ‘project management’ within the four walls of your highly techy environment thereby making the PMO feel alienated. These Project Managers are on the other hand saying developers have no business understanding and their mindset is narrowly focussed on just development which perhaps jeopardizes business expectations and promises made to customers.
If good thinking leads to good products, then what does mix thinking leads to? i.e. a band of classic project managers vs a band of agile developers all working together to deliver the same product but burdened by the luggage of contrasting mindsets.
Again, these were thoughts in my head, and now suddenly interrupted by the last call from the train manager. I was daydreaming as we arrived Euston station. My new role “Agile Project Manager” was playing tricks on me again. The “Me” talking had always referred to himself as a typical agilist if such word exists and now I feel like I was about to sleep with the enemy or move to the dark side. I will be dealing with business stakeholders, working and reporting on strict datelines, building Gantt charts and constantly updating my excel reports, entering resource hours with one key thing in my head “Cost!”
In a traditional project management world, the cost of requirement gathering, the cost of design, the cost of development, testing and maintenance are usually treated and managed separately. Once requirement gathering is complete, the next phase “Analysis will be approved and the whole focus will be on that and then the next, and then the next etc. Imagine you get hired with the title “Agile Project Manager” and find your self in such environment, will you quit or influence the necessary change. I don’t know about you, but I’d chose the later or at least try to.
Although many software projects remain sort of highly artefact driven or ‘waterfallish’, there is a vast number adopting agile as it has become apparent that agility works. The arts of incrementalism, the game of discipline, the value of honesty, focus and constant communication and collaboration brings excitement and thorough sense of responsibility within that working environment.
The question is: Does the agile PM have a role to play here? If Yes, then should they be embedded into the agile team? If No, then why Not?
This article highlights the relevance and role of an agile project manager within a tech-driven organisation. Although we are just focusing on tech, it is also important to know that the agile approach is used for all types of projects and not just IT projects as this approach actually have little to do with software. Its more about recognizing and applying feedback where relevant.
The oxford dictionary describes agile as the ability to think and understand quickly. This is inline with the agile manifesto that defines the agile approach as the ability to recognize and provide feedback. Again, does the agile PM fits into this? I think the answer is “Yes”
Let’s think about what the agile manifesto says again:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
While the left and the right should both be taken seriously, preference is given to the left side. But it is important to know that both sides are important for the successful delivery of the product.
I have been in environments where people make comments like “ we are agile now, we don’t need all these plans” or “This contract talk is taking too long, lets just start work, after all, we are agile” The worse of them is “We are agile and so there is no need for these documentations” The outcome of these is usually an enormous amount of re-work. So again, both sides are very important and should be carried out.
This understanding should be familiar and understood by everyone involved in the project including the customers as in the real sense we are all customer or value driven.
The Agile Project manager perhaps does not have some fix role which all organizations must follow, but what is more important here is that he or she must have an agile mindset. In some organizations, the Scrum Master plays the role of an Agile Project Manager, in some depending on the size of the team or teams, there is the need for someone to sit above the PO (Product Owner) and do all that boring accountability and reporting stuff. That could be the agile PM. The most common of them all is the case whereby a Project Manager is assigned to an agile Project and in the real sense, we want to call him/her an “Agile Project Manager”
In all cases, the most important thing is for that person to have the agile mindset. An agile mindset means they understand:
- the principles behind the agile manifesto
- the agile reporting models
- the mindset of a developer (if working in development world) as they see things differently
- Must be willing to collaborate, Understand and work with the Scrum-Master or Product Owner without interrupting the development team
- Be motivated and be part of the people that create a motivated and agile environment
It’s important to see that even the principles behind agile recognizes the fact that business people and developers must work together daily, but how can this happen if they don’t understand each other. I always tell my developers that they should adopt a manager’s mindset likewise managers should have the developer’s mindset. That takes us back to the type of managers we are talking about here, “The agile project managers”
They are a couple ie Development and Management and we all now know a couple that understands each other make a happy family.
The developer is busy thinking of the work breakdown structure (WBS) derived from the effective planning session possibly in the form of use cases etc and the agile project manager, on the other hand, is busy thinking of the business value of the work being done in terms of cost and benefit to the organisation as a whole.
This brings us to the invention of “User stories” within agile development. I personally think its one of the greatest invention ever made. The user story is what brings the world of “Development” and the world of “Business” together. As a <role>, I want <feature> so that <business reason>.
The developer should understand what he/she needs to build but he/she also needs to understand the business value he/she is trying to achieve.The agile project manager, on the other hand, is thinking cost/benefit, what is it worth? but he needs to understand the agile principles being implemented to build that product. It's as simple as that.
If being agile is a game, then everyone involved needs to play by her rules.
The business might need him to do a formal ROI (Return on Investment) or PNL (Profit and Loss) calculations as we all know everything eventually boils down to the monetary value.
This is when the calculation of the BVI (Business Value Index) comes into play. i.e. for each work being done, both the managers and the developers should have in mind that in a typical business world, the BVI will represent the percentage of the total business cost in that bucket of WBS, backlog or Sprint and the Scrum Master or if acting as the agile PM should be able to derive this information using the relevant tools and then feedback to the agile PM.
This constant communication should be happening as everyone must be made aware of what is going on. That way, the development team is less distracted, The product owner is focused on his/her backlog, The agile PM have the relevant information to feed his/her reports and the scrum master or agile coach will be there ensuring the agile principles are followed both within the team and the organization as a whole.