Scaled Agile Framework

In December 2015 I earned my Scaled Agile Framework Practitioner certificate. Suffice to say I am a big fan of the Agile Manifesto. The SAFe homepage is a rich source of information and if you google “scrum” or “agile” you will find a host of awesome resources.

But right here I just want to share my takeaways from the training and specifically how it can relate to delivering data analytics projects. Think of it as Anto’s unofficial guide to Agile in no particular order:

  1. Always remember what the fundamental deliverable is: value. We can lose sight of that when we’re down in the weeds of a project.
  2. Write your tests before you code, not after.
  3. Agile is robust and designed to handle the world as it is, not as we would like it to be. However, C-level people often want certainty, i.e. what will be completed when, and this is difficult to deliver in an uncertain world. Do not underestimate the challenge of selling Agile methodology to clients.
  4. Having a constant predictable work velocity is better than having alternate periods of high and low workload.
  5. User stories are not pushed on people, they are pulled down by members of the team. This is a bottom up approach to management, people are empowered to take on work items.
  6. Build good people and they will build good products.
  7. Five Whys: Asking why five times consecutively will often get to the root of a problem.
  8. Clearly define performance metrics upfront. Do not assume that everyone agrees on a definition, make sure stakeholders sign off on it.
  9. Data, like food, has a shelf life. It is better to get interim “good enough” information to stakeholders in a timely manner rather than spend a long time working on the “best” product.
  10. Multitasking is a drag, see here, here and here. Work one story at a time, one sprint at a time.
  11. Quality, scope, time: pick 2 out of the 3. We should always want to maintain high quality. Time can often be rigid due to external stakeholder needs. Scope is the one we sometimes need to adjust.
  12. Timeboxing at every level is important whether it’s planning meetings, scrum meetings or sprints themselves.
  13. There should be one product owner. I know from experience, too many chiefs can really suck.
  14. All activities should have business value and you should be able to explain that value to stakeholders. Even experimental efforts that fail can add value.
  15. Structure user stories like so: As a <…> I want to <…> so that <…>.
  16. User story is not complete without acceptance criteria.
  17. No changing priorities during 2 week sprint.
  18. Leave a little slack in your plan to allow for inevitable unknowns.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s