I believe so. This is based on my personal observation over the last 24 years, since I graduated and joined a Software Services company.
In 1994 when I joined this company, in Bangalore, it had less than 1000 employees and about US$ 15 million in revenue. By 2004, that company had hit a revenue of US$ 1 Billion with employee count of above 25000.
2004 was also the year I decided to get my PMP certification. As I went through the various processes in the PMBOK, I could clearly map it to the practices we had been following in my organization with respect to estimation and planning and then execution, monitoring & control and closure of projects.
Being a CMM Level-5 company, engineering processes were clearly well defined, the capability baselines in terms of productivity and expected defect density etc were available to me for planning a new project. We had to submit the closing report with project metrics like productivity achieved and defects delivered along with the non-quantitative information.
By 2000, we had started hearing the phrase ‘We are a Matrix organization’ within the company. The same project managers who executed software projects, where called upon to oversee the external CMM audits. The same pool of Project Managers planned the movement of 500 engineers from an old office to a new one, with minimal loss of productivity. The back-ups would be planned, the new machines in the new office would be ready, data would have been transferred and all things were executed as per plan. On the said day, employees would have a slightly extended lunch. They would leave the workplace after saving their work at say 11:00 am, have lunch and take the pre-arranged bus to the new office. Everything was operational by 2:00 pm. That’s it.
The organization doubled its revenue from US$ 1 Billion in 2004 to US$ 2 Billion by 2006. Having a great leadership team that focused on management processes and discipline meant that the company had the processes and management systems in place to be able to scale up rapidly.
Cut to the future…
It was in 2008 that I think I first heard about ‘Agile’. This time as an entrepreneur working on a product idea. We had engaged a small-time vendor to do software development for us. My first thought to myself was ‘We must have been the lethargic folks’.
Since 2007, I have been conducting Project Management workshop and though I don’t have a count of the number of Project Managers that I have face-to-face interacted in my sessions, but I believe that number is well past 1000, in more than a few dozen organizations.
One of the recurring themes is that most of my participants have been working in some kind of ‘Agile’ environment.
These are some of my observations:
Engineering Vs Management approach
Is agile a substitute to Waterfall i.e. Software engineering methodology or is it a new Project Management approach? Though I won’t say people are largely confused, but there is an unmistakable mixing of the two aspects of executing a project. To the extent that I almost hear some folks say “We don’t need project management, we use agile methodology”.
Agile as an excuse for poor requirements management
Our(or our customer’s) requirements are always changing, therefore we need ‘Agile’ and do not need ‘(The Lethargic) Project Management’. This is a very common phases I get to hear. It’s almost like they believe that putting the label ‘Agile’ on their foreheads would alter the basic mathematics baked into the space-time continuum of the universe. Its like, because we are ‘Agile’, customer can keep changing requirements through out the sprint and we will still deliver by the decided end date at the same quality. To put is mildly the Project-Triple-Constrain doesn’t apply to my project anymore.
Agile as an excuse for poor documentation
Also, there is a strange aversion to documentation. ‘We are agile, we don’t document’. You don’t document things for fun. You document your project decisions for future reference and verification. If you haven’t established a baseline, you will never know how far away you are from your intended goal. Something which is ‘lesser important’ is still ‘important’. Agile does mean that you give more importance to ‘delivered code’ than documentation, but it doesn’t mean that you ‘Don’t need to document’.
The Lethargic Project Management
A quick search on the internet would reveal the large number of articles and blogs comparing various Project Management methodologies and lot of them comparing what they call as ‘Traditional Project Management’ Vs ‘Agile Project Management’. The very fact that these comparisons exist is a symptom of the problem. And that’s why I am forced to coin the term ‘The Lethargic Project Manager’, because if ‘Agile Project Management’ exists, there ought to exist the ‘Non Agile Project Management’ to which I give my own name ‘The Lethargic Project Management’.
The Absurdity
This entire debate looks absurd. In fact, the entire situation is absurd. To the extent that an entire industry has been built on this. There are certifications. And there are flavors of certifications. I have actually stopped counting the various flavors of this methodology.
Ok, but what’s the concern?
The above points notwithstanding the question is ‘So, what’s the concern? How does it harm?’. Let a million methodologies mushroom!
There are several issues I have observed:
Tyranny of terms
There is a proliferation of terms that has happened. Each new term giving an impression to the young professional that it is something new and exotic. Something that makes their method ‘Agile’ while everyone else up till that point was ‘Lethargic’.
It’s pretty much like saying ‘Columbus discovered America!’. Like America didn’t exist for thousands of years before Columbus actually discovered it and the natives didn’t exist.
The reality is that no business ever said:
- Take as much time as you want
- Finish as much as you can and deliver when you can
- Money is not important
- End users are secondary
- Understanding business objective is not important
- Quality even if poor is ok
- No need to show intermediate progress, I will see only the end product
As you will agree, these are age old business concerns with any project undertaken by an organization at any time.
Phases and Release/Sprints
The idea of Time-Boxing requirements is as old as we have been talking about Project Management. There is nothing that can convince me that the ancient Egyptians who built the Pyramids didn’t know about Time-Boxing.
Closer in our lifetime, during the first dot-com boom, Time-Boxing was a standard philosophy when entrepreneurs with brilliant ideas wanted to get their product out in a hurry. We would put 4 months as a dead line for launch and work backwards. This would force use to have the optimal phases for design, coding, testing and launching. This ‘boxing’ forced the product owner to prioritize and push some requirements into the next phase.
Estimation- Delphi and Analogous
Techniques like ‘comparing to similar’ and ‘taking inputs anonymously’ are again not new. I won’t insist that the ancient Pharaohs also knew it, but suffice it to say these techniques have been around for more than my lifetime. Calling them ‘Planning Poker’ or giving then any new name isn’t going to change the underlying philosophy of simplifying the process by using 2 simple techniques, one, compare it to the closest equivalent, two, take input anonymously from multiple sources so that they do not influence each other and finally reconcile the differences to arrive at a number acceptable to the group (by majority of unanimity? Its your project, you decide the ground rules.)
Introspection vs Lessons Learnt
Ok, ‘Introspection’ sounds philosophically deeper than ‘Lessons Learnt’. It sounds like a grey-haired sage talking about looking within, while ‘Lessons Learnt’ sounds more like a headmaster’s rebuke to a high school pupil ‘Have you learnt your lessons yet?’.
The Problem
While what I have written are my observations, which are more like symptoms, the underlying problem needs diagnosis.
Most young professionals are being introduced to the ‘Agile’ processes as some sort of a ‘Silver Bullet’ – Like some new age religion that will wash away sins that the earlier religions couldn’t.
Professionals are handed over some set tools and ceremonies as some kind of a final solution to all their problems.
The Implications
There are several implications of this.
- Professionals at early stages of their career are not getting exposed to project planning, execution, monitoring and control. I remember my early days in career where we could see the project in action even though we didn’t have direct project management responsibilities.
- These employees when they move up into the middle management do not have any exposure to Project Management principles and therefore miss simple management issues and are unable to apply rudimentary management solutions to the problem(Example ‘Independent Review’ is a basic risk mitigation step when the stakes are high. ‘Do I need to budget for an independent review?’ is not a question that comes to their mind).
- These organizations then suffer the inability to take up and execute large complex projects. Top-Down estimation and planning capabilities are totally missing within the middle management. Top-Down planning, what I call ‘Bullet-Train’ sizing. The teams can do bottom-up ‘T-Shirt’ sizing but cannot look at large projects and see ‘How much will it cost to build a bullet-train system between two cities’ by instinctively searching for range of per kilometer cost for building a Bullet Train. They cannot plan for the big picture with ‘progressive elaboration’ and managing the project cost and timelines using top-down approach with increasing level of details as the project progresses.
So, what do we do with ‘Agile’?
I am not suggesting that the ‘Agile’ approach is not needed or is flawed in any sense. While time to market has always been an issue, the product life has reduced drastically and so has the product development time. Methods have to be fine tuned for a much more rapid paced business life.
What I see is how ‘Agile’ is positioned and understood is flawed. Agile is not a substitute for Project Management.
No matter what name or label you put on your forehead, the truth is that you cannot bypass the laws of logic, in this case the inviolable Project-Triple-Constrain. That is, you cannot change one of the project characteristic without changing at least one of the other.
I don’t see Agile as a new revolutionary methodology. At best it is a set of documented ‘Best Practices’ and ‘Software Development Template’ that needs to be applied in case of very specific types of projects within the rapid pace of business environment we now live in.
What should organizations do?
First things first, focus on the fundamentals. Organizations and individuals have to put in effort to understand project management fundamentals, such as:
- What is a Project? Why and how does it start? Under what environment is it existing?
- What is Stakeholder Management? How do I identify and analyse stakeholder needs?
- What is Scope and Requirements?
- What is Estimation? This has to be especially understood from a top-down perspective.
- What is Risk?
- What is an ‘Execution Methodology’? And how do decide one for your project? This is where Agile Methodology comes in. Breaking a projected into Phases or in this case ‘Releases’ with ‘Sprints’. A Work Breakdown Structure(WBS) reflecting the High Level Product Road-map that can be Progressively Elaborated and is perfectly aligned with the ‘Release/Sprint’ based execution methodology can be created. Project Managers should be capable to create such a WBS.
- What are the fundamentals of Scheduling? Traditional Vs Agile(Scrum/Kanban)
- What is Quality, Process Capability, Process Stability and Process Improvement?
- What are basic issues with Human Resource Management? Motivational Theories etc.
- What is procurement? Basics of Contract and SoW.
Organizations that do not build a workforce that is exposed to these fundamentals at an early stage in their career would have a challenge in scaling up and growing. As these employees move up the seniority, they will not have the basic grooming and exposure to management issues and how to respond to them. These managers will not be ready to take on more complex projects and the organization will suffer.
Leave a comment