Project and Delivery Management in the context of changing software development paradigm
(New post published on linkedin, blogger and medium blogging platform)
It has been a long since I left blogging on this space of project management. Probably managing projects and delivery kept me too busy that it became BAU (Business As Usual) for me and led more to philosophical and self-help topics in my blogging space, to bring back balance rather than think about work space again. 😊 But that wasn’t the case, I was happily into reinventing myself, into doing projects and delivery management in different ways, in different context and enjoying what I have been doing. But time has definitely come (and sure so - as I am on a short break!) to write a new one and hope it leads me to writing more on this space. I will be touching upon few concepts, without expanding on the context, and hence for a casual reader it might look simplistic approach in larger organisational context, or they might overlook what I intend to convey. So having given a word of caution as to what you might expect to gain here, let me go and spill out what is in my mind.
The role of project management has evolved in the Information Technology (IT) industry and is probably half-way in its journey to turn a full circle. As the technology evolved rapidly from siloed to distributed development, so did the management and delivery of such projects and initiatives. Organizations and individuals who shied away from such changes and became ‘hard coded’ were the ones who struggled most and felt outdated soon. While others who clung onto the new ways, well — at first spoke differently, and then found themselves — apparently very busy and continuously adapting to newer refinements of managing things. Then it happened again. The vast majority started speaking the new language, had no choice but to mend their ways, and the marketing and sales teams found their new jargon to aid their work. I am sure most would have now guessed what this is all about — agile software development with self-organized projects/product delivery.
So, has agile software development resolved all problems that faced the earlier development models? Yes and No. Has it removed the need for dedicated project or delivery management? Yes and No. So, what works well with agile and what does not?
I am not going to go into details of agile methodologies and different models here. There are enough materials out there on the web and organizations that provide training and consultation to help adopt agile practices and coach their teams. My intention is to bring again certain aspects of project / product / delivery management when projects are running on agile models for whatever reasons they chose to adopt.
Let’s look at the problems and general trends around the four agile software development values:
While there are numerous practical problems in different projects and different organization context, agile approach did provide certain retrospective ways to amend the ways of working to make them effective. However, to help steer towards an agreed goal, there was a need for a different kind of skill set that includes facilitation skills. As agile adoption increased and evolved, so did different roles and designations associated with an IT project. While traditional project and delivery managers took on different hats while owning and delivering projects, and gained over time an ability to coordinate and facilitate delivery, their focus turned elsewhere due to the prevailing career paths for such roles. In agile, the management responsibility is split across all the agile roles, and hence whether one is scrum master, product owner or development team member or a vendor project/delivery manager playing different roles, everyone had to adapt to the ways of working and develop facilitation skills. In essence project success was proportional to team work and team success in every iteration.Let’s look at the 12 agile principles and related practices.
Any triggers that disturbed these factors may only delay the grouping of the team to deliver well within contractual obligations. As many organizations were in transitional phase in the last decade to agile methodologies, every person playing a role in the agile development process irrespective of his /her degree of involvement faced difficult challenges to communicate the actual reality versus perceived reality. This resulted in two larger factions, those who were still on the transitional path — across different levels in the organization versus those who made it to the new ways and were perceived religious agilist, again at different levels within the organization. But if we go back to the original ‘spirit’ of the agile manifesto, and throw away the hardened aspects, these perceptions can be refined.
So can we eradicate the role of a project / delivery manager? 😊
Not at all. There is a lot to learn and apply on holistic management concepts far from any specific methodology and avoid distributed ownership /people related risks. Many agile teams have realized this and appreciate such a role in their team. On the other side, the project/ delivery managers from non-agile experience have to learn an important aspect to adapt to the agile ways — applying their expertise to different, changing context all the time.
However, what is critical from waterfall to agile software development days, projects needed two aspects — client management and software development/delivery. And the facilitation skillset acquired by those opting the management career path in earlier days — project managers, delivery managers — are now required across the distributed self-organizing teams if they have to succeed. While most are learning the skill and adapting to the situations well — albeit with many failed projects — few things that has also worked well and has unified different aspects following agile:
Project and technical delivery management are the same and requires similar role profiles
Gaps perceived between product and project management have come down
Delivery and service management are beginning to unify with agile now becoming agile devops and transitioning towards integrated development and service management tools for development and operations
Flat organization structures with Servant leadership skills
Managing Emotional Intelligence / Quotient / Empathy becoming a need with self-organizing teams
Remote and hybrid working model triggering a change to the original agile manifesto of co-location with technology sprouting to support using metaverse technological advancement
And many more changes to come, as agile manifesto needs to have a retrospective on itself and adapt to the newer paradigm shift. First and foremost, it is important to acknowledge that we aren’t fully and truly agile yet in most context, as it’s a continuous improvement principle. I do think that collectively we have completed half circle, and are getting ready for the next curve in the transition towards a newer model. With changing global situation, this is going to be difficult to predict, but the core aspects of management skills are here to stay and everyone irrespective of their career orientation have to learn, unlearn and relearn to sustain the ongoing changes. Hoping to continue again on this blog more regularly as I navigate through this journey.
References
https://en.wikipedia.org/wiki/Agile_software_development
https://resources.scrumalliance.org/Article/key-values-principles-agile-manifesto
https://hbr.org/2016/05/embracing-agile
https://www.softwaretestinghelp.com/agile-scrum-methodology-for-development-and-testing/
https://www.atlassian.com/agile/manifesto
https://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/
http://www.agilenutshell.com/what_is_agile
https://www.agilealliance.org/agile101/
https://www.productplan.com/glossary/agile-values/
https://www.coursera.org/articles/what-is-agile-a-beginners-guide
