Tag Archives: Project Management

Project Management

What is a Feature Flag?

Leave a comment

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.

Further Reading

Book Reviews

Waltzing with Bears – Book Review

Leave a comment

Waltzing with Bears is one of my favorite reads. It has become essential reading for anyone leading projects. It’s honest and pragmatic, providing evidence for the need and power of good risk management for project planning.

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 10 / 10
  • Did I learn anything? 9 / 10
  • Did I learn anything I can apply? 9 / 10
  • High Information density? 10 / 10
  • Would I re-read? 8/10

Buy Waltzing with Bears on Amazon

Waltzing with Bears Book Cover

Waltzing with Bears Overview

Waltzing with Bears takes us through the journey of Managing Risk on Software Projects. It starts out analyzing what Risk really is and why it matters. Then it transitions into demonstrating what we can do about it, how to talk about it, tools we have, mitigation methods, and common pitfalls. It shows how analysis of risks & their probabilities can inform the probability curve of delivering a project

Ultimately Waltzing with Bears advocates for being open & honest about what on a project we can control, thinking about what risks we can mitigate, and how we can more realistically plan projects while including uncertainty.

Who should read Waltzing with Bears?

Every Project Manager, Product Manager, Head of Engineering, and Senior Engineer. It will shift how you think of projects and give you the tools to stop guessing about projects and start projecting realistic projects.

My main takeaways

Don’t ignore project risks. Risks make us more self aware and not count on ‘luck’ or ‘stars to align by chance’. We can eliminate a good portion of guess work.

We can use math to quantify risk asses its probability of impact on a project delivery dates or outright failure.

Deadlines dates are a bit of a myth. Instead a distribution confidences for completion is more realistic when Planning Projects and Road Maps.

Just because you wish / hope / believe that things will go perfectly, doesn’t mean they will.

If you did no diligence in checking for risks, and a project goes perfectly, you are just as guilty as someone who knew of risk and did nothing about them. See Ethics of Beliefs.

5 most common items that impact software project timelines: Scheduling Flaw (ill informed project timeline), Requirements Inflation (additional unplanned work), Turnover (staff leaving), Specification Breakdown (ignoring agreeing upon what/how key items are built), Under Performance (low/high throughput by team).

Riskology Worksheet is a great way simulate these risks impacts on a project.

If you liked this book, next I’d recommend

On team culture: Debugging Teams

Project Management

Why We Should Consider 1 Week Sprints.

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

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.

  1. Not Critical
  2. Hardly Critical
  3. Somewhat Critical (Neutral)
  4. Critical
  5. 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.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Planning Quarter Roadmap for a Team

3 Comments

Planning quarter roadmap and which projects to tackle is daunting.

It’s a lot to think about: What’s most important, What are quick wins, What work needs to be finished, Which stakeholders are most important.

Time to build matters

It’s easy to overlook the size of projects and how long they will take: Requirements are vague, Designs don’t exist, Dependencies are unknown — Everything is guess work.

Including the Team to Discover Scope

It’s tempting to hold tightly what projects are being dreamed of, holding them close until the start of the next quarter — revealing them at a kick off. Keeping the roadmap a secret is dangerous.

Two things this can cause:

  • Surprising the teams that will be building the projects, they have many questions.
  • The time and effort wasn’t decided by the team that will be building the projects, it was likely assumed.

Therefore it’s important to pull in the team to help build out the next Quarters roadmap. It should be clear they likely won’t be making decisions of what gets prioritized. Leveraging the teams to understand the systems that are in place, project managers can work with the team to understand guesstimate time range or amount of effort it might take to accomplish the possible projects project.

  • Better estimates of projects scopes that can inform prioritization.
  • Team is excited for & already understands projects that are in the pipeline

Temptations & Warnings planning quarter roadmap

It can be tempting for a team to dive into the technical implementation of a project. This is ok up to a point, but only to a hypothetical point. The goal is to create a rough range how long it might take.

Time ranges are important. There are always surprises, both good and bad that cause projects to go faster, but typically longer than expected.

When estimating, pick a unit for the time. Let’s say a project may take 2-3 weeks – but is that with 1 person? Or a full 3 person team working on it? It makes a huge difference! When pick units, Stay consistent with those units.

An extended form of hiking in which people carry double the amount of gear they need for half the distance they planned to go in twice the time it should take.

~Author unknown

It’s very tempting to take the low estimate. Don’t use the lower estimate! Projects always tend to run longer for miscellaneous reasons (bugs, scope creep, interruptions, pto, forgotten pieces, testing). It’s much more realistic to pick something in the middle or even the pessimistic estimation. I wrote about a related topic, Why We Estimate Stories which goes further into the cautions of under estimating.

Visualizing the Estimates

I’ve built a spreadsheet layout for looking at projects that have been picked for the roadmap and how they look on a time line.

Again it’s tempting to only look at the Optimistic estimate, and it might be best to delete the Optimistic row if temped by it.

On my teams it’s very important that the entire team focuses and works on only one project at a time (else you really have 2 teams not 1 and projects take longer, gasp!). We also estimated our projects in units of “number of weeks 2 devs working” for each project which makes it super convenient to map out.

I’ve made the Roadmap Planning Template available on Google Docs. Make a copy and give it a try.

Looking at this we can see a lot of great info. For example, we can see something interesting about Project B. It’s 4-7 weeks, the team isn’t very confident in it’s scope & needs. We either need to better define the scope, cut scope, or table it until we better understand it. It puts other smaller projects at risk. Perhaps Project D is high priority to complete in Q4. There are many great conversations we can now have.

Setting Good Commitments & Expectations

There were actually Projects A – J slotted for Q4. That’s 10 projects. Working with the team, even the optimistic projection puts us at the end of Q1, and pragmatically 1/2 into Q2!

If we hadn’t worked with the team to estimate the scope we would have been blind to our commitments we almost made in Q4. While we were excited with hope about all the things we would to accomplish in Q4 we would have been setting ourselves up for failure & disappointment & poor morale. Not only within our team, but also our external stakeholders.

Conclusion

Being pragmatic about commitments planning quarter roadmap is hard but hugely important in setting a team up for success. We are inherently optimistic creatures, we want to promise & hope to accomplish more than is realistically always possible.

Finding tools to help us be honest with ourselves makes us & our teams be honest & better people.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Why do we estimate stories?

3 Comments

There are two reasons we estimate stories: to understand scope and then to communicate that size of that scope to others.

Understanding Scope of Tasks

In order to be effective at anything we do in life, it’s best to step back and understand what it is exactly that we want to accomplish.

  • How hard is it?
  • How complex is it?
  • Are there unknowns?
  • How long might it take?
  • How well do we understand it?
  • Are there other tasks that need to be done first?

As an individual we ponder these questions ourselves. As a team we discuss them together during our weekly scope and grooming to refine our shared understanding.

It’s easy to dismiss small tasks as not worth any further scrutiny because they feel obvious. Asking these questions takes little time. Even the simplest tasks can hold surprises if we take a moment to ask these few simple questions.

A fool does not care whether he understands a thing or not…

– Proverbs

Communicating Effort

It’s hard to express how long or hard a task is to others that are not in our domain of knowledge. Perhaps they’ve never seen what code even looks like, much less tried to program.

Thus we point and estimate stories. I prefer to call them effort points or “oof” points. How much “oof” effort does something take to accomplish.

Here is an example with my household chores.

“oof” effortStory Points~Time
Take out trashLittle “oof”11-10 min
Wash the dishesSmall “oof”310-60 min
Mow the lawnMedium “oof”51-3 hrs
File taxesBig “oof”83-8 hrs
Remodel bedroomLarge “oof”132-5 days

What’s important to notice is that Story Points / Effort doesn’t mean a specific length of time but rather an estimated time rage.

Story Points are a valuable tool to roughly translate effort → time estimations.

This gives Project Managers a way of estimating a rough expectations of when a collection of tasks might be completed. This empowers Project Managers therefor to set a realistic estimated timelines & expectations with external stakeholders for when tasks and projects might be completed. I wrote more on Planning Roadmaps & Project Estimation in another post.

Personal Cautions & Notes – Estimate Stories

  • Lean heavily on higher end time values when trying to translate points to time; that is be pragmatic.
    • It’s highly unrealistic it only takes under 1 min to take out the trash & put a new bag in, probably closer to 8 min.
  • Project managers don’t mind hearing that something is complex, big or unknown, the sooner they know this the better.
  • Project Managers love the radical honesty, it helps them set realistic expectations with their stakeholders.
  • Always round up to higher point levels if something is on the fence.
  • Talk about estimating with your team and create a good Developer Culture when you estimate stories.

(cover photo credit: Jonathan Stassen / JStassen Photography)