Engineering Manager in Agile World!

1. What happens to Engineering Manager in
Agile World?
AN ACTUAL IMPLEMENTATION EXPERIENCE BY NAVEEN INDUSEKHAR

2. What happens to Engineering
Manager in Agile World?
 Asked to leave?
 Asked to take up some other role available elsewhere (or
not available)? Like Release Manager? IT Manager?
 Nothing is done and left as is for Manager to figure out
 Asked to be a developer within the Scrum team which he
did few years back

3. What is the impact?
 Resistance to Agile transformation by Managers
 Demotivated Managers spreading negative energy
 Manager going out takes top talent with him
 Create ambiguity

4. Why is middle management critical
in Agile?
 While teams are empowered and are expected to deliver by
themselves, larger organization have other challenges in terms of
market commitment, adherence to certain standards, shortage of
Product Owners, technical capabilities to take architectural
decisions in the early stages, cross functional / cross team
knowledge, legacy knowledge, etc
 Goal setting and people development are still needed in Agile
world.
 Domain expertize of Managers can’t be replaced.
 There are lot of XP practices like TDD, Continuous Integration,
Automation, Refactoring, Evolutionary Design, etc that need
expertize and who better than middle management to help team in
this direction?

5. Did you already get an answer?
Lets see what we did and how it
worked for us…..
 Scaling Product Owner shortage
 Scaling technical Architect shortage
 Delivering a Program (through Agile teams)
 Engaged Management
 Neutral Scrum Masters
 Cross Functional Skills
 Individual Development Plan, Appraisal and Quarterly goals:
Changes

6. Scaling Product Owner Shortage
 Traditional waterfall teams have 1 Product Manager (mostly remote location) every 60-70
engineers. We need 10 times this number of Product Owners (PO).
 Product Managers continue to do the same role in Agile world ( we didn’t call them Chief
Product Owner), while Managers were given the role of Product Owners. Managers
regained bandwidth of estimating time that was utilized here.
 More importantly Managers had the same Agile teams reporting to them. So team reports
to Product Owner (fully cross functional team).
 Single wring-able neck now has the resource with him to go build what PM wants. PM and
Product owner have to behave as one unit for this to be successful. This was resolved by
continues sync calls.
 PM came up with Epics, while PO and team broke them into stories.
 PO doesn’t use team time for other work since delivery of working software is his
responsibility.

7. Scaling technical Architect
shortage
 While moving Managers to technical Architect role is common, we did that in a
slightly different model.
 Solution Architect role was created for technical Leads and this virtual pool was
managed by technically inclined Manager who played the Architect. For
someone who didn’t wish to go PO path, Manager had this choice.
 Technical Leads were given a growth path of 1 year to become Solution
Architects and they were the SME called up by teams for their projects.
 Typically 2-3 teams shared one Solution Architect, and one Architect having 3-4
Solution Architects with him/her.

8. Delivering a Program
 Managers (as PO) were key in prioritizing program level backlog with other Managers,
PMS and other stakeholders.
 2-Dimensional dependency story mapping was done to track what is needed at
program level, facilitated by an Agile Program Manager.
 Technical skills of Managers came forth in planning for future needs for program like IT,
Localization, Hardware, Budget, Team sizing, Technologies, Resource pooling, release
trains, etc.
 There is no commitment done at this stage with business and that was done purely
based on release planning outcome done with the team. The Program level planning
gave a very high level visibility in terms of how many quarters the project may run into
and what is needed at that level to succeed.

9. Engaged Management
 Exec Management struggles to get visibility through Agile tools like Version One or
Rally or anything one is using.
 Program management report project status, while Manager play the bridge in helping
get this metrics.
 More importantly, as PO, managers are constantly in connect with team and can step
in if team is heading in a wrong direction.
 As the team matures, this engagement will reduce; while there is always scope for
improvement and Manager can help team grow in terms of technical excellence
through improved practices.

10. Neutral Scrum Masters
o With manager being Product Owner, Scrum Master (SM) has to be independent and
not a team member.
o One option was to have a Scrum Master hired for every 2-3 teams (anyways that is a
role that is to be invested in). There is an added advantage of focused Scrum
process keeping in this case.
o Second option is, if an engineer wants to be a Scrum Master, he can be so for a
team he is not developing for. Hence SM doesn’t report to PO.

11. Cross Functional Skills,
team and Manager!
 Initially there was apprehension of reporting structure wherein a Manager doesn’t
have functional skills that a team member has.
 Over period, this was not found to be an issue. There were forums created where
experts in a domain shared knowledge and practices. Example: C++ forum, Testing
group, etc. these forums were driven by expert functional manager in that domain.
 Trainings were arranged to scale cross functional skills by Manager. Career roles like
SDET [Software Development in Testing] was created where black box testers were
encouraged to slowly move into defect fixing, automation, etc.

12. Individual Development Plan,
Appraisal and Quarterly Goals
 Plan is directed more towards team success.
 There are individual goals planned for self aspiring learnings,
innovations, improvements, etc.
 Quarterly goals has a 360 degree feedback mechanism. Team members rate their
peers, while Product Owners rate the team. Product Owners in turn are rated by their
own teams, Management and Product Managers. Scrum Masters provide generic
feedback. 70% of goals come from team success.
 Annual appraisal is also tied majorly to team success and partially individual goal
achievement. ‘Logging more defects as a tester giving a goody’ sort of goals are no
longer existent. Product having 70% unit test coverage is the sort of goal set now.

13. What about aspiring Leads from
Waterfall World?
 Some of them stepped into Solution Architect role (tech track)
 Most of them head a track (about 30%) in addition to the team they
are working with. Tracks like implementing Continuous Integration,
Automation, TDD, Refactoring, Exploratory Testing, Design Principles in
Agile, Code Reviews, Security Testing, etc
 Agile enthusiasts took the path of Scrum Masters, Mentors, Trainers,
and local Agile Coaches.
 Some others took to becoming Product Owners, mentoring new
joinees, etc, heading towards Manager roles.
 Few interested people moved to newer domains like Devops, System
Integration, Release Team, etc as Technical Leads.

14. Email: Naveen.Indusekhar@gmail.com