Project Manager Interviews

1. A/B Testing  -Existing production deployment; how do you plan an upgrade deployment without downtime?
2. SSO Testing with AD federation – ? P
3. Business Continuity  (GAP analysis)
4. Task Estimation – What tools? How do differentiate between deliverables around 2 different end users (internal claims processors, who do 1000 claims per day ) and external users (1 claim per day)
5. Production Bug – And requirements traceability matrix – describe how you would trace a production defect back to the root cause
6. Traceability – Code Quality  and Unit Tests ; Traceability
7. Scope Creep  – How do you deal with it?
8. Selling the cloud to customers – expectation of 1 week, reality is 6 months. How would you deal with both sides?
9. Agile versus Waterfall; XP vs Scrum,  Scrum vs Kanban
10. Project Velocity
11. Defects per release and compare to Code Test Coverage
12. What are some of the metrics you use around agile projects? Which ones have worked and which ones haven’tfa

XP (Pair programming and unit testing = code refactoring) versus Scrum – Scrum – A Fundamental Shift

Scrum is a well-defined process framework for structuring your work. Introducing Scrum is quite a change for a team not used to agile software development: They have to start working in iterations, build cross-functional teams, appoint a product owner and a Scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits of the Scrum methodology are well understood: Less superfluous specifications and fewer handovers due to cross-functional teams and more flexibility in roadmap planning due to short sprints. Switching your organization to use Scrum is a fundamental shift which will shake up old habits and transform them into more effective ones.

Business Continuity – How does Project Management Help?

• GAP analysis (for emergency response etc..)

Scrum Leverages Commitment As Change Agent

The initial introduction of Scrum is not an end in itself. Working with Scrum you want to change your teams’ habits: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motivated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.

Scrum versus Kanban – Incremental Improvements

The Kanban methodology is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum  ). In Kanban, you organize your work on a Kanban board. The board has states as columns, which every work item passes through – from left to right. You pull your work items along through the in progress, testing, ready for release, and released columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. By managing WIP you can optimize flow of work items. Besides visualizing work on a Kanban board and monitoring WIP, nothing else needs to be changed to get started with Kanban.

Kanban Leverages Work In Progress (WIP) Limits as Change Agent

Sprint Burndown and Scope Creep

• The team finishes early sprint after sprint because they aren’t committing to enough work. 
• The team misses their forecast sprint after sprint because they’re committing to too much work.

Scope creep” is the injection of more requirements into a previously-defined project. For example, if the team is delivering a new website for the company, scope creep would be asking for new features after the initial requirements had been sketched out. While tolerating scope creep during a sprint is bad practice, scope change within epics and versions is a natural consequence of agile development.

Project Velocity

Let’s say the product owner wants to complete 500 story points in the backlog. We know that the development team generally completes 50 story points per iteration. The product owner can reasonably assume the team will need 10 iterations (give or take) to complete the required work.

It’s important to monitor how velocity evolves over time. New teams can expect to see an increase in velocity as the team optimizes relationships and the work process. Existing teams can track their velocity to ensure consistent performance over time, and can confirm that a