What happens to engineering manager in agile world
Download as PPTX, PDF•5 likes•4,594 views
The document discusses how engineering managers can adapt to an agile work environment. It describes how one company addressed common challenges like product owner and architect shortages by having managers take on those roles. Managers were also given responsibilities like goal setting, cross-team knowledge sharing, and helping teams improve practices. This engaged managers in delivery while addressing skills gaps. The company also emphasized team success for performance reviews and career goals over individual metrics. This helped managers and other leads transition successfully to agile.
![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.](https://image.slidesharecdn.com/whathappenstoengineeringmanagerinagileworld-141014065206-conversion-gate02/85/What-happens-to-engineering-manager-in-agile-world-11-320.jpg)
What happens to 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.