Outgrowing Our Process

A question was posted on reddit

My brother just hired me on to help with the admin side of his 4-person construction company. We do a lot of subcontracting, and we use Trello to organize who is hired to do which job and where. For the most part, this system works great, however because of the amount of work we are getting, it’s starting to feel a little clunky. SO…

I’m looking for an alternative program. I love how simple and user friendly Trello is. But it would be great to add a calendar, a “contact” page, maybe even sync my current excel sheets contact list.

Any recommendations?? Thanks!

You could try finding ready-made commercial packages for your industry and business size.

You can try to see if Trello can be configured to better meet your needs. And to do that you might need to spend a handful of hours doing a bit of lightweight documenting, conversations, brainstorming as I describe below:

You are already starting off on a good foot by being curious if there is a way to improve how you are currently working in terms of process and tools.

Things like Trello and Jira are glorified to-do lists. Especially useful for accessing 24×7 and remotely. They are also generic as hell. Not a care in the world for what industry you are in (well, Jira might have some hints of being a software issue tracker).

I would recommend continuing to capture just enough of your needs (aka, requirements as you have begun to articulate herein). Also, it is important to capture the pains that you are currently experiencing. And maybe jotting down potential gains you could see; e,g,, “if only X were possible.”

That is, do not merely settle for finding a new tool. Maybe it is time to also step back and ask yourselves where you are headed. What is our current way of working, pains and all, and what might we want to shape for our future way of working?

Suggestion: Grab a handful of your team (and maybe some trusted sub-contractors) that know how you work and are interested in finding a better way, and consider doing something like this:

  • Capture a high-level view of your CURRENT process… from intake (work order) to cash (i.e., accounts receivable)
  • Get a large whiteboard — 4’x8′ for example,
    • plenty of pastel-colored post-it notes and black markers
    • Get some whiteboard markers
  • Put INTAKE (Start) at the left, and CASH (End) on the right
  • Get the coffee and donuts going, or beers and brats… hand out sticky pads and thick markers
  • Set a timer to work in 15-min chunks, for example, and step back and discuss.
  • Encourage people to start filling in the details between START and END
    • Different people might know different parts of the process
  • Use simple ideas (do not write a novel on a sticky)
    • Work order arrives
    • Acknowledge receipt
    • Triage new orders
      • Needs estimate
      • Estimated
      • Estimate sent to customer
      • etc.
  • Along the way, as people are contributing to building this “flow chart” be sure to jot down things that really suck — because believe me, folks will moan and groan when they hit parts of the process
    • I like to write down PAINS on pink (a shade of red) stickies so it is easy to see and ponder
    • “Work items getting lost in the shuffle”
    • “Management by text message sucks”
  • Also, track when “reverse flows” happen (and how often) — for example,
    • having to do rework
    • estimate needs another pass
    • quality problem
    • customer rejected the work
    • shit, a request fell through the cracks
    • etc.

FUTURE PROCESS

  • You might want to tweak how you currently work to address pain points
  • You can do this as you dream up a more ideal way of working
  • You might need the OTHER side of the whiteboard — if it was one of those on rollers 😉

You could do this over a few meetings… let it stay up in the office and ponder it over lunch for a week or so.

This process gets the entire team on board with owning this problem. Or at least participating and building a shared understanding.

You might even be shocked at how much you can accomplish with a manual system — at least for parts of your process. After all, companies were successful before computers.

If you do not know what your process should look like manually, you might just find yourselves being driven by the biases inherent in a tool that you expect to solve your problem. Some tools might be perfect for your industry, and might even show you good “default” ways to start out because they are built off of the backs of real people using them to solve needs similar to yours. And other tools could lead you to ruin.

If I had to guess you will end up with some high-level bits of the process that emerge that could map to a set of simple lists and a set of steps within each.

  • Intake Processing (including no-bids)
  • Job Preparation
  • Work in Progress
  • Work in Review
  • Invoicing/Accounts Receivable

Once you see the types of things you need to do from the exercise above, you could:

  • Look for a product for your type of construction work (though they might all be bloated and geared towards larger companies)
  • Try some simple ways to create a process flow in something like Jira or even Trello now that you have a handle on what a better way of working could look like

Might even be worth paying someone to help guide you to finding/creating a solution that meets your needs. Because it is easy for me to see how to force a tool like Trello or Jira into behaving for a specific need, but that’s after decades of experience.

It’s a great opportunity to put a bit of effort into learning how to find new ways to work. Because you should do it as often as needed.

 

Do You Really Need Story Points?

To the Point

Instead of wasting time estimating story points, spend that precious time understanding the requirements. Figure out how to break them down into smaller and more valuable stories, and deliver less volume and higher impact.

Base all of your work and planning around small stories. Your predictability will increase. Your customers will get more frequent deliveries of truly valuable functionality. And you will have an overall happier and more engaged development team.

What do Story Points Provide Your Team?

If you are using story points:

  • Did you ever ask why?
  • Did you ever track the accuracy?
  • Or ever track the consistency of story points to any other metric?
  • Have you ever considered the effort required to guess at the story points?
  • What is the return on investment of the time spent generating a guess of dubious accuracy?
  • Do customers ask for Story Points?

The primary reason that Ron Jeffries and the XP team pivoted from estimating in ideal hours or ideal days was because of the confusion this practice caused. The unit of measure was well understood by business people. But the concept of “ideal days” was not. So turning to a made-up value and calling it “points” was a way to discourage the business folks from wondering how a three-(ideal)day effort required a week of calendar time.

Though Scrum does not dictate using Story Points, it seems everybody does so.

The Problems with Story Points

The problems I see with Story Points

  • The fact that people use numbers gives an illusion of “we know what we are doing, we have a precise metric.” No matter if you pull out the “but we are using a Fibonacci sequence” – that just exaggerates the degree of imprecision.
  • No two teams – maybe, even, no two people – have the same Story Point “Ruler.”
    • Yes, I know we can pick a well-known story as a 1 pointer and do relative sizing…
    • And I know we can work to make all teams estimate story points the same way. Hogwash.
  • The activity rarely (never?) reduces the scope
  • Estimation is usually coupled with a capacity planning session, further deepening the impact of imprecision on the overall process
  • The ceremonies around estimation sessions often miss the point – we are here to understand what needs to be delivered to the user.
    • Instead, the Scrum Master diligently asks for Story Point estimates for the story as written in Jira (because the business is too busy)
      • They get (3,3,3,3,5,5,5) from the team members.
      • They then proceed to ask one of the low number people (a 3) to defend their score, and one with the high number (a 5) to defend their score.
      • Once again the dogmatic ceremonies deliver low-value results
    • Yes, I know there are anecdotes of well-run ceremonies
  • NEWS FLASH – you still need to break down the work into meaningful, smaller features. Or at least you should.

A No Story Point Strategy

I have a different strategy.

We deliver features (aka, stories) that customers value. No customer is asking for more story points.

It is better to expend the “story-pointing” energy in breaking down the stories into smaller features. Along the way, we even learn more about the actual needs of the users, and we can frequently find ways to produce more value for less effort by cutting or delaying scope. We do this by bringing the business/subject matter experts, QA, development, and UX, into the conversations. We collaborate to deliver the highest value issues for the least effort. We use story mapping to help defer scope to later releases (or never).

We track completed features delivered.

It turns out to be a pretty stable metric over time – if you maintain the discipline.

If you also track the features you want to build for a given version release (as shown in the graphic), you can get a pretty good handle on time ranges.

(Ab)Using Jira Story Points

I have abused the Story Point field in Jira by setting it up as a signal to the team about simplicity:

  • 1 – super easy, maybe a day or two of work
  • 2 – A bit more complicated, could be a few days, maybe 4
  • 3 – these are never allowed to last long; they must be broken down! They can never be pulled into the “selected for development” column.

The reason I put simplistic values in the field is to allow us to get some Jira reports that use Story Points.

For example, look how we can guess when the release date will be for the set of issues!

Freedom

Try out the strategy of breaking down all features into small, client-valued stories, Make all issues a 1 or a 2 pointer.

If you aren’t reducing (or delaying) scope along the way, you might be doing it wrong.

Remove the ceremonies around story points and base all of your predictions on issues delivered.

Hard to Capture Fluid Agile Practices in a Static Graph

Well, this is sort of what I like to do on software development projects…

I feel like there are some necessary startup processes to get you up and running quickly with a glimpse or vision of the product/end goal. And then some set of similar, or refined,  or slightly modified practices that carry on during the life of the main product development period. I liken it to getting the skeleton up and running, or the “tree trunk and main branches” upon which we can rapidly build out the app.

This was part of a “Day of Agile” immersion course where the attendees step through a mock development project…

PDF: Iterative Development Path Agenda.

PNG: Iterative Development Path

 

So You Wanna Try Agile?

Well, in a nutshelll, agile is a state of mind.
Agile is relative.
Agile is not dogmatic.
Agile is pragmatic.

Agile is designed to reduce the gap in time between doing something, and seeing a result that you can “measure.”

Blend in Lean concepts.
Read The Goal.
Don’t do giant monolithic things.
Learn how to decompose your “features/expected outcomes” into bite-size chunks.
Don’t plan across a far horizon to the same degree.
What folks are tasked with doing today better be clear and have unambiguous meaning of “DONE”
What folks are tasked with doing in 2 months better be rather nebulous and broad.

Don’t be complacent and relax.
Question the value of deliverables that are needed to fulfill some process step for some other team.
Ask any downstream recipient what they truly need — and why.
Try new processes.
Reflect.
Agile takes constant effort and constant partial attention if you are doing it right.
Be holistic.

Prefer Explicit Cucumber Tests

Leave a reply

An Inexact Test

Innocently enough, one of our developers added this feature, which passes:

  Scenario: Create Field
    When I manage the "acme" org
    And I go to the user field management list for "acme"
    And I click "New"
    And I set the following values
      | Name     | Test Field |
      | Required | true       |
    And I click the "Create" button
    Then I should see "Test Field"
    And I should see "test_field"
    And I should see "Yes"

Note: for now I am not going to discuss the other improvements that could be done with this feature (e.g., to remove the “click” steps).

Unfortunately, the actual page looked as follows (using save and open page):

Name        Required?  Key 	
First name  Yes        first_name
Last name   Yes        last_name
Test Field  No         test_field

Sure enough, the text “Yes” was indeed on the page, given the step was defined simply as shown below. However, the intent of the test was actually not correctly followed in the code.

Then(/^I should see "(.*?)"$/) do |text|
  expect(page).to have_text(text)
end

An Explicit Test

So one way to ensure the proper data appears in the proper place on the page, especially when it is in a table, is to do the following.

Add an ID to the page location:

    %table
      %thead
        %tr
          %th.text-center Name
          %th.text-center Required?
          %th.text-center Key
          %th.text-center
      %tbody
        - user_fields.each do |field|
          %tr{id: dom_id(field)}
            %td.text-center= field.name
            %td.text-center
              -if field.required
                Yes
              -else
                No
            %td.text-center= field.key

Change the feature to expect the text exists in the context of the record:

  Scenario: Create New Field
    Given I follow "User Fields" in the sidebar
    And I follow "New Field"
    And I set the following values
      | Name     | Zodiac Sign |
      | Required | true        |
    And I click the "Create" button
    And I should see the following user field:
      | name        | required | key         |
      | Zodiac Sign | Yes      | zodiac_sign |

And define a step something like this:

Then(/^I should see the following user field:$/) do |table|
  # table is a table.hashes.keys # => [:name, :required, :key]
  field = UserField.find_by(name: field_name)
  dom_id = "user_field_#{field._id}"
  table.hashes.each do |row|
    dom_id = dom_id_for_field(row[:name])
    within("tr##{dom_id}") do
      expect(page).to have_text(row[:key])
      expect(page).to have_text(row[:required])
    end
  end
end

Test Your Test!

I also like to check my tests! That is, go to the code where the text “Yes” is defined, and change it to something else. If your tests still pass, you know your test is flawed!

Summary

By adding a “findable” id to the output, you can more exclusively assert some text is on the page in the correct location!

Other approaches

  • ensure you eliminate the other non-essential elements from the page, so there are no “false positives”
  • Check for a very bizarre string that will not accidentally appear, like “Zebra Fangs”

 

User Stories and FDD

FDD?

I bet you never heard of Feature-Driven Development, eh?

Well, Mike Cohn wrote this recent post:

Not Everything Needs to Be a User Story: Using FDD Features

Having worked with Peter Coad since the early 90s, and Jeff De Luca in the late 90s, I’ve been a fan of FDD and naturally turn to that style when “user stories” are not so user-centric. And yes, those are typically the minority items on our backlogs.

Software development is working through a prioritized to-do list. Most of the to-dos should be about addressing user needs. Call them user stories, call them features, maybe even call them requirements. Whatever works best to help you organize and communicate what needs to be built.

Another element of FDD is breaking down (or building up) the system into

  • Major Feature Sets (Quote Management), and their
    • Feature Sets (Clone Quotes, Create Quotation Documents), and their
      • Features (create a quote, edit a quote, archive a quote).

Major Feature Sets might loosely equate to epics 🙂

One of the keys to successful software development, is to combine the list of features with a domain model (and some UI mockups don’t hurt). The domain model need not be to the nth degree of UML detail. But one that clearly describes — in just enough detail — what your problem domain is all about. This eliminates the need to write all sorts of detail in the development issues, leaving that to the model. Then the feature list become more about the order in which we are building up various aspects of the product feature sets.

Thanks for paying a bit of homage to FDD. A blast from the past!

Zurb Magellan Navigation

Love the Zurb Foundation stuff. Love that they freely open-source these cool tools and provide documentation to the community. So, it is hard to complain about “free.” But, in the spirit of community, I think our frustration is often due to being excited about trying out a new, cool, thing, and getting bummed out when running into small roadblocks. (Especially for me, a hacker, who is not really qualified to jump in and discover some crazy cascading javascript or CSS explanation for the odd behavior.)

The disjointed and terse example on the Magellan docs page does leave one asking for more details.

Disjointed example:

  • Arrivals (build, js)
  • Destinations (arrival, destination)
   
  
Arrival

  
  
Destination

I had a great deal of trouble to get the nesting correct on my page that also included the topbar element. There seemed to be conflicts with having the topbar being contain-to-grid and fixed.

From what I have gleaned by looking at the page source and doing a lot of trial and error (:boom:), I got something to work “good enough” (as I got tired of the trial and error):

  • In one div, define the arrivals
  • Later in the page, define the matching destinations
  • And fiddle around with divs, nesting, classes, until it works the way you like

An example in haml (sorry for not doing it in HTML, but this is ripped from an app I am writing — modified slightly for this post):

- structure_elements = %w(Access Interior Roof Shutoff Drain FloorPlan SiteDetails)
- structure = @structure

%div{"data-magellan-expedition" => "fixed"}
  %dl.sub-nav
    - structure_elements.each do |element|
      %dd{"data-magellan-arrival" => element}
        = link_to element, "##{element}"
%article#structure
  %h4
    = link_to structure.name, edit_structure_path(structure)
    = link_to fa_icon('pencil'), edit_structure_path(structure)
%hr
= render partial: 'photos/photos', locals: {context: structure, preplan: preplan}
- structure_elements.each do |element|
  %a{name: element}
  %h3{"data-magellan-destination" => element}
    = element
  %div.panel
    ="#{Faker::Lorem.paragraphs(3).join(' ')}"

I hope this helps :heart_eyes_cat:

 

 

Kaminari Paging and Zurb Foundation

I am using Kaminari paging gem and Zurb Foundation 5, and here is what I did to make them work together in HAML fashion:

If you generate the theme (it might not matter which one), for example:

rails g kaminari:views bootstrap

You can see all of the “machinery” in the viewskaminari folder. Here is my “hack” to get Foundations Pagination working with Kaminari:

I tweaked _paginator.html.haml to reflect the Foundation class on the %ul tag:

= paginator.render do
  %ul.pagination
  ...

And I tweaked _page.html.haml to reflect Foundations current class (instead of Kaminari’s active class):

%li{class: "#{'current' if page.current?}"}

And then it just worked!

Kaminari and Foundation Paging

Kaminari and Foundation Paging