Blog

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.

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

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.

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.¹

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 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.

Empathize

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.

Define

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.

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.