Self-governing, self-stating, self-managing, self-organizing TEAM.
Combined human potential. Direct interactions & co-operation. Simplifying communication routes.
Power to the (team) people.
Yay.
Yes, that's right, agile approach promotes all the team-related statements listed above. Scrum team, in favorable circumstances, can perform magnificently without any kind of manager support (not mentioning one onboard). But does it mean that agile projects ...
... don't need managers at all?
Plenty of people think that way - due to dogmatic interpretation of Agile Manifesto or just because they've crossed paths with some asshole-manager (who didn't ...) & they don't want to refresh the experience. But to be honest I disagree with that thesis anyway. As long as managers do what they are REALLY supposed to do, they ARE needed.
Managing is NOT about ...
- being bossy & finger-pointing stuff to be done by particular people
- useless chart shuffling
- saving most interesting low-level work for yourself & delegating dull stuff to subordinates
In case of agile it's also not about managing scope, quality, risk, etc. - these are now the duties of the whole agile team.
What are managers needed for then?
-
Projects' sizes vary. Some initiatives span among several IT applications & involve multiple teams. In such environment, single teams perspective may be far from high-level perspective one. And that's understandable - just like in army: there's operational, tactical & strategic level view. And they should all be covered.
-
IT projects are not just about producing code. Introducing new applications / changing existing ones involves a lot of non-development activities: like providing training or business service introduction / transformation (sometimes also decommissioning old ones). All these may require a lot of different skills that agile team may not (& doesn't have to) possess. Do not underestimate the amount of work & responsibility here - service management is a great example.
-
Projects happen in organizations, but organizations aren't only about projects. HR happen, budgeting happen, procurement happen, logistics happen. Agile teams have to interact with the various functional units of the organization (that may have nothing in common with IT product development) & those interactions may be something far more deeper than just removing basic impediments - especially in companies whose core business isn't software development. That should be covered by managers too.
-
Communication between agile team & their business partners (users + owners) is absolutely crucial, but there are several interested parties ("stakeholders") in the game as well -> including top management, program management, enterprise architects, marketing. Each of those groups is interested in different perspective, granularity, timeframe & accuracy of reported information - someone has to make sure a proper communication is prepared, released, routed & processed (in all directions).
-
Individual projects may get really complex & easily involve hundreds of people. But large enterprise usually conduct several projects in the same time. Those projects may involve multiple departaments / companies, but on the other hand it's still possible that your agile team performs activities that conceptually belong to several projects (that may not even be perceptible from their perspective) - this requires coordination, coordination & even more coordination. In such scenarios, having a person focused on the project (not product) perspective won't hurt.
-
These days agile becomes pretty much a default option in software development (finally) - sometimes it's Agile and sometimes "Agile" (in quote marks), but people seem to get the principles (knowing & using is a different thing though) - anyway, there are some common scenarios when you have to take off your agile hat & follow more traditional, waterfall principles - one good example is a co-operation with external companies (by sharing a service or outsourcing some work): they have different agendas, different obligations, live in different environment - a sensible dose of planning, coordination & regular monitoring (sounds like managerial duty...) should be considered.
Names are just names (*shrug*)
Whether you like it or not, you can't scale agile teams indefinitely - Scrum teams are limited to ~9 for a reason. In larger, more complex ventures additional coordination is inevitable - you can find individuals dedicated more or less dedicated to it in all agile scaling approaches: check this website for more details. Whether you want to call them Project Managers or Area Product Owners is really up to you (and doesn't matter a lot TBH) - what is really important is their duty, responsibility & kind of mindset they have to develop.
Manager 2.0 (or 3.0, following Jurgen Appelo's way of thinking) is something different to what we were accustomed for - it's a more subservient role, it doesn't have the hierarchical character it had (between managers & agile teams there's no traditional subordination-based relation) - maybe the word "manager" is just not adequate anymore. But it doesn't mean there's no space for such people.
Quite the contrary.
