Category Archives: Project Management

Perhaps you’ve heard of Feature Flags, maybe you haven’t. What is a flag? What do they solve?

We value low stress deploys that are independent of feature launching. We value working in small batches enables us as a team to be agile to priority changes.
We value these things so that we may continuously delivering the highest value product to our users of our application.

Feature flags are a tool that help us meet these values.

We utilize Feature Flagging as a mechanism to Continuously Deliver product with both confidence and safety. A partially built feature can live behind a flag instead of a feature branch. Feature branches are worthwhile avoid to eliminate merge conflicts, reducing work, and integrated.

A feature flag create two universes that live in parallel

A feature flag creates two universes that live in parallel for a period of time – one with the feature, and one without. Ultimately when the feature is live, the flag will be removed.

Life cycle of a feature flag

A flag is short lived and is removed after the feature is live.

📋 Flag added →
🏗️ Feature incrementally built behind flag →
👷 Feature tested with flag enabled →
🚀 Feature enabled in Production →
🧹 Flag and old code removed

If we want to use a flag more long term, it’s more likely an application setting. Feature Flags should be temporary.

What does a feature flag look like in practice?

A flag is essentially an if statement around a body or line of code. Let’s say we’re adding a dark mode to our site and want to give users a setting to use it, but it’s going to take a while to build theme the entire site. We could make a very simple flag to hide it from the settings page until it’s ready.

const darkModeFeature = false;

const SettingsPage = () => {
  return (
    <div>
      {darkModeFeature && <Checkbox label='Dark Mode'/>}
      <Checkbox label='Send me emails'/>
    </div>
  );
}

This flag is inline and in the same file, It can be a good idea to centralize flags into a single file like config/featureFlags.ts or use services like LaunchDarkly, Split.io, or other services.

Levers can be use to enable a feature flag

Depending on your service you use, or how you implement your flagging, flags can be automated to have to be triggered on / off by different signals. For example:

Deployment Environment (Development, Staging, Production)
Comparing the current date to launch date and time.
Set of User ID
User Role
A small percent of users

Each have their uses and potential benefits and the options will widely very by your creativity and application. However most common will likely be the deployment environment.

Why We Should Consider 1 Week Sprints.

March 4, 2021 Jonathan Stassen Leave a comment

You know how 2 week sprints are the de-facto go-to pattern for many teams? I don’t believe they are the best for teams and we should all consider 1 week sprints instead, and I’ll tell you why.

The Downfalls of 2 Weeks Sprints

Longer meetings to plan for 2 weeks
Need more Context
Hard to estimate how much work can be accomplished
Over commitment is easy
Doesn’t accommodate changing requirements
Doesn’t accommodate newly discovered scope as well
Doesn’t accommodate surprises that pull for attention away from the team (support, external teams)
Can create anxiety when falling behind, especially considering work remaining
PMs have less certainty on sprint progress
Slow feedback cycle

The Upsides of 1 Week Sprints

Tighter feedback loops
Shorter meetings
Allows team to be more precise in their commitments
Forces team to think about the now (highest priority).
If scope or focus change occurs, only interrupts 1 weeks worth of work.
If over commitment occurs it is smaller and easier to correct.
Generally feels more exciting, each week starts anew.
Weekly routine lightens the mental load

Won’t 1 Week Sprints have more meetings?

Since we have only one week to plan for, we must have more meetings, and this take more time right? Surprisingly you’ll spend less time in meetings!

Touching base on a weekly basis there are fewer surprises and thus fewer ‘new’ topics that need to be introduced.

For instance, when we are driving a car, it’s natural to drift a little side-to-side within our lane. But, instead of large jarring adjustments every minute, we make many frequent little adjustments keeping us centered on the road and therefore moving smoothly around every turn along the way.

Similarly, frequent touch bases are simpler and shorter, and therefore also keep the team in sync moving smoothly through their work.

Now let’s take a look at what a 1 week sprint schedule might look like.

The 1 Weeks Sprint Schedule

Here is what a possible 1 week Sprint Schedule could look like.

Outside of this schedule there still may be additional team meetings such as Project Planning, Project Kickoffs, or Planning Quarter Roadmap.

A week calendar view showing the meetings on each day including standups, grooming, retros, and demos. There are only 6 meetings displayed in total. Standups shown every day at 10am, three of which are longer in length because they include Scope, grooming, and demos. Retro remains it's own meeting. — A sample 1 week Sprint Schedule

Standup (15min) – Everyday at the same time, occasionally bundled with other team meetings.

* Touch base to talk about work in progress
* Update team members of any changes or needs

Week Scope (30min + 15min Standup) – The kickoff for the week.

* Review Previous Sprint metrics, work completed
* Review Previous Sprints remaining stories that will cary over to this weeks sprint.
* Define the weeks big picture focus for the team
* Pull in new stories & Prioritize them
* Pull in/out stories until matches teams throughput (don’t compromise and over commit!)
* Confirm the scope committed to
* End with Standup

Grooming (15min + 15min Standup) – Looking forward to future work and estimating stories

* Start with standup
* Introducing upcoming work & projects
* Breaking down, defining, and estimating stories
* Delegating project leads for spike work

Retro (30min) – How can the team improve

* Depending on how well the team is running this can be every 2 weeks instead of every week.
* Retros should always focus on how the team can improve to become the best team.
* Retros can be sometimes heavy. Therefore Thursdays tend to be best to avoid ending the week with any weight.

Demos! (15min + 15min Standup) – Celebrating the weeks wins!

* Start with Standup
* End the week with great for team morale
* An open form where any team member may share work (in progress or completed) from the week
* Great for knowledge sharing
* Ends the week on a high note.

(expand each section above for a detailed description & structure)

Bundling Team Meetings with Standup

Folks tend to prefer fewer meetings. A clever tool to utilize – combine meetings together that have the same or similar attendees.

In the sample 1 week sprint schedule above, we’ve combined Weekly Scope, Grooming, and Demo meetings with standup. This takes 9 meetings down to 6. Everything is simpler and lighter.

Summary

It’s worthwhile to consider switching your team to 1 Week Sprints. They will give your team more energy and more accurate commitment to their work. 1 Week Sprints will set your team up for even better success.

What does your team use? Would you ever switch?

(cover photo credit: Jonathan Stassen / JStassen Photography)

Project Management

How do you define a critical path

October 4, 2020 Jonathan Stassen Leave a comment

With any application there are parts that are more critical if they break Other areas are less critical, but nice to have. How do you figure out which are part of your Critical Path?

A Critical Path is considered: Anything that inhibits a necessary core functionality.

It’s easy assume to assume we already know what is Critical or not in our applications. It’s good to have a strategy to evaluate the criticality of one feature to another.

Understanding what features are Critical Path helps understand things like: urgency of fixes, amount of unit/automation testing should be written, and amount of time to invest in making it resilient to failure.

Create a list of features

List out features of your application, both small and large. This list should be extensive. Collaborating with team members is a great way to remember every little features that exist.

Next we need a way to score and compare features.

Create a Critical Path Rubric

Create a list of questions to evaluate features against each other. Here are 7 great questions to ask of each feature to test if it’s a Critical Path feature:

(Click to expand each)

1) Does it have a high volume of usage?

Example: On this blog articles are ready many times a day, search only used a couple times a week.

Does the system, workflow, or feature see more than X volume of usage per day?

One of the simpler tests at first blush, how much is it used. However, personal anecdotes, preference, and bias can cloud our judgment of what the most used items are.

If we aren’t measuring usage, then we can only guess with an anecdote how much something might be used. Thus it’s important to truly add monitoring to systems.

When we can measure the volume of usage the feature or workflow by users. Each time a someone uses a feature or system we can consider it a vote towards that item.

2) If it broke would it disrupt / make common workflows unusable?

Example: Does it prevent the user from getting to other Critical Paths, like replying?

Often there are single spots of failure in a workflow. For instance maybe there is only one ‘next’ button on a view. Without it there is no other way to progress to the next step. The only option they may be to give up on what they want to accomplish until its fixed.

3) If it broke would there be a comparable workaround?

Example: Instead of logging into a site with Facebook Login, logging in with username & password.

This one is a counter point to the previous, even a workflow is common, there is a second way to accomplish the workflow. It might not be perfect or ideal, but the support team can direct users to the alternate path while the main workflow is repaired.

For example there might be multiple places on a site a user could go to try to remove a photo they posted. If one page doesn’t seem to be working, a user could go to another view that also shows your photo and try there.

4) If it broke would support receive a moderate to large volume of calls?

Example: Severity 3 or higher

This also builds upon the previous, if the support team does receive calls about the broken workflow, what would the anticipated call value be? If the volume would be large and overwhelm them, the feature is likely part of a Critical Path.

5) If it broke would we consider an app-wide rollback instead of a bug fix first.

Example: All images are failing to load.

App-wide rollbacks are fast, they quickly switch code back to how it was a couple hours or days ago. This is a great option to leverage when something critical breaks, but it’s not a lightly taken path as it will also roll back any other fixes or features that also would like to be out.

If rollbacks are on the table as an option if a specific workflow were to break, it most certainly is considered a critical item.

6) Would a customer consider leaving if it was broken for more than a week?

Example: Unable to reply to emails.

Customers and users depend on your application, they form a dependence on it work and working well. If something they consider critical within your app breaks, the trust in the reliability is eroded.

Some items might be so critical to a customer that they may even consider canceling if it was broken for a significant length of time.

They won’t probably cancel because they can’t change their profile photo, but other functionality they most certainly may.

7) Would the CEO be asking questions if it was broken?

Example: Inbox failing to load / empty, red bars, and mayhem.

The CEO carries weight and has their values. If something major breaks the CEO will know and be aware. If a workflow is so critical that they would be made aware of it breaking, you can guarantee it’s likely critical to the organization.

Score and Rank Features

Looking at each feature score each feature’s Criticality using the questions you’ve developed.

For example you could use a 1-5 points scoring.

Not Critical
Hardly Critical
Somewhat Critical (Neutral)
Critical
Very Critical

Once scored, what do we do with this new understanding?

Conclusion

With these tools at hand, there is now a way to understanding what features are Critical Path.

There is a method to understanding the urgency of bug fixes. You know the areas of the application that more unit/automation testing focus should be put. And can start to think about investing in making these features more resilient to failure.

Building with intentionality around Critical Paths can take your application to the next level of reliability.