Rusty Divine

Live, Love, Learn, Teach

Defining the Slides for my Agile Requirements Gathering Talk

Previously, I outlined my talk into seven six-minute sections, with a three-minute intro and outro. That’s 48 minutes, which is good, but I found out that the talk is supposed to be 45 minutes and I’d rather leave time to have a question or two at the end than run over. If I did seven five-minute sections, it would work out a bit better.

This revelation hasn’t affected my outline - I haven’t cut out any of the points yet. I feel like there is still too much there, and some of it may not support my main idea of showing the audience how we did this type of assessment, but I’m more comfortable risking developing slides and notes that I’ll later cut out than pre-optimizing the talk.

I have a theme chosen for the slides (one of the default themes for PowerPoint 2013), and my working list of slides is:

title_slide_mvp

  1. p0  Title Slide
  2. p1,2 The old way (how it used to be)
  3. p1,2  Idea vs. Problem (what it works well for, and doesn’t)
  4. p3  How to sell it to stakeholders (both $ and rationale)
  5. p3  Preparation for the meeting
  6. p4  Where’s the Fruit (idea of the app we’ll walk through)
  7. p4  Assessment Agenda (describe different parts)
  8. p5  User Stories (how to collect and record)
  9. p5  WTF’s example stories
  10. p5  Constraints & Assumptions
  11. p6  Getting priority & CFS/MVP agreement
  12. p6  Whew. Retro time
  13. p7  Checklist of what’s left to do
  14. p7  Running a project (burn down/agile)
  15. p8  Thanks, contact info, questions

Fifteen slides at an average of three minutes per slide seems about right to me. Adam had an interesting suggestion – he wondered if assigning planning poker points to each section would help estimate how big that section was. I think this could work for the slides, too.

Next: design the slides. I’d like to include some animation (content coming in/out of a slide) and stock photography balanced with my main points in text. I’d like to stay pretty light on text and try to focus on things that will grab the audience’s attention and keep it. I’d like to try throwing something into the middle that breaks the norm to keep them engaged. Around slide 8, the half-way-point, I’ll ask for a little audience participation to suggest a user story for WTF – I’ll need to be careful to time box that experiment so that I don’t run over.

Outline for Upcoming Talk on Getting to Minimum Viable Product (MVP)

On the last Saturday of March, I’ll be giving a talk at Nebraska Code Camp titled, “An Agile Requirements Gathering Process to get to MVP.” My progress will be shared here on this blog, and ultimately, the slides and maybe even a video of my presentation will be available.

The talk covers the experience Keil, Adam, and I had using a requirements gathering process we adapted. The big idea is:

An agile assessment process can help stakeholders define and agree on the vision for a project, the most important features and their priorities, and help prevent developing something that strays off target.

I want each slide in the presentation to support that idea if it can so that the message sticks. Having the one big point to make helps me determine how to prune and focus the talk.

7 sheets of paper * 6 mins per sheet is a great way to plan a talk. Hat-tip @shanselman, @john_papa, @pluralsightI started out with a stack of sticky notes, each with its own thought. Next, I decided that if I divided the presentation into seven six-minute talks, plus an introduction and conclusion, then I could more easily determine how to pace the talk and define its structure. I took seven sheets of paper, and organized the sticky notes onto them.

Today I took each page and thought about the main reason for each, then created an outline with notes about the ideas I had. I started combining and separating the notes on different pages, moving them around, and identifying some I hadn’t thought of.

The outline is posted below so that Keil and Adam, or anyone really, can comment on it and help me to clarify it. I feel like I have too much content here, so using the big idea above for reference, I should be able to pull some out – for instance, talking about how to sell an assessment while handy doesn’t really support the big idea. I’ve left that in for now to help show the process.

I want to include as much showing of the process as opposed to telling about it as possible, so I am going to be walking through the assessment of an app called “Where’s the Fruit” (WTF). Adam and I have already done an assessment on this app, which we did to help show off the process to potential customers.

I’ve been using the Pomodoro technique (just the timer) while working on this presentation, and that’s really helped me focus. My next step will be to start creating the slide deck using some tips from Pluralsight (John & Scott), Scott Adams, and Rexi Media.

Part 0 - Intro

- Introduction, welcome

- Talk about what’s in it for the audience (story/reward), provoke curiosity

- brief overview

Part 1&2 - Answer Why

- Story of how we were doing things before this method. Good and bad. Ask audience if they've can relate.

     - Tell me how much this project will cost after this 30min meeting; book review analogy

     - There is no such thing as a simple app

- Story of how we learned about this process from someone in our peer group.

- Why it works for consulting projects

     - Balance between full agile and waterfall; a middle-ground for establishing trust

     - Weed out customers who won't even pay for the requirements gathering. Story of D.S..

      - Client/Stakeholder empowerment through driving the requirements  

     - Budgeting needs

          - Fixed price vs. T&M

- What does it not work well for

     - "I have a problem"

     - Migrating one system to another

     - Integrating one system to another

- What does it work well for

     - "I have an idea"

     - greenfield

     - Getting multiple stakeholders to agree on the vision and priority. Need as many stakeholders in the room as possible, and devs, too, so they can get in on the vision from the ground floor.

     - Getting the core feature set determined (aka mvp)

Part 3 - Selling & Preparation

- Simple to sell a fixed-price product vs a T&M project

- This process, or something like it, is something we have to do anyway. We're just pulling it out and putting it in front.

- Gives customer a chance to work with us with a small risk

     - At the end of the assessment, they can take it and shop it around or continue with us

- We don't validate the business idea, but could give them some feed back as a SWOT

- Consider having a plan for handling conflict between stakeholders and practicing.

- To prepare

     - Send customer information about the process and what to bring and what to expect. The more work they put in up front, the better.

     - Setup the room, preferably one that is very large and has a large white board or two or wall board paint

     - Put the agenda and rules up

     - refreshments and name cards ready

     - sticky notes for story titles

     - One note taker, one facilitator

     - Try to do between meals

Part 4 - Getting Started

- We are going to walk through a mock product - where's the fruit

- We don’t know the budget or schedule, customers don’t like to tell us that up front (trust)

- Talk through the agenda

     - Never feels like enough time, but we make due

- Define the objective

     - what makes a good objective

          - SMART, derived from narrative, like an epoch; could have a so that

     - edit it as needed throughout the day

     - WTF's objective revealed and dissected

- Users and Roles

     - Admin users

     - end users of different types (don't get too stuck on these)

     - system integrations

     - report users

     - these become the actors in the user stories and can provide a check point during the meeting to see if we've captured the main stories for each user

Part 5 - User Stories

- User stories format

     - format of a user story

     - why the so that is so important

     - look out for circular reasoning

     - conditions of acceptance

     - consider admin tasks; back-end user & data management

     - consider the long haul; archiving, cleaning, moderating, reporting

     - have customer describe the workflow they envision as if they were sitting down to use the app

     - easy to overlook stories about security, exports, logging, reporting - some of these can be added in after the assessment during the research

- User story examples

     - WTF's examples

     - Get the audience to throw one out

- Write down constraints and assumptions as they come out

     - show WTF's examples

- Diagram and mockup as necessary, but beware of spending a lot of time there

Part 6 - Defining the core feature set

- Good time for a break to get people's mind a rest

- Put all the sticky notes of feature titles onto the wall

- Have stakeholders take turns organizing them into what is most important first

     - guidance is needed to give them context

     - Importance does not equal darling

     - Which feature is more important than another in context of having a functioning application

     - Can't put stories at the same level; can nest them if they really are related, but otherwise have to decide if one of these stories wouldn't get done, which one would I rather get done

- After everyone is satisfied, it's time to draw the core feature set line

     - Sometimes this is hard for customers who want it all

     - We need to determine what has to be there for the system to stand up on its own

     - We can and should add more later; priorities will shift, new ideas gained, old ones discarded.

     - What we find is the target has moved by the time we get that small set finished, so aiming to do more than that will often waste time, effort, money.

- That's a wrap. Now, we're all exhausted and don't plan on doing anything else productive.

- One more thing to do - a meeting retro. We did this without the customers sometimes and with them sometimes.

Part 7 - Post Assessment

- Off-the-shelf research - is anyone else already doing this; can we integrate?

- How we point stories

     - filling in any missing stories

- Assembling deliverable

     - creating some mockups, workflow sketches

     - tools: PowerPoint w/mockups,

     - lean canvas and/or SWOT

     - Proposal with fixed price, first available start date, stories and their sizes down to CFS

          - project scope & price is more about sum of user points; customer can swap in/out stories as long as total points are same

     - how to convert points to dollars

- Running a project

     - two-week iterations, burn down, daily stand up with customer, demo/retro, customer prioritizes and manages scope, change requests

Outro

- You can use this process for your own ideas, or for customers

- It is a great way to brainstorm features, get agreement among stake holders, and get everyone in the room on the same vision

- Get the slides and more information from my blog, and feel free to contact me

- Questions?

Effective Scrum and High Quality Code – LNK .Net Talk by Rod Clarr

Tonight Scrum Master Trainer Rod Clarr presented at the Lincoln .Net User Group on Scrum and High Quality Code. The main point he made was that agility and high-quality code need to go hand-in-hand; developers need to produce the highest quality code they can.

Rod walked us through how to measure quality from different angles. From a functional standpoint – does the product perform as expected – quality is easy to test if you have done a good job defining what the product should do. From a structural stand point, it may not be obvious how to determine what quality code is, but poor quality code does rot faster, especially when it does not have unit tests.

Rod described two concepts to help qualitatively evaluate the quality of code from a structural standpoint:

  1. Viscosity – how hard is it to move the project in a different direction by adding or changing a feature. The more viscous, the more rigid, the worse the structural quality is.
  2. Testability – how difficult is it to write automated tests for the product – the more difficult, or the less coverage you can achieve, the worse the structural quality is. A project needs to have good quality before it gets to QA-style testing; by that point it is likely too late to improve structural quality.

Rod also talked about the sweet spot of the intersection between Scrum, Acceptance Test-Driven Design, and Component-based Architecture. Scrum is the process to manage risk in the process, ATTD is the top-down approach to defining what done is, and Architecture is the bottom-up test-driven development that results in good OO-based design.

Most of what Rod talked about resonated with my experiences. We’re currently focused on moving a number of iterations worth of work to production so that users can validate the progress we’ve made – the longer we wait to get to production, the more risk we incur in assumptions that we may have made that won’t be revealed to be wrong until users really pound on the code.

We also need to include more technical debt stories as we go; which Rod talked about as being important, or at least, not adding more technical debt knowingly. Our team has discussed adding two technical debt iterations per year, but I wonder if a better approach might be to allocate a number of story points per iteration to beat back technical debt.

Rod talked about getting the whole organization on board with the importance of quality and the Scrum process. Keil commented about this after the meeting, and I totally agree, that it is a very different thing for management to be OK with a project being run in an agile process versus management running their own process in an agile way (the latter being the much less risky option of the two).

Finally, Rod talked about the importance of feed back loops in requirements gathering. The first thing you need to do is confirm you understand what the customer is asking for, and then ask questions. We have started doing a better job of this on our team by creating good meeting notes to record decisions made (which have proven very valuable to refer back to), and by adding conditions of acceptance to all of our user stories to help us define and agree on what done is.

An Agile Principle for Hobby Software

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"

That's the first of the twelve agile principles, and arguably the only one that stands heads-and-shoulders above the rest. The other eleven principles could be described as a mix of technical and practical guidelines with more or less the same importance as their neighbors.

The principles are targeted, yet generic at once in order to accommodate the various modes of software development. They are flexible enough to help us make decisions when building enterprise software, commercial software, open source software, line of business software, or hobby software.

The principles help guide decisions, but are there extreme environments where they begin to break down? What happens when a project's velocity, the number of features that can be produced in a set period of time, trends towards zero or grows towards infinity? Do some of the principles become more important than others? Do any principles become irrelevant, essentially falling off the list?

One could imagine other environmental extremes that may also affect the principles, like writing software without a customer in mind, writing software that no one will ever use, writing software with extremely short or expansive deadlines, software that is incredibly small or large, and  writing software where there is an absence or abundance of trust, just to name a few.

The disc golf app that Adam and I have been working on has been a bit challenging to manage with the agile process because our velocity so so low - we are doing good when we are able to dedicate 6 hours a week each to the project. Based on the few agile teams I've been on and their average hours-to-points (I know, that conversion can make a scrum master pucker) that could yield a 10-to-15 point velocity at a one-month iteration. It would be common for teams to do 70 points in an iteration of two or three weeks, so 10 points in a month is like a turtle's pace.

Our first iteration, which was the month of November, was just two stories. I set up the architecture and Adam did some user interface design and mockups. I don't think either of us were ready to close out our stories, so we probably didn't even burn down.

With a velocity so low, I argued that we shouldn't task out our stories. I didn't want to allocate time to think about breaking out our user stories into hourly tasks like we would normally. Our process was starting to bend to our new circumstances, but I think that's OK considering two important tenants of the agile philosophy: 1) Do only the what you need to get well designed, working software delivered, and 2) Use the periodic evaluation of what went well, what could have been better, and how you are going to improve to tweak your process.

After our first iteration, we decided that we did need to put a little pressure on ourselves in the form of a goal to strive for. Each year in February there is a tournament here in Lincoln called the Ice Bowl where you play no matter the weather conditions. You may need snow shoes or chemical heating packets in your shoes and extras in your mittens, but you play. We are going to have a working scorecard for the 2014 Ice Bowl. It will give us something to work towards and help us follow the simplicity principle - only do what is necessary, no more.

Our scrum master friend and sometimes boss Keil wondered at my use of the term "near-zero-velocity" when talking about our starting to abandon parts of our process. He wrote, "it makes me wonder what the point of any project is if you aren't willing or able to put more effort into it than is necessary to keep it on life support. Assuming we never have enough time to get it all done, does it make sense to say we're 'working' on a project where we never make progress towards completion? Maybe we should just shelve the project for a later time when it becomes a higher priority than the other attention grabbers that surround us."

I wonder if he'll be right or not, if we'll end up shelving this project because of lack of momentum. With family and work, it's hard to stick to a system of working on a side project. Adam and I both have young children that we don't want to sacrifice our family time with to spend time on this project. On the other hand, we both need an outlet for trying new technologies because we are both, at separate jobs, working with code that is several years old. If we want to stay fresh, we have to find a project to work on outside of 8-to-5. My primary reason for working on the Disc Golf App is to learn new technologies, build my portfolio, and share ideas via blog posts to help other developers looking to learn. I told Keil that even if this app never gets finished, I will consider it a success if I can use it to learn some new tricks and share them with the community. It is a principle that falls outside of the agile principles, but it trumps the twelve other principles for me for this project:

Strive to hone your craft by learning and applying new techniques and sharing that knowledge with others so that they may benefit.

Agile Principles Exercise

Earlier this week our project manager, Keil, asked us to review the Agile Principles and pick one that we felt was most important to our project at this time, then justify our choice. We emailed him our results without talking to each other.

Today the development team (9 of us, including Keil) met to talk about what everyone picked. Our choices were scattered, but our rationales converged on the importance of getting working software in front of the end users to get quick feedback and promote trust between our two groups.

It was interesting that similar justifications could be made for so many of the different principles. Keil then showed the responses from the end users* and there was only some overlap with their choices, and their rationale converged on the importance of trust between our two groups – trusting us to deliver quality and expected functionality.

One of the dev team remarked that the end users’ chosen principles were less technically focused overall than the developers. I hadn’t realized it, but some of the principles do seem to be more technically focused while others are people-or-process-focused.

The only principle that more than one of the devs picked, “Simplicity--the art of maximizing the amount of work not done--is essential,” was not chosen by any of the end users. Coincidentally, we’re currently hashing out a new feature request from the end users that the dev team feels may be over-complicated while the end users are persistent in the request for it. There’s a related post about this on Keil’s blog.

I’ve been thinking about the agile principles and how to apply them to the disc golf app Adam and I are working on. It’s been a struggle to tailor the process that is appropriate for a project where we can apply 8 hours a week between us to it. I’ll post something on that later, along with some of the input Keil has on what we’re doing now.

 

*We’re fortunate to be able to work with our end users every day because they are directly down the hall from us, so getting feed back is very quick and relatively easy for our team.