Benjamin Brandall – Process Street

All posts by Benjamin Brandall


How to Create a Runbook: A Guide for Sysadmins & MSPs

Benjamin Brandall
September 20, 2017
IT

How do you name a new server, export config data, or fix that one really annoying bug that keeps popping up every 2nd Thursday?

For prepared IT professionals, that information is stored in a runbook. A runbook is a set of standardized documents, references and procedures that explain common recurring IT tasks. Instead of figuring out the same problem time and time again, you can refer to your runbook for an optimal way to get the work done. What’s more, you can also delegate tasks and onboard employees more effectively if you have documentation to train them with.

Whenever you do a task, think of this quote:

“Will you remember how to do these things 6 months from now? I find myself having to re-invent a process from scratch if I haven’t done it in a few months (or sometimes just a few days!). Not only do I re-invent the process, I repeat all my old mistakes and learn from them again. What a waste of time.” — Tom Limoncelli, The Operations Report Card

In short, the less time wasted figuring out how to do a task, the better it’ll be for your business efficiency, productivity, and sanity.

This post will look at runbook examples, documentation methods, and some processes you can use in your own business. Also, it will show you how to use Process Street as your cloud-based runbook for all IT documentation.

First, let’s look at some example runbooks so we can get context on what I’m going to talk about.

The 2 types of runbook

Runbook is a broad term. It can refer to two kinds of documentation:

  • General documentation updated by a sysadmin when new procedures arise or evolve
  • Specialized documentation written for one team, one use-case, or one system

With this in mind, it’s likely that any one IT department or sysadmin will have multiple runbooks that assist with their routine tasks and act as reference manuals for special cases.

For example, to build a general daily tasks runbook inside Process Street you could use this template as a starting point:

Runbook documentation is precise. It’s specific to the systems your company is running, and the custom configurations you’ve made. While the process above can’t cater to your systems and existing procedures, it can act as a demonstration or template you can fill in with your common daily tasks.

As for specialized documentation: this varies drastically for each organization. The below example — Installation Runbook for Palo Alto Networks virtual Firewall and Juniper Contrail plugin for Fuel — contains diagrams, tables and procedures that will guide the user through every step and contingency.

Aside from system-specific documentation, most organizations will prepare use-case specific documentation. The most operationally-vital use-case for documentation in IT will always be disaster recovery, which needs to be executed quickly and thoroughly.

Xtium has released a 33-page disaster recovery runbook template which runs you through example procedures and recommendations for creating and updating your disaster recovery procedures.

A disaster recovery process is something many businesses only make when it’s too late. The top three causes of downtime are power outages, hardware failures, and network failures. How do you respond to these incidents in each case?

For a cloud-based option, you can edit our information security incident response template, for example of one kind of disaster recovery:

How to create a runbook

Every runbook is unique and specific. The actual content will be specific to your needs. The methodology, however, is the same as it is for all process creation. The first stage is to plan which procedures need to be documented in your runbook. When you have a list, you can write them up in detail. After field testing a process, you can make updates and optimizations as necessary.

Author and ex-Google sysadmin Tom Limoncelli recommends that each runbook contains 7 sections:

  1. Overview: Overview of the service: what is it, why do we have it, who are the primary contacts, how to report bugs, links to design docs and other relevant information.
  2. Build: How to build the software that makes the service. Where to download it from, where the source code repository is, steps for building and making a package or other distribution mechanisms. If it is software that you modify in any way (open source project you contribute to or a local project) include instructions for how a new developer gets started. Ideally the end result is a package that can be copied to other machines for installation.
  3. Deploy: How to deploy the software. How to build a server from scratch: RAM/disk requirements, OS version and configuration, what packages to install, and so on. If this is automated with a configuration management tool like cfengine/puppet/chef (and it should be), then say so.
  4. Common Tasks: Step-by-step instructions for common things like provisioning (add/change/delete), common problems and their solutions, and so on.
  5. Pager Playbook: A list of every alert your monitoring system may generate for this service and a step-by-step “what do to when…” for each of them.
  6. DR: Disaster Recovery Plans and procedure. If a service machine died how would you fail-over to the hot/cold spare?
  7. SLA: Service Level Agreement. The (social or real) contract you make with your customers. Typically things like Uptime Goal (how many 9s), RPO (Recovery Point Objective) and RTO (Recovery Time Objective).

The way that’s structured is up to you, but it’d best to put non-interactive documents in cloud storage, and then use a workflow app to record and assign the common tasks.

1. Planning

Which procedures do you regularly execute? Some ideas:

  • Disaster recovery
  • Data backup
  • New user setup
  • Virtual machine troubleshooting
  • Patch management

A runbook should contain your most regularly executed tasks, as well as instructions for complex semi-regular issues with easily-forgotten details.

Our CTO, Cameron, uses Process Street to fire an SSL renewal checklist once every three years (because it’s an archaic and fiddly task), but he also runs daily and weekly checklists for system maintenance.

2. Writing

It’s sustainable and scalable to write runbook documentation in language that anyone can understand because later down the line staff of every level need to be able to understand it for training and onboarding purposes. This means cutting jargon, avoiding abbreviations, and making no assumptions about the skill level of the user.

To create a process, it’s best to actually do the task and record your work. You can do this by taking notes of every button you click, and all of the information you enter, but you could also just record your screen and take notes afterwards. That way, you get a realistic step-by-step procedure that can be replicated by non-technical staff, too.

To summarize:

  1. Choose a process to document (it should be a common cause for error, or a critical regular task)
  2. Start recording your screen
  3. Work through the task as you normally would
  4. Pause the screenshot at each action and note down everything you do (“Open the Start menu. All programs > Accessories > Paint”)
  5. For actions that need more explanation, take a screenshot of the screencast and use it in the runbook
  6. Repeat until the end of the screencast

Make sure to pull together any resources you used while doing the task:

  • Reference documentation
  • Network diagrams
  • Login credentials
  • Config information

Process Street has everything you need to create rich-media processes that include images, videos, sub-checklists, code snippets and more. You can also easily update your processes and have the changes reflected to all users.

3. Improving

It’s one thing to document a process for yourself, but having that process executed by someone else in a real-world situation is a different story. The first time your process is battle-tested, you’ll notice any errors you’ve made by seeing the efficiency and accuracy of the work done.

A good way to improve processes is to be present when the instructions are being carried out, then hand the process off to be updated and used by more general staff.

Process consultant Ian James says that improving a process after it’s documented includes 11 steps:

  1. Get everyone on board. When you’re making changes to the generally accepted way of doing work, it’s likely you’re going to need approval from higher-ups, and time from everybody involved.
  2. Choose the right process to optimize. Which process is causing pains, needs to be handed off, or is too out of date to be useful?
  3. Calculate the time and resources you’ll need. A pitch to upper management will need backing up with data.
  4. Act when the time is right. Process improvement is necessary, but often that’s only apparent in a crisis.
  5. Set expectations for everyone involved. If you’ll need 5 hours per week of a certain team’s time, and expect the project to take three weeks, make it clear.
  6. Offer process training. Thinking critically about business systems is a learned skill. If your team doesn’t have training, prepare by getting them some.
  7. Build the process out in a workflow application. Paper or Word documents will eventually fall flat. Pages can get lost, and collaboration is impossible in Word.
  8. Know why you’re improving the process. Is it because it’s done frequently, has a high margin for variance, or because it needs to be predictable? Categorize the process by this criteria.
  9. Select your team size. Choose a small number of trained individuals to help.
  10. Pick the right team members. The only people who should be involved with optimizing a process are the people who run it.
  11. Get together in a dedicated room. Ian James reports that projects where the team collaborates in a physical space have a 200% higher success rate.

We’ve also put together a process specifically for process improvement:

Running your IT processes with Process Street

Process Street is a workflow documentation platform that lets you document your processes and then track progress each time the process is run. Insert form fields, automation, and supporting files into your process documents, and then assign them to members of your team.

Process Street’s folder structure lends itself well to IT runbooks, and we’ve also got plenty of pre-made processes for IT teams, and integration with ITGlue.

Using pre-made process templates

We’ve put together three process packs for IT businesses:

These packs collect the following templates:

To add a template to your Process Street organization, just click the “I want this for my business” button, and it’ll be automatically copied in.

Whether you copy and modify our pre-made templates or make your own from scratch, you’ll want to create a folder structure so you can easily filter the processes and control access.

Structuring your IT processes

Process Street has folders, sub-folders, and tags. This gives you a lot of control over the way you structure processes in your organization. For example, an organization for multiple departments might have a different folders on their home screen for each department.

In the gif below, I go through the layers of an example structure for IT processes, with the home screen divided up by department and then the IT folder divided into folders such as hardware setup, maintenance, security, etc.

You can create new folders with the green ‘New’ button on the left sidebar. Go inside your IT folder to create subfolders:

You can use the same ‘New’ button on the sidebar to add a template to the folder. For example, you might want to use one of our VPN processes:

It makes sense to organize files into their proper folders, but you can also use folders to control access management. Read more about folders in our help documentation.

With Process Street, you can use and optimize your processes in one central place. This even means you can integrate with tools like ITGlue.

Integrating Process Street with ITGlue

ITGlue lets you set up notifications when key events happen on your systems that need dealing with: SSL renewal, licenses, maintenance, audits, etc. These are linked to your ITGlue documentation, and live alongside the rest of your key IT knowledge such as network structure and inventory.

Process Street can be integrated into this notification system to act as a runbook. For example, whenever your SSL certificate is running out, ITGlue will notify Process Street which will then run a checklist from our SSL renewal checklist and email the person in charge of getting the job done.

Read more about setting up this integration here.

Get started with your runbook

Runbooks make it easier for you to remember the ideal methods you come up with, and to delegate work to a team. You can manage your IT documentation with Process Street, and use documentation templates created specifically for IT.

Get your free Process Street account to start systemizing and scaling your IT operations.

7 Documented Processes for IT, MSPs and System Administrators

Benjamin Brandall
September 13, 2017
IT

Technical procedures — especially those affecting your client’s systems and operations — must always be documented. Details and specifics are too vital for you to just wing it, especially when you’re dealing with long lists of configs, server names, and other easily-forgotten information.

That could be why SOPs (and documentation in general) are so popular and well-supported in the MSP community. Thanks to the wealth of information out there, we’ve been able to put together 7 of the most in-demand IT processes among MSPs and sysadmins.

In post, you’ll get 7 processes you can easily edit, share, and use in your own organization. Since they’re built inside Process Street, when you add them to your account they’re stored in the cloud and provided to anyone in your organization with the right access permissions.

Continue Reading

15 Load Testing Tools, Tips and Methods to Protect You from Crashes

Do you find your website users complaining about it being sluggish at times? Does performance degrade when traffic is high? How certain are you that a new feature or build isn’t responsible for your laggy site? These are questions best answered through load testing.

Load testing is a branch of software performance testing. It involves subjecting a website to simulated workloads that stretch its specified operational capacity to its limits in order to assess its performance.

A slow and vulnerable site can affect your search visibility, user experience, and conversion rate — all of which can negatively impact your revenue.

In this article, I’m going to explain the advantages, goals, and metrics of load testing, and then give you 6 tools and 9 tips to try.

WebLOAD’s dashboard

The advantages of load testing

Some benefits that you get from load testing include:

  • Prevent downtime with analysis. It helps you run various scenarios mimicking real-world usage to gain different insights on your users’ behavior and website performance. This is an accurate and quantifiable way to discover new methods to add value to your website and improve your business.
  • Save money long-term. Although a load test can lead you incur costs it helps you save money in the long run by uncovering emerging problems that you can fix for much less. It also helps maximize your website’s efficiency which saves you from over spending on maintenance.

The goals of load testing

At its core load testing is a means of measuring metrics. It therefore means that there are goals that underlie the quantifying of the specified metrics. Some of the things it seeks to find out are:

  • How robust the system is and more so how it recovers from any errors
  • How efficiently the resources the system has at its disposal are being used e.g. if you have a fast processor and low RAM it means that the hardware resources are under-performing. In such a case load testing will reveal where relevant improvement should be done to achieve optimal output. This is also applicable in assessing efficiency of a website’s resources
  • What hampers the system’s ability to fully handle its work load i.e. bottlenecks

It is important to note that you need to differentiate between goals behind load testing and the means by which you arrive at load testing.

Load testing metrics to analyze

Once you have identified your goals for carrying out load testing, you need to know what metrics to measure. A few key things to look at can include:

Throughput: How much bandwidth a website uses up while conducting the test. It indicates the amount of data sent and received from the servers.

Error rate: How frequently errors occur when a website is processing requests and at what stage they do occur.

Response time: How long a website takes to respond during the highest levels of activity (peak time) and as measured over a period of time (average time).

  • Requests per second: How many requests are sent to the server
  • Concurrent users: How many virtual users are active at any given time
  • CPU utilization: How well the CPU is utilized as the website processes a request
  • RAM utilization: How much memory is utilized as the website processes a request
  • Number of failed or passed transactions: The overall amount of successful and unsuccessful transactions
  • Wait time: How long it takes once a request is sent to when the first byte is received in response

Methods of load testing

There are two general approaches one can use when carrying out a load test.

Longevity testing

This measures the capacity of the system to handle a specific work load that simulates the average amount that a live user handles over an extended period of time. A baseline defining what the optimum work efficiency ought to be is used as a reference point. It is also referred to as endurance testing and is used to check for errors in the system that occur after a sustained period of use.

Volume testing

This measures the capacity of the system to handle large volumes of data in a limited period of time. Subjecting the system to an increasing volume of work helps to assess whether it can competently handle the quantity set out by its developers.

6 load testing tools

The Grinder

The Grinder is a free, JAVA-based load testing tool. It creates the load by using load generators, also known as agents, that handle many workers. It is compatible with a BSD-style open source license. It has flexibility in creating parameters. It also has the capacity to handle various protocols. A console is the central interface through which editing is done and tests are developed.

The console is a GUI application by nature that facilitates monitoring of real time results via the several Grinder agents it controls. It has TCP proxy and can handle distributed testing. It provides complete access to the information generated after a test for verification and analytical purposes.

WebLOAD

WebLOAD is a licensed tool with a free version used in testing large-scale loads. It has capacity to handle complex scenarios and the load itself can be generated through the cloud or on-site. It’s used when testing any web and mobile application or API that deploys Adobe Flex, Oracle Forms, HTML5, Ajax, .NET and others.

It enables automatic correlation, DOM-based recording, automatic bottle neck detection and JavaScript language when scripting. There is a free plan with limited features. The paid plans have flexible pricing and a robust licensing mechanism.

LoadView

LoadView is a paid tool whose unique feature is that it tests in real browsers making it more precise as it can more accurately mimic real-world user behavior. It is cloud-based and as a result has the ability to deliver a large scale, distributed load test.It also provides point and click scripting. While it’s not an open source option there is a free trial feature.

Apache JMeter

JMeter is an open source tool that manages multiple load injectors using a single controller. It supports a variety of protocols that include JAVA-based ones. It has a user-friendly GUI which requires less scripting. It can be loaded onto a network or server to assess its performance under various types of loads.

Testing Anywhere

Testing Anywhere is a tool that enables you to create the test criteria that best suits you via its in-built editor. There are five steps involved in creating any test:

  • Object recorder
  • Advanced web recorder
  • SMART test recorder
  • Image recognition
  • The editor

One common use for it is to automatically uncover any bottlenecks in its early stage of development. This helps you resolve it before the users encounter it.

HP LoadRunner

LoadRunner’s unique advantage as a load testing tool is that it enables you to simultaneously create and manage thousands of users. It consists of several tools namely Virtual User Generator, Load Generator and Analysis and Controller.

It creates a scenario that contains the script to be executed while generating the required number of virtual users. It factors in other specified parameters and generates results. A developer is able to get all the information relating to the infrastructure and performance. It is a paid tool.

Factors to consider when selecting a tool

The best tool is the one that most suits your needs to deliver the best results for your specific context. Things to weigh include:

  • The cost of the license if you opt for a paid tool
  • The protocols you will use. You need a tool that supports the relevant protocols involved for it to deliver
  • How often the vendor or developer updates it and whether there is any support offered in case you run into technical difficulties and need assistance
  • How expensive it will be to train any staff on using it, be it monetarily or time wise
  • The software or hardware that is required to run the tool effectively
  • Whether your client has a particular preference for any specific testing tool

9 tips for website load testing

The best load test that will deliver valuable and actionable feedback to help improve your website is one that you prepare for. Load testing goes beyond just simulating a desired scenario. Here are a few things to do to make sure you get value for your money when testing:

Schedule your testing

The value of regular load tests to consistently gauge your system’s capacity is indispensable. Institute a testing calendar that enables you to receive feedback without going for too long. A recommended period would be two weeks between every test. You will be able to adequately study the results in depth, meaningfully iterate and coordinate for the next test. Such a practice will help you uncover bottlenecks that you can then address before your users get affected by them. Your website will be consistently performing above average as a result.

Use real browsers

Aim to use real browsers as much as possible to generate more accurate results as they better mimic real-world users as compared to virtual browsers. If need be you can add virtual browsers to reach your target.

Set accurate benchmarks

A load test is only as good as the information it delivers when compared to a relevant baseline. Look at what your competitors are doing to help you determine what an accurate and realistic benchmark should be. The closer it is to real-world situations the better the insights you will glean.

Create a team

A well-executed load test can deliver high quality insights that significantly impact your website in a meaningful way. Assign specific tasks to a relevant team member and let them know that they are in charge of delivering on it. Coordinate the who-does-what during a test to foster collaboration. The result will be a test that encounters minimal barriers to its smooth operation. Consider a self-service solution if you have a complete team and a full-service tool if you can’t constitute a big enough team.

Critically analyze your data

A well-timed load test is one that is executed when the website is at its busiest. Study your analytics over the last 12 months to pinpoint when traffic is at its highest point. When testing, aim to go around 20 percent higher than your peak traffic volume to ensure that the website can handle its greatest number of users without significant problems.

Record all information

Maintain a record of all the results generated from each test in a system that is easy for all team members to access. It will help narrow down any bottlenecks that crop up to find the root causes without talking too long. Always monitor your overall infrastructure and servers to stay on top of any emergent issues.

Cross reference the results

Ensure that you match up the results of a specific test to its timeline. Cross reference all the resulting timelines and test results to look at the complete picture when analyzing insights. This will give you a well-rounded understanding of any problematic areas than if you individually analyzed the tests for insights in isolation.

Build up with every test

The best way to find out how the website performs at different load levels is to start small and keep increasing with every test. Compare the metrics you are interested in with every increase in the number of users to gain insight.

Free vs. paid tools

Cutting down on operational costs is admirable for a business but not when it affects the quality of services provided. Avoid using the price of a tool as a determinant in whether to adopt a free or paid one.

The goal of a load test is to mimic real-world user conditions as much as possible for best insights. Assess if you can achieve this through a free tool. If not, a paid one may be an option to consider in order to effectively gather the data needed to improve your site’s performance. The more a load test can copy real-world user behavior the better the results for your website.

Get started load testing

Load testing is an important strategy in making your website more user friendly and efficient. The data gathered from testing in different scenarios provides different insights that help point you to improvements that need to be made. There are varied load testing tools to suit various needs and contexts. Planning your load test and understanding what metrics to look for are key in deriving high value results. A test that is well executed carries significant and material impact on your website and business.

This guest post was submitted by Glenn Lee, Marketing Assistant at Dotcom-Monitor

The Needlessly Complex History of SaaS, Simplified

Benjamin Brandall
August 30, 2017

Look up the history of any modern technology, and you’re taken on a quick-fire tour of antiques, innovations, failures, successes, bubbles, booms, and busts.

Unlike the history of the Roman Empire or Greek poetry, software history is almost immeasurably short.

It’s rich and it’s exciting, but it’s also full of strange developments. Developments that never really went anywhere, but serve as warnings to organizations of the kinds of flops to avoid.

New terminology and seemingly revolutionary inventions have cropped up every single year since the 1960s, but by now most of what formed the foundations for today’s software market is obsolete.

The Department of Defense’s SaaS timeline is broad (and not particularly exciting-looking), but it gets the job done.

In today’s world, the majority of businesses and consumers use software-as-a-service (SaaS). If you define SaaS an application that can be accessed through a web browser and is managed and hosted by a third-party, then Facebook, Snapchat, Google — and many things that most people would just call ‘websites’ — are SaaS products.

Continue Reading

What We Learned Analyzing 281 Full Sales Cycles (1,183 Emails & Voicemails)

Every SaaS company pours mountains of resources into building a sales team, creating efficient sales processes, and optimizing sales emails.

That’s because the most direct way to impact your revenues is by making sure your sales processes are as tight as possible.

But, how can you be sure you use the most effective methods to follow up with leads and close more deals?

Maybe we can help.

In partnership with PersistIQ, we analyzed the complete sales cadences of 281 SaaS companies, from intro to break-up. That included signing up for a whole heap of free trials, and then collecting over 1,000 emails and voicemail transcriptions.

If you want to get proven insights from some of the world’s best SaaS sales teams, build your ideal sales sequence and learn to write emails that close deals, then check out Inside SaaS Sales.

Inside SaaS Sales is a microsite we launched that collects and organizes every single piece of sales communication we received. It’s all there for you to browse through, swipe, and analyze.

With such a lot of data, it’d be silly not to study it to find out the key trends and share that knowledge with you. So, keep reading for our full analysis of the data!

Here are our key findings:

Continue Reading

21 Ways to Use Slack Bots to Simplify Everyday Tasks

Imagine if you had an invisible robot running around the internet doing all kinds of tasks for you.

That’s a bot. 🤖

Bots live on Twitter, on Wall Street and in factories.

They cut down on pesky repetitive tasks and do things that would take humans much more time and energy.

Bots started out as weak, experimental and expensive, but the rise of SaaS and automation means that you can have your very own family of bots, living exactly where you work: Slack.

Slack isn’t just a place to chat with your team, it can be extended to:

  • Check your emails or aggregate your newsletters into a public channel
  • Send notifications from Trello, JIRA, or hundreds of other apps
  • Stream tweets that match a certain hashtag or keyword
  • Update your calendar
  • Save your reminders and to-dos
  • Store company knowledge and resources (like a chatbot attached to a wiki)
  • …and a million more time-saving (and fun) things

Slack is simple, text-based, searchable and allows you to customize it in creative ways. It’s the perfect environment for simple bots that can replace the need for time-consuming or interrupting tasks, and its Slack App directory makes it easy to find and plug a bot right into Slack ready to use.

But, before we get into all of the cool stuff Slack bots can do, let’s get the basics down first and talk about the original: Slackbot!

Most Slack users know Slackbot as the friendly and helpful character that helps them set up their profile. It sits in always-on mode in your direct messages, occasionally popping up to give you notifications. It’s easy to forget, but you’re missing out on a lot of great features if you overlook it.

Continue Reading

9 ITGlue Alternatives for IT Documentation That All MSPs Should Consider

Benjamin Brandall
August 9, 2017
IT

ITGlue is a collaborative, cloud-based IT documentation platform created to help MSPs standardize documentation, create knowledge bases, manage passwords and track devices.

As well as documentation, it lets you stay on top of what’s going on in your network by notifying you when key events happen, like an SSL certificate nearing expiry, or a firewall breach.

Continue Reading

3 Reasons Why Construction Managers Need Workflow Automation (And How to Set it Up)

The following is a guest post by Erin Vaughan. Erin currently resides in Austin, TX where she writes full time for Modernize, with the goal of empowering homeowners with the expert guidance and educational tools they need to take on big home projects with confidence.

Most industries have already acknowledged that workflow tools save their companies money and time, while also promoting compliance and accountability. However, in the construction world, contractors remain stuck in the pre-internet era of paper filing systems and faxed work orders.

They keep their schedules in their heads, have a wallet stuffed with paper receipts, and use “fill-in-the-blank” copies of contracts and work orders. It’s the “if it ain’t broke, don’t fix it” methodology to accounting and administration.

However, this highly manual process means tons of opportunities for human error.

There’s the customer who never got a receipt because the original paperwork for her work order was lost. There’s the client who wants special terms added to their contract, all of which has to be handwritten and added to the back of a cookie-cutter contract template — and a thousand more things that can and will go wrong.

Continue Reading

How We Collect and Analyze Customer Feedback to Improve Our Startup

I didn’t used to see the point of surveys…

I’m much more comfortable with scraping data, using software and relying on trends based on in-depth studies. I didn’t understand how it could be beneficial to read unstructured feedback from a few hundred people until I conducted a survey myself.

It’s not easy to know if what you’re doing is important for your ideal user or reader. You might believe that a certain marketing campaign or product feature is going to be the next big hit that brings customers, but without hearing the opinions of your audiences, you’re making another shot in the dark.

In July, I sent out the first reader survey we’ve done at Process Street. I built the processes and learned the benefits as I went along, and in this post I want to share them with you.

As a result of the survey, we received hundreds of common problems to solve in our articles, allowing us to create relevant and high-converting content. And, speaking of conversions, the follow-up conversations with respondents landed us a few new users and customers!

For a quick email template and a few hours of data entry, I’d say it’s well worth trying. In this article, I’m going to show you exactly how we surveyed our readers, and how it’s helped us improve our marketing and product. But first, an explanation of what I mean by feedback.

Continue Reading

The 11 Agile Processes We Use to Run an Efficient Software Team

agile processes

Maybe some teams can get by without strictly following documented processes every day, but when it comes to agile software development teams, it’s simply not an option to operate in the dark.

Since software is complex and easy to mess up, processes mean the difference between a great product and a crappy one. Without processes, software teams will spend more time squashing bugs and dealing with support headaches than they will actually developing the product…

The exact reason we created Process Street is to help businesses avoid that nightmarish cycle, and, of course, we use Process Street ourselves to help run the agile processes behind the scenes.

We use regular agile processes like:

  • Daily standup meeting
  • Sprint planning
  • Sprint turnover
  • Sprint retrospective

We also run routine QA processes like:

  • GitHub pull request procedure
  • Weekly WordPress maintenance
  • SSL certificate renewal

And, finally, we have a set of training processes:

  • Developer onboarding
  • How to set up your development environment
  • Pull request review failed procedure
  • Pull request merge procedure

These are all regular tasks for the team, and the reason they were created was because we found they have a high margin for error.

Scroll down to find the exact processes we use.

If you want to tighten up the way your software team works, hit your sprint targets, and efficiently train new development hires, then this post will show you how. We even reveal the exact processes we use and a workflow diagram detailing the journey an issue takes from start to end.
Continue Reading

Get Started Free Today

No Credit Card Required