What Is Your Mindset?


Whenever I start coaching a new team and promoting an Agile and DevOps approach to software delivery, it is common for some teams to procrastinate or even resist an automated delivery pipeline. Some teams feel it is better to get features manually deployed into production as soon as possible and that the time to develop an automated pipeline will minimize the number of features that can be delivered. 

Of course, this is true. Time is a limited resource, and the time to develop automated release pipelines takes away from delivering “true” features.

Some teams do not think this way. They see the value in investing the time in automation with the belief that it pays off in the long run.

I conclude that a team’s position on this depends on what a team mindset is and what they consider value to be.

Linear Mindset

Some teams view the delivery process as linier manner. Here we manually create our Dev, QA and Production environments. 


We use version control and develop our product in the Dev Environment. When we are ready to test, we deploy the codebase to the QA Environment where the QA Team formally tests the product features. When a release has passed our testing, it is deployed to the Production Environment. 

Automation is not necessarily ignored, but the value comes from getting features into production as fast as possible. Time spent on automation takes away from delivering features into production. 

Teams who follow this emphasize the value of deploying features into production and minimizing that of automation. Their mindset causes them to have this perspective.

Cyclical Mindset


In reality, delivery is not linear—it is cyclical. We want to move through the development and test cycle and into production as fast and as easily as we can. The way to do this is to follow DevOps principles and automate everything if possible. Things that are not automated should be carefully documented. 

A full discussion on DevOps is beyond the scope of this article; however, some general points are highlighted below:

  • Infrastructure as Code – We can define each of our environments in code and store it in version control. This makes it easy to manage changes and deployments. 
  • Continuous Integration – As code is committed to version control, it is then compiled and undergoes unit tests. An artifact is then created for deployment to our other environments.
  • Continuous Deployment – The artifact created by Continuous Integration is deployed to other environments for testing. Integration Tests and Automated QA Tests are executed at this time. Manual testing is also performed.
  • Production Deployment – The same artifact we have been using is deployed to production. If zero down time is needed, we use Blue/Green deployment techniques.

If we expand this over the life of our product, the process looks like the diagram below. This allows us to deliver our product to our customer quickly and with high quality.


It is very hard to do all this automation, and it does take time and money. If you have read this and still think it is not a fit for your situation, consider the following points:

  • It is a very competitive world. If you cannot deliver software to your customer quickly, your competition will.
  • You do not know what your customer needs until it is in production and used. If you cannot deliver software quickly to your customer, you cannot respond to your customer’s feedback on time.
  • When defects are found, you need to fix it fast without affecting the process development.

Teams who have accepted this balance the value of deploying features into production and the value we get by automation. They understand the investment in automation has high value.

Learn More

Some links to more information on DevOps is included below:

Sprint Planning with Jira Using Hours


I have always found it challenging to do sprint planning in Jira when using hour estimates for user stories. This is because Jira does not have tooling to fully support this need. 

Under this approach, the team enters subtasks for each story that includes estimated hours. The total of these hours is the total work necessary to complete the stories in the sprint. This work is compared to the team’s capacity to see what can fit into the sprint. We use 6 hours per day to calculate capacity. 

In our example, we have a team working on a 2-week sprint. This gives us a capacity of 60 hours per engineer (10 x 6 = 60). 


The above team can fit about 180 hours of work into a sprint. We also are assuming a velocity of 29 story points. Our backlog is shown below.


Jira will support our example so far. The screenshot below shows our pending sprint.


The work is denoted by the Remaining value of 177, and the story points are denoted by the Estimate value of 27. Given our capacity of 180 and our velocity of 29, these stories fit into the sprint.

Jira does not support capacity planning based on individual engineers or discipline. For example, we cannot see if we have overbooked individual people or our testing and development specialties.
In the past, I have used an extract into a spreadsheet to support this need. This does work, but is cumbersome and slows down the planning process. The SumUp AddOn provides us with a way to do this without spreadsheets.

Sprint Planning Dashboard

Below we see an example of a subtask for the Login Screen. It has an hour estimate of 5 hours, is assigned to Scott Dev1 and has a discipline of Development.


Subtasks like this have been entered for all of our stories by our team during sprint planning. Let’s take a look at the Sprint Planning Dashboard that was created using SumUp and see if the team is balanced properly.


We can see our allocation of developers is not proper. We can click on the Scott Dev1 assignee to load the associated data. Let’s assign JSP-17 to Scott Dev2.


This looks better. Our developers are better allocated. Scott QA is over-allocated, but we have a cross-functional team so one of the developers will help test.


For teams who do not wish to allocate individuals during sprint planning, we can use Discipline.


This allocation is OK without any changes. The Testing discipline is over-booked, but our developers will help test. 

Setting Up Sprint Planning

A number of things need to be configured for this example to work. A custom field for Discipline must be added to the screens your Jira project uses. A Filter that returns the subtasks for the next sprint must be developed. 

A Dashboard that is used for planning is added, and the SumUp gadget is configured as shown below.


In Conclusion


This does not give us everything other tools provide. We must maintain team capacity outside of the tool and manually compare the Capacity and Work.
Other tools like Microsoft Visual Studio Team Services do this out of the box, as the screenshot on the right shows.

SumUp and this configuration gets us close. It is much better than spreadsheet extracts. I hope this makes your sprint planning easier.

Your Teams Work is Hiding


There is a good chance that the work your team is doing is hiding. If you find that you often ask for something to be done but the time it takes to be delivered does not meet your expectations, this may be the case.

It is very common for a member of the management team to ask someone to complete some task. The person tasked with the work may say he or she is really busy but will be able to perform the requested work nonetheless.


The problem is that work like this piles up in an invisible black hole, and no one really knows much about it.

Toyota Figured This Out for Us

In the late 1940s, Toyota studied how to improve its manufacturing process, and thus a process called Kanban was born. Kanban is a scheduling-based system that identifies a set of queues and moves work through the queues based on need. Kanban was originally developed for a manufacturing process and has been modified to support software.


The above diagram depicts the simplest Kanban board possible, which contains three columns or queues. Tasks are added to the ToDo column. When tasks are being worked on, they are pulled into the Doing column. When a task is completed, it is pulled into the Done column.

All tasks, which are often represented by cards, must be placed on the Kanban board, or they will not be worked on. The Kanban board is visible to everyone on the team. The cards in the ToDo column are prioritized based on the needs of the organization. The Doing column is constrained to only contain a predetermined number of cards—in this example, it is two. There is a short, fifteen-minute meeting each day, where the Kanban Board is reviewed by the team. From time to time, a longer planning meeting is scheduled.

The above paragraph contains some very powerful practices that can dramatically improve the delivery of work and the happiness of the team. Let’s spend more time discussing each of these points:

  • All Tasks Must Be on the Board – People requesting work quickly realize that it will not get done unless it is placed on the board, and thus a process is developed to facilitate this. This is typically some sort of planning meeting where new tasks are discussed and added to the board when the team agrees that it is appropriate to do so.
  • The Board is Visible – Transparency has an amazing effect. If the board is visible, people requesting new work see how much work is in progress, which may cause them to limit trivial task requests. The team doing the work also sees what is in progress. The tasks on the board often have the name of the person performing the work, and other team members are encouraged to help overloaded team members.
  • Pending Work is Prioritized – It is the responsibility of the team members who understand the business to keep pending tasks prioritized. Tasks are pulled from the top of the ToDo column into the Doing column. This prioritization is determined at a planning meeting. 
    This approach stops random requests of tasks that “have to be done right away” from occurring. Remember that all work is on the board, and the board is visible to everybody.
  • The Columns are Constrained – The columns that contain tasks where work is performed are constrained. In our example, the Doing column can only have two tasks in it. The only way another task can be added is if one is moved out, normally to the Done column. 
    A column’s constraints are devised based on the size of the team doing the work and experimentation.
  • Daily Standup Meeting – There is a daily, fifteen-minute stand-up meeting. Everyone on the team actually stands, and everyone makes a short statement about what they are doing and whether anything is blocking the completion of the task.
    It is common for longer planning meetings to be scheduled, where additions to the board and their prioritization are discussed.

Why Does This Work

In order for you to consider trying this approach, you need to already be experiencing considerable pain. Your customers and employees must be complaining enough for you to try something completely new.

This process mitigates the normal human nature of all busy, anxious people. Some of the points I make require a leap of faith and may seem counter intuitive. I provide links in the Learn More section of the article, but unless you are truly convinced, you are probably not ready for this approach.

If you decide to switch to this approach, be sure to have buy-in from senior management. It is also a good idea to hire a good Agile coach who can provide guidance to Agile processes like this.


Transparency makes all things visible. This causes the team to do the right thing without being directly asked. A good Agile coach provides guidance and asks probing questions when he or she notices issues.

The board is posted in a visible location—this could be a central white board or a big-screen monitor. It should be visible to everyone all the time so that everyone can see all the work. They can see what is being worked on and what is planned to be completed next.


The columns on the board that involve performing work are constrained. This is one of the most powerful aspects of Kanban, as it causes people to focus on work and get it completed.

“Stop Starting and Start Finishing”

Multitasking is evil. When someone works on more than two or three things at once, task-switching causes tremendous delays and inefficiency.

Identifying the constraint for a column is not an exact science. It is based on the number of people on the team performing the work. We do not want to “schedule” work at 100% utilization. We do not want to have the team perpetually busy: we want them delivering high-quality work, and we want them productive.

My advice is to start at a utilization percentage well under 100% and experiment with it, measuring how long it takes a task to go from ToDo to Done and not the utilization of individuals’ work.


Meetings are evil. Have as few meetings as possible in order to get the job done.

One meeting I recommend is a short, daily stand-up for the whole team. This should happen at the same time and place each day. Scrum uses this approach. Each person mentions what they are working on and any blocking issues they may have.

Other meetings are completely up to the team. Meetings may be required to add and prioritize tasks in the ToDo column or to address issues that arise at the stand-up. It is also useful to have a retrospective meeting from time to time where the team identifies two or three things they agree to improve on. Make these meetings optional and limit them to 30 minutes.

Getting Started

The columns on the Kanban Board are the workflow steps necessary to get tasks to a Done state. The first thing you need to do is define this workflow. The image below depicts a Kanban board with a simple workflow for delivering software.


The easiest way to do this is to meet with a representative portion of the team and draw the workflow on a white board. Once the workflow has been defined, draw the Kanban board on a whiteboard. Identify the constraints for the columns that require them.

Assemble the team and use post-it notes to identify all work the team is doing. Place the post-its in the appropriate Kanban columns.

For some teams, a Kanban board with post-its works fine. If this is not the case for your team, you will need to select a tool that better supports your Kanban board.

The final thing to do is to schedule the daily meetings and any planning meetings that are needed.
Future articles will discuss how to track progress, so stay tuned.

Learn More

For those of you who still need to be convinced of this approach, I have included links to some articles I have found that prove the points I mentioned.

  • Two good articles on the myth of 100% utilization can be found here and here.
  • Two good articles on the evils of multitasking are here and here.
  • You can read two good articles on making meetings optional here and here.
  • An article on Kanban is here and a good short video is here.

Kanban Software to Consider

All full-feature ALM tools support Kanban as well as Scrum. Most are free or almost free for small teams, so you can pilot something before committing any large sum of money.

A good article that compares Kanban tools is available here


Think Differently When Infrastructure is in the Cloud


If you are fortunate enough to be using cloud based resources, it is cost effective to configure Production Like Environments for load testing. The combination of Infrastructure as Code and the Pay as You Go price model in the cloud makes this possible.

Let’s assume that your cloud based production infrastructure is distributed world-wide and has a cost of $70,000 per month. It is not feasible to replicate this infrastructure in other environments full time at this cost.

The above example equates to about $100 per hour. We do not need load test environments full time. We only need them a fraction of that time. Since is it easy to create infrastructure, we can delete it when we do not need it, and thus we do not pay for it. If we run our load test each night for two hours, the cost of a load test on an environment like production is $200 per day.

So, there is really no reason these days to skimp on lower environments.