Agile Coffee 6-6-13

Agile Coffee time/location update

Based on attendence over the last few weeks, we are moving Agile Coffee to once per week.  The new day and time is:

Thursdays at 2:00 pm

NCRC B200 Collab Space (lunch tables area)

Agile Coffee 4-16-13

Agile Coffee 4-9-13

Agile security and compliance

Security is a process, not a product.  In our environment, we are frequently navigating security and compliance waters and it can often be confusing and frustrating.  There is a tendency to inflate security into Big Upfront Design, but it's not necessary   Here's an iterative approach one team is using:

1. Before implementing a new system, do a dry run of the UMHS Compliance Office Security Self-Risk Assessment.  Look for things that we have not considered that could negatively impact security.  
2. Solicit guidance from our security officers on specific risk-mitigation strategies for items identified in the previous step. Implement those strategies.
3. Implement the system and review the Self-Risk Assessment for accuracy.  Have things changed since the first time you filled it out?
4. Review any associated assessments for accuracy.  For example, if you are making changes to a database associated with a web application, review the assessment for the web application as well to see if things have changed.
5. Obtain sign-off from our CIO before moving to production.
6. Move to production and submit the assessment to the compliance office.
7. The compliance office will perform their own audit based on NIST 800-53 standards.  They may recommend changes based on the outcome of their own audit.  

Overcommitment

Overcommitting to work is common in agile teams.  It's just human nature.  Here are some strategies our teams have used to combat it:

• Get to the root cause: Why and how is the team overcommitting?  Do some retrospetives and find out.  Is work coming in the side door, or are we just underestimating the amount of work required to complete the stories we committed to?
• Write good acceptance criteria: Make sure you know what done looks like, and know how you're going to demonstrate the work to your product owner.
• Ground rules: It's often a good idea to publish some ground rules for the team, and a common one is "We won't commit to more work than we were able to deliver in the last iteration."  Solicit buy-in from your team before publishing those rules.
• Treat commitments as a promise: When we make a promise to deliver, and deliver on that promise, everybody wins.  Customers like it the predictability, and teams like the good feeling that comes from living up to your promises.
• Milestones vs. iteration driven: Often we underestimate the amount of time it takes to complete stories that require interaction with external parties.  In those circumstances where you are trying to reach milestones, consider using longer iterations to allow for flexibility in scheduling work with other groups.
• Adjust where necessary: In your retrospectives, try to get the team to commit to one small change. 

Story sizes

What's best - small, medium, or large stories?  As with everything, the answer is "it depends".  In our collective experience, we have found that smaller stories typically have better acceptance criteria.  However, beware of breaking stories down into such small units that you've lost all the business value!  This takes discipline to do right.  

Thin Vertical Slices

Thin vertical slices is a practice some teams adopt.  For a primer on thin vertical slices check out this excellent blog post on the subject

Why are Thin Vertical Slices a good thing?

• They encourage driving towards a minimum viable product.  By delivering a slice of functionality, you are delivering working software!
• Information architecture is done incrementally, with time for feedback and review by customers.  
• By designing top down, or designing the back-end first, we may lay the groundwork for features that are never delivered.  This is waste!
• It focuses on customer value.  Infrastructure is required, but ultimately provides no value to the customer.  Thin slices focus on the features that are meaningful to users of the system.

More on product owners

In our collective experience, the most successful projects had product owners who were engaged with the team and the process.  Alternatively, everyone had horror stories of projects with absent product owners.  How do we more of the former and less of the latter?

• Train new product owners: Spend some time with them, explain your methodology, the PO role, and set clear expectations.
• "Product owner" is not interchangeable with "customer": We often use these two terms interchangeably, but they are truly different roles.  Customers are selfish and design for themselves.  Product owners have a vision in mind and represent the interestes of many customers.
• Product owner, singular: Sometimes democracy is good, but product ownership is not one of those situations.  Someone must have the final say, and committees often have difficulty making a decision.
• Absent product owners: For those projects that do not have clear product owners, we should be seeking them out.  One method could be to stop working and see what happens - if a product owner is out there, they will not be happy and we will hear about it!  If the business wants a project to happen, they will find a way to make someone responsible for it.  If they can't, was it really that important in the first place?

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.  

Agile Coffee 4-2-13

Creative Commons
This blog is now licensed under a Creative Commons Attribution 3.0 license (except where otherwise noted)

Measuring Team Happiness
The first results from the team happiness surveys are on the cork board in the team space.  We've come to a consensus that 3 options are better than 4, but Mark will experiment with 4 options for another week to see what happens.  Further discussion will happen at the PET meeting tomorrow.

Getting the word out about Agile Coffee
Mark will submit a request to put a notification about Agile Coffee in the NCRC newsletter.  We can also use the bulletin boards spread across campus.

"Never put salt in your eyes"
This sketch from The Kids In The Hall is a great example of not learning from your mistakes. Don't mix up your messages, learn from your mistakes, and never, ever put salt in your eyes.

Agile Coffee 3-28-13

Creative Commons?

It was bit of a lonely Agile Coffee today (seems like there was a meeting attracting everyone's attention), so I took the opportunity to give the blog a new header graphic.  I also made other changes to match the University's style guidelines.  

I sourced a Creative Commons licensed coffee cup image for the header, which made me wonder if we should open this blog under a Creative Commons license.  I'm going to send a message over to the Open.Michigan team and see if there a particular license they recommend, and report back at the next Agile Coffee.