We’re excited to talk about Sprint.ly, our Project Management solution. We first used Sprint.ly back in 2013 and loved the tool for its simplicity. The team at Sprint.ly had moved onto other things, and frankly hadn’t been working to improve the tool for a while, so we stepped in to continue to support and iterate on the product.

A lot of project management tools are too heavy for the majority of people to use, and Sprint.ly’s not that.

We believe that work doesn’t have to be as complicated as Jira makes it, and Speed is a Feature. Our new iteration on Sprint.ly embodies these principals, and while you can’t do everything that you used to (yet), we’re excited to keep moving the ball forward on what is fundamentally a great product.

We’ve spent the last year tinkering and building a new, improved mobile-friendly Sprint.ly, and we’re excited to share it with the world 🔜

A lot more coming soon. Cheers!

If you’d like to get an invite to the new version, please fill out this form here and we’ll shoot you a link.

Building a Shared Vocabulary

So much about communication is being able to agree on the same ideas. 

It doesn’t matter if you agree on a subject, what’s important is that you agree on what the subject is.

There’s a non-trivial difference in each individual’s mental models of the world. What is gun control? What is poverty? What is financial intelligence? 

When you’re working with people, it’s critical to reach a mutually understood architecture for ideas to pass through.

There is no chance you are building the right software unless the entire team has a shared understanding of precisely what it is you’re talking about.

It would be best if you, and your team, groomed your vocabulary on the subject regularly. Make sure your client has the same definition for standard terms and systems.

There are hundred of thousands of words in the english language, and that’s just the dictionary.

When you add technology, acronyms and bespoke system designs, it’s not reasonable to assume everyone on a project has an identical understanding of what each thing is, means, or stands for. These are technical terms, and there are subtle differences in the way they are applied. It doesn’t matter what the vocabulary is; it’s about what it means.

On most projects, it is worth your time to compile a glossary or similar documentation with standard terms and their definitions. Your project’s glossary helps to get everyone on the same page and is especially useful when new people are getting started with the project.

Deployment Confidence

Deployment Confidence is a measure of a change’s likelihood to break the production environment. Some changes are trivial, and after code review and testing have little to no chance of breaking the production system. Other changes, especially when they are sourced from long-lived branches and involve many changes, would be riskier. The higher the risk, the lower the Deployment Confidence is.

It doesn’t take much skill to identify changes that have a high likelihood of breaking production, but it does take some experience. In general, things to look for that should decrease your Deployment Confidence include:

Environmental Drift

local development == staging === production

How consistent are your Development, Staging, and Production environments? If they are extremely dissimilar, then you simply cannot have high confidence in your changes functioning properly in production.

Some dev teams believe they can work around this by having a staging environment that is near perfectly identical to production. Staging should always be extremely similar to production. If your development environment is not extremely similar to staging, then you’re introducing waste into your value stream. [Context Switching Kills Productivity]

  1. Many changes made without deployment (more than a thousand lines of code added net)
  2. Long-Lived Branches
  3. Major refactoring
  4. Complex database migrations

Versioning Strategy

Using a software versioning strategy for your builds can reduce the cognitive load for everyone developing and using your software. Versioning Strategies allow you to identify each build artifact quickly and easily. What versioning strategy you use for your software is up to you and your team’s personal preferences. Here are some different options and some pros/cons for each.

Git Tags

When you’re using Git for your Version Control System (VCS), you already have a unique hash for every commit that you make. You can find the hash on the terminal with git log -1. If your Git repository is on production, you can easily tell exactly what is running by checking the git log.

Whenever you make a production release of your project, it’s best practice to identify the release with a Git Tag. This makes it easy to know what you shipped and when, and gives you some additional methods for rolling back to a previous version.

git tag v1.0.0 && git push --follow tags origin master

If you’re paying attention, in order to create a Git Tag, you’ve got to name it something.

Semantic Versioning: “SemVer”

Versioning Numbers https://commons.wikimedia.org/wiki/File:VersionNumbers.svg

MAJOR.MINOR.PATCH SemVer Documentation

Semantic Versioning is the most popular choice in open source and is widely adopted by the Ruby, Python, PHP, and Node.js ecosystems, with minor variations. Semantic Versioning is built using the glorious RFC2119. Each numerical version has its own meaning.

A MAJOR version must be incremented if there are any backward-incompatible breaking changes included in a release. This has the benefit of making it easy for anyone to quickly identify if a new version will work differently than a previous one.

The MINOR version must be incremented if there are backward-compatible functionality is introduced. In the strictest sense, this means you should be able to upgrade to a new minor version without experiencing any breaking changes.

The PATCH version is meant for backward-compatible bug fixes. You should expect no new functionality with a new patch version, only improvements.

Remember that each number in SemVer is treated independently. This means version 3.14.2 is more than 11 releases ahead of version 3.3.0. This will not be apparent as version 3.3.0 is higher in priority when sorted alphabetically.

SemVer also allows for pre-releases, but we do not recommend using them. Pre-releases A pre-release defy all logic of semantic versioning, meaning they ignore the conventions around breaking changes. Any pre-release may break at any time. If you’re considering releasing your software as 2.0.0-beta-1 through 2.0.0-beta-24, you might as well throw away SemVer all together and use Incrementing Build Number or Date Based Versioning systems, since there is no meaning in incrementing a beta number indefinitely.

Resetting the Version

Occasionally developers decide to reset their versioning for various reasons. MySQL released versions 5.5, 5.6, 5.7, and then jumped to version 8.0, leading some folks to refer to the previous 3 MINOR releases under MAJOR version 5 as 5, 6, and 7. Similarly, React made a change when they released version 0.14.8, followed by v15.0.1. SemVer’s recommendation is to start with version 0.x.x, which React did. In their case, the React Team decided their project was mature enough to skip version 1.0 all together as in their case the MINOR version had much more meaning than the MAJOR.

Incrementing Build Number

Another somewhat popular methodology for versioning your software is to simply use the build number as set by your Continuous Integration System. This gives you a simple incrementing version to your Git Tags. You can still easily reference the Git Commit Hash and find the date of the release using Git.

Date Based Versioning

Date Based Versioning provides you with some information about when the release was made. Arch Linux uses Date Based Versioning in the following format: YYYY.MM.DD

If you are on a more frequent release cycle than once-a-day, you may have to also include time information to maintain a unique identifier for the artifact.

Hybrid System

Ubuntu is the most popular Linux distribution for web servers. Ubuntu follows a strict 6-month release cycle using a date-based schema. For example, 18.04, 18.10, 19.04, etc. Since Ubuntu is so critical to so many people, this release schedule makes sense for them. Like many mature projects, there is documentation for the Ubuntu Release Cycle, which allows everyone to plan ahead for changes.

Further, additional updates to each major version Ubuntu uses patch versions to indicate follow up releases to their major versions such as 18.04.3.

Software Versioning System Comparison

Versioning SystemProsCons
SemVer– Widely Adopted
– Generally Meaningful
standard-version npm package makes it easy to use
– Most open source ecosystems require usage for package distribution.
– Attempts to reduce the nature of changes to a number
– Specific conventions may vary from project to project and language to language, for example, Python PEP 440
– Pre-releases negate any worth
Incrementing– Simple
– Referrences CI Builds
– Does not convey any infromation about the nature of the changes
Date Based– Simple
– Very easy to identify when releases were made
– Does not convey any information about the nature of the changes
– Not ideal for releasing multiple times daily
Hybrid– Can use the best parts from SemVer, Incrementing, Date Based versioning systems
– You get to define for your own project how the system will work
– May not be consistent with any specific package manager’s requirements.
– Anyone developer using your software must understand your versioning conventions via your documentation

Additional Reference:

Sizing Software Work Appropriately

Sizing software work appropriately has some challenges and pitfalls, but there are a few simple guidelines you can follow to help raise your level of confidence in your team delivering on time. First, you should [Make Sure You’re Building the Right Thing]. Next, [Learn How To Estimate Software Work]. We encourage you to use [Fibonacci Estimation for many reasons].

Assuming that much is straightforward (which it isn’t), as a team, you need to take work on that you can reasonably expect to complete.

How to Eat an Elephant

Step 1. Butcher the Elephant. Cut it up into tiny pieces.
Step 2. Cook and eat the pieces one at a time. Size each meal so that you can finish it in one sitting.
Step 3. Ship it.

In software, [Agile Methodologies] encourage us to break work down into small chunks. Much like eating the proverbial elephant, it’s not likely to go supremely well on your first go of it. Perhaps it won’t ever be done perfectly, but you can follow some guidelines to make sure that you have a high probability of success.

How Big is Too Big?

Your team’s estimation accuracy is likely to increase over time. When you start a project, there are too many Known Unknowns and Unknown Unknowns. There is much uncertainty — and uncertainty never contributes to accuracy. You need to start somewhere, which is why we say an estimate of a 1 is the simplest of all tasks. As you progress up the Fibonacci scale, by the time you estimate a task at a 5, you’re looking at 4 ordres of magnitude in complexity. That’s approximately 10,000 times more complex than the most straightforward of changes.

So why on earth would you be willing to take on a task estimated larger than a 5 on a Fibonacci scale?

Stop. Keep It Stupid Simple.

We strongly discourage any team from taking on a task estimated at more than a 5 in Fibonacci estimation of complexity. As the complexity of a task increases, the chances of Unknown Unknowns being encountered increases. If your 8 or 13 point task is the most important thing on the docket and “absolutely must” be completed in the future, you should know what to do:

Break It Down

Take your 8 or 13 point task, and start talking through the approach with your team. Split the item into as many individual tasks as appear reasonable and necessary to achieve the goal of the original story.
Start by breaking down the item, focusing the team’s conversation on what is involved in achieving success for the original task. Once you have an accurate picture of what the technical pieces in need of execution are, Once you’ve worked thoroughly breaking the item down into its discrete parts, have the team go through another round of estimation.

Important Side-Note: help your team avoid context switching by handling the breaking-down and the estimation of tasks separately. Once you hit a 13 pointer in the backlog, it’s worth breaking it down right away, because the team’s shared context has switched to wrap their head around this item. Proceed to break the item all the way down into seemingly reasonable parts. Once you’ve accounted for all pieces of the work item, then move back to estimating the discrete parts. [Humans are Terrible at Context Switching] so help your team out by avoiding it.

A typical 13 point story could likely be broken down into 5-8 different individual tasks. You may be surprised to find that as you break the issue down, the sum of the parts is equal to more than that of the original 13 point estimate. It’s typical to see estimates of the tasks involved in the delivery of a 13-point story to break down as 5+3+3+5+2+1=19. There’s nothing quite like taking something complex, making it simple, and then realizing there’s more work involved than you originally had thought.

Why Does this Matter?

When a developer sits down at their computer for a day’s work, (let’s say it’s 8 hours), it’s reasonably likely they can complete a 5 point item that is well defined and has few unknowns. As soon as you pass beyond the 5 point threshold, the uncertainty begins to increase and the likelihood of the work extending beyond one-day increases. It’s essential that the work not extend beyond one day because it’s easier to get work done when you feel like you’re accomplishing something every day. Long, slogging tasks are disincentivizing.

By keeping your team’s work items small, you should see higher team morale, not to mention more easily testable code with more isolated changes.

Choosing The Best Git Branching Strategy for Your Team

Choosing the best Git Branching Strategy for your team helps to deliver value to your production environment quickly and with a high degree of confidence. Generally, the best advice we can offer is to start simple. Don’t over-optimize your git branching strategy before you have something in your workflow that needs improvement.

Branching Strategies

If you find yourself as the only developer on a project, using a branching strategy that is less-than-the-simplest-tool-for-the-job is likely to be [premature optimization]. A single dev working on code should be able to get a single task into production within one business day from the time they start working on it. Yes, the code needs testing, so are including that time in our metric of “deliver value within one business day.” Tasks need to be small enough to be shipped in one day for this to be achievable.

The three primary strategies range from simple to complex in the following order: GitHub Flow, GitLab Flow, and Git Flow.

Start with the simplest thing that works.

GitHub Flow

GitHub Flow is a vastly simplified workflow compared to the process that Git Flow recommends. GitHub Flow is usually best for small teams that don’t need to manage several different environments or versions simultaneously.

GitHub Flow is trivially simple. You start from the master branch, checking out a new branch to do your work. When you’re ready for your work to be reviewed and merged, open a pull request to master.

Even if you’re a solo developer on a project, we still recommend you go through the process of opening a pull request, as it serves as a record of changes submitted. The work should be tested (on its feature branch), and when it is considered ready for deployment, the code is merged to master and deployed with due haste.

GitLab Flow

GitLab Flow is the newest popular branching strategy. It’s great for the case where you have multiple different environments that you need to support. In GitLab Flow, master is still your base branch, and the code is branched from master when you are working on features. Additional branches are release-purposed for different environments.

Example: Perhaps you have an iOS project, so you can’t control when your production releases are made (due to Apple’s review process). In this case, you’d cut a release branch at the time you want to deploy it, and employ some versioning strategy that makes sense for your team.

Work can continue regardless of changes from the appropriate release branch and cherry-pick those changes back into master. This workflow minimizes [drift] as much as you can, considering that you can’t control production releases.
It’s also useful if you need to deploy a series of changes to a staging environment. You’d cut the staging branch from master until the QA process is complete.

Advantages of GitLab Flow include the workflow still being simple. Master is your base branch, and [you shouldn’t merge untested code to your base branch]. If there’s a problem with a release, you can handle the changes in the appropriate branch, and promulgate those changes back to master.

Git Flow

Git Flow, the original article from 2010 proposed that master should be your production branch and that you should set the base branch to development to avoid confusion. While there’s nothing inherently terrible about this, due to the nature of changing the defaults, it does come along with some cognitive load for the team to consider at all times.

In our experience, Git Flow encourages [drift between environments], since development is by definition not equal to production. We’ve seen Git Flow abused such that broken code is merged to development and is allowed to make roost there for weeks before deployment.

Advantages to Git Flow are a highly rigid process. If your paranoia level is high for a good reason, Git Flow does provide some added protection. Compared with the other branching strategies, Git Flow increases the number of hoops that developers need to jump through in order to release code to production. If you have a rigid QA process and infrequent releases, Git Flow may be right for you.

Additional resources on Git Branching Strategies and when to use them

What are the Pros and Cons of Git Flow vs. GitHub Flow
Git Flow Considered Harmful
GitFlow and When You Should Use It
GitHub Workflows Inside of a Company
The 11 Rules of GitLab Flow

Quality Assurance

Does every change need to go through a thorough quality assurance process?

It’s unlikely that a cookie-cutter QA process takes into consideration Deployment Confidence. If it takes 30 minutes for a developer to merge and deploy changes to the staging environment for testing, then a QA tech can access those changes and test for another 15 or more minutes, you’re looking at about three-quarters of an hour worth of work.

Before anything even reached staging, there should have been a code review, which perhaps took another 15 minutes of a different developer’s time (assuming that the code review was perfect).

Perhaps the Product Manager already reviewed the changes in her local environment, consuming another 15 minutes of time.

All and all, we’re looking at a total of 1.25 hours of work spent on quality assurance in this case. Over an hour of quality assurance, all for one change.
What is the added value of the 1.25 hours of Quality Assurance? Did we stop to consider the Deployment Confidence for this work item? If the risk of breakage was low, the 1.25 hours spent on QA was probably overkill. The work item only needed a code review and perhaps a spot check by the Product Manager to make sure that the software behaved correctly. We could have avoided the staging deployment, in this case, avoided the use of a QA tech, and we could have delivered value to production faster.

Standard QA Process

  1. All team members should rebuild their environments on a regular basis, usually when pulling in new changes from the remote repository.
  2. Developers should test their code to the best of their ability before they submit their work for a peer’s code review.
  3. Someone else on the team performs code review: Code review means you read the code carefully and you pull the code into your local environment to test that it is working. Bonus points if, as a developer during code review, you have the time to test the specific feature change to ensure its behavior is appropriate.
  4. Review each pull request for a measure of Deployment Confidence: This isn’t an exact science, but a rough risk estimation is possible:
    • Low Deployment Confidence: the app needs thorough testing in a staging environment before deployment to production. This staging deployment should mimic, as much as possible, the deployment to production: including running migrations or other “launch-checklist” type items. The goal here is to surface any issues that may are likely to be encountered during the production deployment.
    • High Deployment Confidence: Code review and local testing is enough time spent before production deployment.
  5. Production rollbacks must be quick and painless. If you can’t easily revert changes in the production environment, spend time on this first. Production stability is paramount, and if production is fragile, then breakages will occur no matter the complexity of changes made.

It’s a better use of time to improve production stability than it is to add extra layers of process and time spent to deploy each change to production.

Deliver Exceptional Value and All Else Will Follow

Focus on Delivering Exceptional Value and All Else Will Follow

Working with software teams is an exceptional challenge, and it can be a heck of a lot of fun. Software is fun to work on when we all are winning, the client is happy, and the users love the product. If you have all of those things, you hopefully can make a decent living too.

Building high-performance teams isn’t complicated, but it takes discipline and the right mix of talent. The team needs a proper, well-defined direction. It Takes Trust.

Our team can only operate as well as its weakest links. We aren’t football players, and we don’t need the likes of Bill Belichick to perform at a high level. What we do need is a profound commitment to our teammates to Always Be Creating Exceptional Value.

We’d love for life to be more straightforward, but just because you work some hours doesn’t mean you can bill for them if you don’t create value. Software is fundamentally about change, and these things take time.

Continually changing dynamics on a software project are the status quo: the state of the industry, customer needs, client demands, toolkit changes, etc. Workflows can always be tweaked to improve the team’s ability to deliver working software more reliablly, faster.

If your team is five people with different knowledge and expertise, consider who is the weakest link, based on:
1. Skills and experience?
2. Team Dynamics?
3. Client Dynamics?
It may be that three out of the five teammates are weak for this project, all for varying reasons.
Faced with the possibility that over 50% of your team is weak, you might imagine they must not be delivering value. However, this very well could be a highly performant team. The team needs to be nurturing its weakest links, not ignoring them, hoping they’ll somehow improve.

Hope is not a strategy

What is Value Creation?

Value creation is the primary aim of any business entity. Creating value for customers helps sell products and services, while creating value for shareholders, in the form of increases in stock price, ensures the future availability of investment capital to fund operations.1

What is the Definition of Done?

The definition of done will vary slightly from team to team. Typically, we recommend that Shipped to Production means the task is done.

shipped === done

That’s all, nothing to see here, move along.

How long does it take to move something from Todo to Done? How many steps are there? How can we reduce friction for the team to be able to move things from todo to done even faster than before? Are we getting better at completing things more quickly? What is the constraint on the value pipeline — is it that no one is quick to do code review? Is it that the client is slow to do acceptance testing on the staging environment? Are there too many changes in each pull request, causing painful migrations and merges, blocking the team from being able to ship their pieces to Production?

There are fewer than a million ways that things go wrong on software projects on a value delivery level. Most problems smell like the ones listed above, and they are all resolvable.

-If the team goes a week without shipping anything to production, you have some explaining to do.
-If items take than 24-48 hours to complete, you need to reduce the complexity of each work item, to deliver the pieces more quickly.
-Team members must feel that they are able to win.
– Team members must be able to work through the process quickly and efficiently, delivering their value additive changes to production in less than a day’s work.

It Should Take Less than 8 hours to get something to production.

The “soft” skilled members of the team, such as Product Managers or Designers are not different. The product manager delivers value by keeping the team fed with well-articulated work items that they can complete and quickly move through QA. The designer creates artifacts and iterates on them by working with the team. “Done” doesn’t mean shipped to production in these cases, as the end state is a work item that can be delivered by the dev team.

How does an Agile Coach Deliver Value

Agile Coaches or Scrum Masters are a meta value add. They’re there to ensure that the team is staying on track and is capable of completing it value delivery in a reasonable manner. The Agile Coach is there as a safety net to surface any apparent process related issues that the team would heartily proceed to ignore due to their inherent conflict of interest.

In more disciplined and experienced teams (meaning that this team has worked together, effectively, for an extended period), an Agile Coach won’t be necessary, because the team has grown in their shared discipline. If this team is capable at this time of operating a regular Sprint Cycle without a Scrum Master, they may be ready to graduate from scrum to kanban.

The value added by the Agile Coach is keeping the team on the rails. In sporadic cases are problems not foreseeable or preventable. It’s the Agile Coach’s job to keep the team on track.

Conflict of Interest

There is a non-negotiable conflict of interest that each developer faces on a software team. Their work is already challenging, and it’s in every great developer’s best interest to make their job easier over time. Many of the technical debates that take place on a software team stem from this simple fact. If you have two approaches to a problem, perhaps one places more workload on the backend developer, and another puts the workload on the front end developer. How do you determine what the right call is? The answer, as many CPAs will tell you, is “It depends.”

Enter the Agile Coach. Having this person around to assist the team from a non-partisan perspective is where they add their value. The developers are not only trying to identify the most value-additive way to deliver their work, but they are also subconsciously optimizing for their workload. If the “Easy” way sacrifices user experience, developers will go unchecked if the Product Manager or Designer are not advocating for Great Ux*.

What’s the Value?

All of the technical minutiae of a software project boils down to this: What value is this pull request delivering?

  • [ ] The client asked for it && it makes sense
  • [ ] It satisfies a technical requirement from the client && that technical requirement makes sense.
  • [ ] It makes our users happy
  • [ ] It’s necessary to reduce the Technical Debt && Reducing the Technical Debt is the most important thing to do right now
  • [ ] It meets the acceptance criteria
  • [ ] It’s an objective improvement to the system
  • [ ] It will improve team velocity

If you can’t say yes to any of those checklist items, we’ve got problems. I don’t know how we’re going to be able to expect the client to pay for that.

That’s how we think about providing value for our clients. We know that as long as we are delivering exceptional value, then all else will follow.

* This is, in no way meant to shame developers. We used to be there writing code alongside you.

Building Trust on a New Software Project

Building trust is essential to teamwork. It’s critical to working with clients and vital to survival in human nature. Show me a team that doesn’t trust each other, and I’ll show you a team that doesn’t operate at capacity.

Trust is a Prerequisite for Value Delivery

Building trust is the first step in delivering value. Don’t believe me? Here is a strange example, (stolen from Seth Godin) but it illustrates the point. Try this:

Go up to a random house in your neighborhood, (someone you don’t know that well). Knock on the door, and offer them a 10 dollar bill for free. What will happen? They’ll say no, close the door, and peer back at you from between the blinds to make sure that you’re leaving. They will immediately start thinking that you are trying to give them counterfeit currency. “Why is this nut trying to give me money for free?”

Next, pick a different house, and put a 10 dollar bill in their mailbox. The next day, do it again, and again the third day. On the fourth, knock on the door and say “Hey, I’m the person who has been sticking $10 bills in your mailbox. Here’s another one.” This time, they’re likely to take the cash from you with a smile and say “thank you,” because now they know you’re crazy. You’ve built the trust. Now you can deliver the value.

Applying Trust to Software Delivery

Let’s make this more applicable to the software value delivery pipeline. You build a software application, and low and behold you’ve somehow magically delivered every one of your client’s requirements — it’s exactly what they asked of you. When it comes time to do your demo, will the client accept the work?

We don’t know. How much trust is there between your team and your client? If the client has convinced themselves beyond a shadow of a doubt that you are incompetent, incapable of delivering, and intentionally trying to screw him, will it make a difference if your work is of high quality or not?

Are there undiscovered bugs in the system that prevents it from functioning in the way that you understand it too? If there is a lack of trust and transparency within the software team, you probably can’t know the answer to this.

Build Trust First

You only get one chance at a first impression, but the last impression is the lasting impression. In the critical early phases of a new software project, it’s essential to do a few things well.


Take the time to understand the situation of your client fully. You’ll want to figure out the following, but you might not be able to ask these questions outright.
– What is their business situation?
– Their place in their organization?
– Who is the person who pays the bills?
– Are they trying to make themselves look good to their boss?
– Are they trying to make their boss look good?
– What is their motivation?
– What is the business goal of the software project?
– Where have they been as a business?
– Where are they headed now?
– Where do they want to be in six months? A year?
– How does your project fit into their picture of reality?

As you increase your effectiveness working with clients, you will eventually learn to be able to answer all of the questions listed under “Empathize” within the first two meetings. You should document this information in an appropriate locale that your team will have access to as they come onboard to the project.


A high-level overview of what the client is looking for is a good place to start. As you begin to unpack the project at a high level, pay attention for ways that you can deliver exceptional value as a team within the shortest possible timeline.

Questions to answer

  • What are the most important features that must work for the project to be a success?
  • What’s a rough estimate of how long it would take to build out those features as a functioning proof of concept?
  • What are the important dates in the future we must hit to be successful as a team?

ProTip™: There is always a deadline. You may have to ask three or more times, each time in a different way before your client finally spills the beans on the drop-dead date.

Get Early Wins

On a Blue Field project, don’t start with Authentication. User authentication is not value-additive, it’s table stakes. If your team is unable to deliver authentication in the first week, it doesn’t mean that your team is terrible, it proves that authentication is a table-stakes feature which includes a constellation of sub-features and every client is going to assume that authentication works (for most web-based applications). There are third-party libraries that you can leverage, but the bottom line is that building Authentication is not value-additive for the client’s software project. If you want to prove your team can build the software the client is paying for, focus on the features that are unique and cannot be serviced by off-the-shelf software packages.

Deliver exceptional value and all else will follow

Depending on the Frame of the Project this phase will always look a bit different, but some things don’t change.

Ship something in the first week.

If the project isn’t running on the internet, that’s not a deal breaker, as long as it’s easy for someone to run the project locally. As developers come online to the project, it’s important to give them the same sense of accomplishment by giving them an opportunity to deliver something to whatever the “production” environment is within the first day of joining the project.

Keep Your Client in the Loop

As the course of the project proceeds, there will be good news, bad news, and discoveries that your team makes along the way.

To build trust, it’s critical to keep the client well informed.

I don’t know a whole lot of people who think delivering bad news is fun. You need to give unpleasant news to clients as quickly as possible. Being quick to disclose adversity will help to prove that you’ve got their best interests at heart. Hesitating to provide a lousy update can easily be misperceived as your willingness to be untruthful. Clients need to know that you are working for them with their best interest in mind. That means keeping them informed in an extremely timely manner especially when things are going poorly.

Good news can always wait a couple of days or over the weekend. Clients will already be happy with good news so if it takes you a few days to deliver it, there’s not much risk of the interaction going poorly.

The amount of time that passes in-between when you learn of bad news and when you deliver that report to the client is inversely proportional to the amount of trust you will receive in return.

Kanban is for Ninjas

Several times, we’ve run into teams that are working off a Kanban board but are not productive. This experience has illustrated that in 95% of cases, Kanban is too undisciplined for an inexperienced team.

The term inexperienced team may sound like an insult to the team’s cumulative skill set; however, we’re talking about the team’s experience with each other more than any single contributor’s abilities.

For Kanban to work, the team members must be capable of aggressively clearing the value pipeline on a regular basis. If any item on a kanban board is remaining in place for over a business day, extreme measures should be taken to ensure that the team is still on track and capable of delivering.

Kanban reduces Scrum Discipline to an illusion. Humans are not good at performing one task at a single time, and although our computers allow us to attempt to do so, this is the ill-fated decision for any human to fall trap.

The singular act of focusing on the performance of one task is the state of flow. Kanban is reserved for teams that have proven they can stay on target together as a group, self-policing each other along the way.

Advantages to kanban on its face appear to be the relative lack of management necessitated for it to promulgate. Disadvantages include:
– The improper illusion that planning is irrelevant
– Incorrect sizing of work items
– The tendency for the team to take on well beyond what is possible
– Merge conflicts
– Inability to ship tasks to production
– Creation of work silos
– Excessive use of direct messaging
– Other symptoms as yet determined by the Sturgeon General.

The state of Flow.

For a team to progress to a sufficient capability to use Kanban, they must first prove they possess the skills as a group to run a scrum board effectively. The team must be capable of performing without a scrum coach, they must be disciplined enough to keep each other in line, under the gun, to Always Be Delivering Value

Don’t think you’re a ninja

Communication is critical, and remember you’re not infallible. Just because you know the ways of the warrior does not prove that the team around you does. You must show you are ready to graduate to kanban. You must determine that you are all capable of policing each other with the calm of a stormtrooper persuaded by the light side.

Then will you be ready to operate without the much-needed training wheels of Scrum. It’s not your ability, but the cumulative operational fitness as a unit that dictates if you are ready to take your discipline into your own hands.


Subscribe to our annual email newsletter!