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?