Agile Coffee 4-4-13

The role of a Project Manager

What does the role of the Project Engagement Team begin and end?  This question was posed and discussed by the group.  

• Manage Projects - All the typical PM tasks including ensuring the team is living the Michigan Agile Philosophy and that the "pillars" of our work are in place. 
• Block and tackle - Remove obstacles to the team and protect their time.
• We own delivery - Project Managers in charge of delivery (the how and when).  The what and why is owned by our Governance processes.  
• Staff motivation, but not development - Although it is the job of the PM to motivate and inspire our teams, the responsibility for personal development, craftsmanship, and discipline are with functional management.  
• Find the Product Owner - Many IT products serve large audiences, and it is often impossible to find a single product owner with the skills and vision to make a successful project.  Absent product owners is also a big problem on legacy projects.  No straightforward solutions here, but PMs should be raising the flag when Product Owners are missing.
• Many hats -  Sometimes we wear many hats, including Business Analyst and Customer Relationship Manager.  Not ideal, but certainly understandable.  Look for opportunities to make pass these jobs on to others where it makes sense.  

Jira boards for tracking 

Erik is running a scrum board in Jira for a project which involves converting 100+ database jobs from cron jobs to Oracle scheduler.  Each job must be converted, tested, moved to production, and added to a dashboard.  It would be nice to see a big kanban board so we can track our progress.  Erik's question to the group: Is it better to do this in the current Jira project with a different kanban board, or as it's own project?

The group consensus was that both options would involve a fair amount of duplicative work, causing headaches in keeping track of the same information in two places.  Andy suggested making a physical kanban board for tracking the conversion, but write stories to do the actual work in Jira.  That way, the team still has one place to go for their work, but we still get a big information radiator of our progress.  

Lessons learned this week:

• Work on one thing at a time - Mark reported that his team is slowly realizing that multi-tasking is making them slower, not faster.  Making the work visible and limiting work in progress was instrumental in the revelation. 
• Given/when/then - Lauren reported that the advice of using given/when/then in acceptance criteria (discussed last week at Agile Coffee) was working out really well.  It's forced her to think more critically when writing stories, and is also exposing missing functionality in their software.  
• Never miss a high-five - Lauren and Lee shared a tip for never missing a high-five: watch the other person's elbow.  You'll always make contact with a satisfying slap.