Agile… No PM Needed?
Today I want to address this comment that was left on a previous post here at pmStudent.com:
Simple, adopt agile methods, which incorporate self organizing teams. Just like that, no PM needed.
My Reply:
I wish you the best of luck Anon. Sounds like a nice dream.
I love agile (my particular experience is with scrum). In my opinion, if you do agile right, you are doing project management. A LOT of people get agile completely wrong, and unfortunately it sounds like you might be one of them.
My Opinion
agile software project management hysteria - by the half-blood prince via Flickr
The flavor of Agile I have experience with is SCRUM.
I am against a top-down approach to project management where the project manager tells their teams how to do their work. That’s not how I manage my projects.
On the other hand, I’ve seen developers have bad experiences with project managers who sign them up for work and deadlines without consulting the team at all. I know some disgruntled developers who have been put into this position. No wonder swing the pendulum all the way to the other side and go off the deep end.
What happens when you do SCRUM without a scrum master? I know exactly what happens, because I’ve been there.
- Accountability Fails – The team ends up working on what they think is cool, regardless of whether the customer wanted it or not. Lots of gold plating springs up. Someone has to manage this thing. Even if it’s the technical lead who is playing the role of PM, someone has to do it. Too much will fall on the floor otherwise.
- Customer Is Lost – Without a project manager, the customer feels disconnected because the team is only focused on writing code, not so much on communication. I’ve seen this countless times. Most customers won’t just throw money your way and be happy with getting to touch a prototype once per cycle.
- Direction Is Lost – Even with agile methods, you need to do some planning. People who go agile because they think it will relieve them of the responsibility to plan for anything are wrong. Even when using scrum, I planned the high-level functionality that would be delivered in each sprint for the whole project. How else do you know how long this project will take? How do you plan your resources? How do you make sure people have another project to go to after this one is done? I use this all the time, here it goes again. “If you aim at nothing, you will hit it every time.” – Zig Ziglar
Do you think I am crazy? If so, tell me exactly why in the comments.
P.S. Anon, why do you have to study PM if no PM is needed?
Other opinions:
Self-Organizing Agile Teams Still Need Leadership
http://www.controlchaos.com/download/Self%20Organization.pdf
Jul 23rd, 2009 at 7:06 am
I’ve worked with agile teams and waterfall oriented development teams, and I’ll take agile every time. The best Agile teams may have so far internalized PM methods and techniques into their cycles that no one person holds the title of PM or needs to; the team members incorporate client communications, planning, and accountability etc. into their work processes. Project management still needs to happen even if there is no titled project manager. Not all teams operate at this high-functioning level, and for those which don’t having a formal PM is very useful. At the least the PM provides directly for the project needs, and at best the PM models and teaches PM techniques to help grow the agile team to use an internalized PM methodology. OTOH, imposing a traditionalist PM on a high-functioning agile team can be stultifying as well.
P.S. That Ziglar quote is great.
Reply
Josh Nankivel Reply:
July 23rd, 2009 at 8:15 am
I think you just said it way better than I did!
I’ve never personally run into an agile team that didn’t need anyone to be the point person though. Maybe that’s just my experience.
Reply
Jul 23rd, 2009 at 8:13 am
Josh and Eily,
Having managed programs and projects for longer than I care to remember, I’ve come to learn a critical point in any discussion like thi:
1. What is the business domain of the project?
2. What are the attributes of the project?
1. Is this software project enterprise, global, corporate, department, personal, embedded, organic, COTS, etc. etc. etc.
2. What the funding, who’s the customer, what’s the business process, who’s participating, etc. etc.
Without a context and a domain for the discussion of ANY method, process, paradigm, etc. the words are meaningless.
This is a continual problem in the discussion of agile methods. I’ve spoken at cocnferences, written papers and persoannl lead agile development programs in realtime controls, ERP, and fligh avionics so I have some background here.
Many (present company excluded) agile voices are clueless about enterprise IT development. Many (present company excluded) advocates for the mis-named waterfall method are clueless about to manage creative teams.
This forum could possibly be a place to have a rational discussion of the needs of various projects in the absence of the philosophy of how to do it.
Glen B. Alleman
VP, Program Planning and Controls
Reply
Josh Nankivel Reply:
July 23rd, 2009 at 8:21 am
Spot on. ejly eluded to her experience with agile teams that didn’t have or need a PM. Perhaps that scenario is rare and highly specific to the project environment.
Are there really environments like that? I’ve never run into one.
Reply
Jul 23rd, 2009 at 8:25 am
Hi, Anon here,
I believe the confusion is caused by use of abbreviations.
The first PM was meant to stand for Project Manager.
The second PM was meant to stand for Project Management.
There is no Project Manager role in Scrum.
I think we can all agree on that.
I learn project management for fun, to use as a bargaining chip against actual Project Managers who scramble to redefine themselves in the face of their role becoming increasingly obsolete, and to understand traditional teams so I can help them migrate to agile.
Oh and I never claimed anything to do with doing scrum without a scrum master. Equating a scrum master with a project manager would be a huge mistake. The scrum master has a clearly defined role in scrum. They are more like a secretary, impediment remover, process advisor and have nothing in common with a project manager. The product owner too also has clearly defined responsibilities that make them more like a customer representative than a project manager.
Both a scrum master and product owner are essential, non-optional elements of scrum. A project manager is not only not required, but incompatible with scrum, as the organisational aspects are taken over by the third scrum role, the self organizing team members.
Reply
Josh Nankivel Reply:
July 23rd, 2009 at 8:40 am
Thanks Anon!
To Glen’s point, I assume you are talking about projects within a specific environment. Can you describe the environment a little more?
Perhaps we didn’t implement scrum by the book, but the theory seldom works exactly right without modification anyway, if ever. When I used scrum and it worked VERY WELL, the scrum master was very much like a project manager. They were the project manager.
Reply
Anon Reply:
July 23rd, 2009 at 9:00 am
“To Glen’s point, I assume you are talking about projects within a specific environment. Can you describe the environment a little more?”
Well I wasn’t intending to talk about projects at all, I was trying to talk about developing software with scrum, which may or may not be in the context of a classical project with a “fixed” scope, cost and duration etc, or it may be a continually developed product. Scrum, which is a very thin simple framework that allows a self organizing team to continually develop their own development process over time, should in theory work for any software development effort.
Personally I find in some cases, such as where hardware development is involved, or where developers are assigned to multiple projects, there may be better choices than scrum, but scrum is still workable without compromising scrum itself.
Scrum is usually used with things like user stories and agile development practices, but neither are part of scrum, and especially atypical situations like I mentioned in the previous paragraph are those where alternatives for these “optional extras” can be applied.
Cases where scrum is not ideal include where the “customer” are not willing to be involved to the extent scrum requires, or where the team lack the skills or maturity to be cross functional and self organizing as scrum requires.
“Perhaps we didn’t implement scrum by the book, but the theory seldom works exactly right without modification anyway, if ever. When I used scrum and it worked VERY WELL, the scrum master was very much like a project manager. They were the project manager.”
That sounds typical, in many cases the product owner appears like the project manager too. Ideally, the team members become the collective “project manager”, to the extent that what they do qualifies as project management, I wouldn’t call it that personally, but others might see it that way.
Reply
Josh Nankivel Reply:
July 23rd, 2009 at 9:47 am
Very interesting stuff. I think we are coming at this from different paradigms. It sounds like a lot of things you wouldn’t call projects are exactly what I would call projects. And to me, if there’s a project, there’s project management going on somewhere, even if it’s not a formal project manager.
On my project I would say that in many ways, just about all of the engineers and leads are doing a portion of the project management. When direction changes come about, it’s usually because there is a consensus among the team members. I trust them to make the right decisions from a technical standpoint, and I verify all stakeholders are being served by these decisions before we act on them. There is a division of labor and attention that allows them to focus on what they do best, and I focus on what I do best.
Reply
Jul 23rd, 2009 at 8:33 am
I’ve ridden this hobby horse before to no avail, but here goes again …
Agile approaches seldom have much to do with project management. Agile approaches like scrum and XP are all about software development. Agile approaches are often great for certain types of software development projects (complex, adaptive systems) and often a recipe for disaster on others (integrated HW-SW, very large teams).
On the other hand, “good” project management is inherent in both the Agile Manifesto and the Twelve Principles of Agile Software Development.
Some other random thoughts:
- Software development has always been iterative. Even the original waterfall model from Barry Boehm shows iteration and inter-phase feedback loops.
- Sprints and iterations are equivalent to waterfall phases.
- Stories are deliverables: a small WBS.
- Velocity is conceptually based on earned value. A good measure of performance.
Duncan
William R. Duncan, Project Management Partners
Reply
Josh Nankivel Reply:
July 23rd, 2009 at 8:42 am
Good points Bill. My project is very large and complex, and we have one subsystem where agile approaches are being used…because the work there lends itself to it. For much of the rest of the project, by the book agile just wouldn’t work out.
Reply
Glen B. Alleman Reply:
July 23rd, 2009 at 6:12 pm
Josh,
One of the programs our firm works is $600M worth of flight avionics. Iterative and incremental (spiral) with incremental and itertaive customer injections of requirements is the only way to make progress.
The core avionics drives the SWIL (Software Integration Laboratory) and the spacecraft integration software – those are equal in size to the flight software.
The other extreme is the FPGA and ASIC development which is pure waterfall. This is the structural and mechanical elements of the program are waterfall as well. And the penultimate waterfall program areas – Safety and Mission Assurance.
The discussion around (present company excluded again) MUST have a context.
Reply
Glen B. Alleman Reply:
July 23rd, 2009 at 5:18 pm
Adding to Bill,
Before continuing with any discussion of agile methods as a replacement for project management, ask the following simple question to the proposer of the agile method.
“What is the sevent knowledge areas of PMBOK are covered by the proposed agile method?”
While PMBOK is not my first choice for most things, it is still a good framework for asking this question:
1. Project Initiation
2. Scope Management
3. Time Management
4. Cost Management
5. Quality Management
6. HR Management
7. Communications Management
8. Risk Management
9. Procurement Management
If there are activities in the agile method that fall into one of more of these activities – you’re doing project management no matter what you call it.
These 9, except possibly procurement management – are the irreducable elements of managing a “project,” be it a sofwtare development effort or flying to Mars.
Reply
Jul 23rd, 2009 at 8:34 am
Twitter Comment
RT @pmstudent: waiting for the backlash – Agile… No PM Needed? – [link to post]
– Posted using Chat Catcher
Jul 23rd, 2009 at 3:10 pm
Context: New product Development
Development Efforts:
ELECTRONICS DESIGN: FPGA, vision sensors etc.
SOFTWARE DESIGN: embedded AND User Interfaces and database and networked communications – Industrial Control context.
MECHANICAL DESIGN: motion (move camera’s), safety, enclosures for electronics.
Parts of the software development uses agile like methods. The hardware and mechanical design uses more of an iterative approach (alpa, beta, pre production).
Each area has a project manager who is responsible and accountable for their areas. A Program Manager is responsible/accountable for the entire development (cross functional team so that we can mfg., sell, market, and service the product).
We have found a greater need for Project managers and Program Managers. So, we definitely are not seeing any “reduction” in the need for project or program managers.
Thanks
Reply
Giora Morein Reply:
July 31st, 2009 at 11:37 am
Bob,
I’m not sure what you mean by “Agile-like”. On a scrum project the person responsible would be the Product Owner. On an Agile non-scrum project this role might be referred to as the customer, truth, voice, business etc. Different titles for the same role. Perhaps on you agile projects you actually call them the “Project Manager” though I suspect this person is more concerned with project execution than the quality of the team product deliverable.
Giora Morein, CST
Reply
Jul 24th, 2009 at 5:59 pm
Twitter Comment
#Agile… No PM Needed? [link to post] (via @Agilebuddy)
– Posted using Chat Catcher
Jul 27th, 2009 at 5:36 pm
This is as good of a jumping on point as any…
So I’ve scanned through this post and all its comments, and come away with the same question I always do when discussing project management with “project managers”: where is Configuration Management? I know how integrated and important CM is in the Agile approach. But I don’t see a single comment in this thread that mentions CM in any of your views on project management.
I have been working in the software development industry (financial services, aerospace, and health care) for nearly twelve years, and have functioned for over a decade as a principal-level CM engineer or CM manager. By far, the most successful projects I have been involved with have been Agile projects without a centralized/formalized project management figure. From a CM perspective (and based on my experience), Agile project teams are much better positioned to actually release their projects when software development is complete. There are many reasons why this might be, but my experience tells me that when trying to pull together a software release, the decentralized “project management” knowledge base inherent in Agile development teams is much more efficient than the classic approach to project management.
I’ve worked for very small software development organizations, with less than 20 engineers and not a single project manager that could pump out over $500 million in annual revenue. I’ve also worked for very large monolithic organizations that employed armies of project managers, but never turned out a single software release. Not even in testing environments. My last job is a perfect example of that. They were so caught up in ensuring that their army of project managers had PMP at end of their email signature, that they completely lost focus of the customer and jeopardized any future success the project might have had.
Just an observation from an experienced CM engineer…
Reply
Josh Nankivel Reply:
July 27th, 2009 at 6:29 pm
Thanks for the comment Ron! It would be great to learn more about how CM works in Agile, do you have a website that goes into this?
Reply
Woody Williams Reply:
August 3rd, 2009 at 9:09 am
Configuration Management is included in PMI (PMBOK). The Configuration Management Plan is a part of the Project Management Plan. There is a PMI Global Standard, “Practice Standard for Project Configuration Management,” as well. CM is related to Activities performed as well as Requirements, according to PMI thought. At least at this level, there is no lack of focus.
As you so correctly pointed out, “focus” is the key and many who play the role of project manager are not focused on the most important criteria. As Agile, Lean, and Scrum make headway in redirecting focus, more organizations and project managers will “redirect” themselves ;~)
Reply
Jul 31st, 2009 at 11:35 am
I think there is a very big difference between management and leadership. In scrum, the hope is that the ScrumMaster is a good leader. Some of the responses to this posts talk about a “single person on the team that is accountable/responsible”. On our Scrum Tream, thought entire team is accountable for the project and its execution, the product owner is accountable for the product. It’s quite possible that on a traditional project a product owner might play the role of a Project Manager but on our Scrum teams, we don’t need this specific role. What you will find is that the things a Project Manager would do on a traditional project, is in fact being done — either by the team, the ScrumMaster or the Product Owner.
Giora Morein, CST
Reply
Aug 2nd, 2009 at 9:33 am
There are so many misconceptions and misunderstandings about Project Management it’s difficult to leverage a primary starting point here. One good point might be the difference between “Project Management” and any particular “project manager.”
Project Management (e.g. PMI/PMBOK) is not now nor has it ever been reliant, dependent, or based upon on any single software development lifecycle and neither does Project Management demand or require usage of any specific SDLC. For anyone studying the best practices, following the arrows and dotted lines; understanding how the inputs, tools and techniques, and outputs relate to one another, it is patently obvious that any SDLC “works” within those best practices — RUP, Agile (Scrum or otherwise), Waterfall, Spiral, Prototyping, whatever. Those who claim otherwise are unaware of the facts.
Project Management requires (demands) tailoring the 42 processes (PMBOK) based on organization and project needs including people needs. That means a great deal of latitude including how rigorously each one is followed. There is plenty of latitude in how those processes fit together as well including Phases, Prototyping, and other options that fit virtually every known development methodology. People who say otherwise are misinformed.
Project Management demands (requires) team, stakeholder, customer/client coordination, collaboration, and continuous input/feedback/communication in defining activities, selecting resources, refining requirements, and the like. People who claim this is not the case are misinformed and probably speaking to an experience or experiences with poor project managers or poor organization adoption.
There is nothing in Project Management best practices (PMBOK) that requires, for example, all requirements to be defined up front and never change. Ditto for design. It requires that requirements be known, communicated, collaborated but nowhere is “big design upfront” a mandate. People who have experienced this from project managers must realize that it is a “person” or “organization” mandating this, it is not a Project Management requirement.
Project Management is constantly evolving and improving its best practices but always focused on “what works” — the things that most often lead to a successful project. Project Management is pragmatic at its core and truely focused on outcomes.
When it comes to individual project managers, however, all bets are off… even those with the PMP certification are not immune.
There are, for example, many, many thousands (perhaps hundreds of thousands) of people who claim the role or title of “project manager” (or something similar) but lack any formal training or understanding of Project Management.
Untrained project managers are not all “bad” project managers — some do quite well — but many more have given Project Management a bad reputation when the real blame lies with the person called “project manager.” These folks are not practicing Project Management, they are bootstrapping projects based on their own experiences and whatever (good, bad, or indifferent) organizational guidelines are in place. This is not Project Management.
Even trained, certified project managers are people… and some are guilty of “worst practices” from time to time. Some driven by organizational mandates, some from their own personal misconceptions.
It is important — vital, critical — to those engaging in these types of discussion to separate what is essentially a failed project manager or failed implementation of project management within an organization from what is a failure of Project Management best practices.
When Enron failed, was there a huge national movement to discredit and remove from practice all CPAs? Did businesses all over the world fire their entire financial departments?
No… and the reason is that it was “personal” and organizational. Rogue organizations, rogue accountants, and rogue accounting firms do exist — changes were made to regulations making those kind of rogue actions more difficult in the future. However, no one called for eradicating CPAs due to the “worst practices” of a criminal few.
When project managers or organizations act in ways outside the best practices of Project Management, it is not a Project Management failure.
Reply
Glen B. Alleman Reply:
August 2nd, 2009 at 4:06 pm
Woody,
Great piece.
We must always be reminded that when someone is “counter selling,” “my method is better than the one you’re using” – they are selling, no matter how noble their position.
They are not solving a problem. This is especially true when the “unassailable benefical outcome” is missing from the selling proposition.
Reply
Josh Nankivel Reply:
August 2nd, 2009 at 8:11 pm
Very well stated! That could have been a new post all by itself!
Thanks for the comment Woody!
Reply