Migrating JIRA Cloud Project from one Site to Another

I have lately been trying and failing in trying to move (or copy) JIRA project from one site to another. One could think that this is so common use case that Atlassian would provide easy tooling for this. But based on quick Google search, this is not as straight forward as one would think. And hope.

The first instructions I found were based on making a backup of your site. Don't do that! If you try to import the backup, you will accidentally overwrite your whole JIRA instance. This only works if you want to bring the project(s) to an empty JIRA site.

But what does work, is the cloud-to-cloud migration that was still in beta when I tried it. With this approach I managed to bring individual cloud JIRA projects from other cloud instances to a common JIRA. In the following section I will tell how to do that and what potential pitfalls to expect.

Prerequisites

Cloud-to-cloud migration has some pretty heavy prerequisites, probably biggest of them being that you need to have Org Admin access rights for both the JIRA you are migrating from and for the receiving instance. I think this is pretty overkill. I hope in the future there would be some much lighter way of moving JIRA projects between sites. That would be possible with Trusted or Site Admin accesses.

Then you need to have the same Apps installed in both instances. This is good to keep in mind, especially if you have some costly ones in the original site. If you can, try to keep the set minimal. Keep it simple is a good rule.

Next, make sure you have same or similar enough custom fields in both instances. I failed my migration a couple of times because I had a validator in the original workflow that I didn't spot first that was relying on a custom field information. I had even trashed the custom field, but the reference was still left in the workflow. I would recommend simplifying your workflows before migrating.

 

Or putting the previous prerequisites into a simple list:

• You need Organisational Admin access for both JIRA instances
• You need same Apps installed in the receiving JIRA as in the original
• Same Custom fields are needed in receiving JIRA
• Check the workflows for validators. Keep it simple.
  

 

The Migration

Once you have done all the preparations, the actual migration should be smooth. For detailed instructions, check this link. In the original JIRA site, go to Settings > System > Import and Export > Migrate cloud site. Choose the receiving site (you will only see a list of sites you have Org Admin rights). Choose the projects you want to migrate. The conflict checker is very user friendly and helps you spot and clear conflicts before you try. If there's no conflicts, review and start the migration. Time it takes depends on the size of the project(s).

 

After the Migration

One thing that we noticed after the migration was that all users who were in the original project got site access to the receiving JIRA. They appeared as having site access, but no product access. In the user administration listing it also seems that these users would have received email invites, but according to Atlassian this is not the case. Never the less, I recommend removing their site accesses unless you intentionally want to give them access.

I hope in the future Atlassian provides a simpler tool for migrating individual projects between cloud instances. And with lighter access rights requirements. I think this must be quite common use case when companies evolve and merge.

Chasing Zero Bug Policy with a Three Strike Rule

Deal with Bugs Early

I claim that the best way to treat bugs is to deal with them fast. I call this the Zero Bug Policy. It means that anytime there's a new bug, development team fixes it as soon as they can. This minimizes the need of categorising bugs or spending time with bug backlog.

Unfortunately teams are often not in such a position that the amount of bugs is zero. Many would probably say that there is no such thing as a bug free software. At least software that has been developed for several years by multiple people and solves a complex real-world problem. Technical capability of the development team, culture, ways of working, staff turnover and many other factors contribute to the amount of bugs. Usually the more moving parts your solution and organisation has, the greater the chance that you will have existing bugs.

Then, assuming you are in a state where bugs have been and are piling up: how do you dig your way out of the situation? One way is to simply increase awareness. If having bugs has been the normal, you need to spend some energy to change the status quo.

Automate Your Way Out

I created a JIRA automation that implements so called Three Strike Rule. It runs periodically and has the following rules:

• All bugs that are found that have not changed status in 30 days, are labeled with Strike1. 
• All bugs that have Strike1 label and have not changed status in 30 days since, are labeled with Strike2
• All bugs that have Strike2 label and have not changed status in 30 days since, are closed/some other action taken.

I have also used JIRA project components and the ability to assign bugs to specific component owners, in most cases team leads. This makes the issues more personal and encourages action. Unassigned issues can be more easily ignored.

Automatic closing of bugs should be seen as something that should be avoided as much as possible. If customer has reported a bug and you close it with some automated message, it most probably is not going to increase the customer satisfaction. But on the other hand, neither does leaving the bugs rotting in your backlog.

With this simple Three Strike action I've witnessed a big decreasing trend in the number of aging bugs. When the rule was first implemented, there were several aging issues, but since then the numbers have gotten lot closer to the Zero Bug Policy for almost all teams.

Kata as a method for Target-Oriented Continuous Improvement

Kata as a word probably first brings to mind the repetitious practice of moves in martial arts. And repetition is definitely the key in that learning process. First you learn the basics of how a punch or kick is delivered. Then, little by little, you get better. You can move faster, the moves follow each other more fluently, there's no need to think.

Kata can be applied also in many other things as a method of target-oriented continuous improvement. The form I will describe here was made popular by Mike Rother in his book Toyota Kata and further instructions to implement the method can be found in Toyota Kata Practice Guide.

First we want to understand where we want to go. What is our vision? This is needed as a north star. It can be something huge and far in the future, but it will help in directing our efforts to correct direction.

Then we definitely want to know that where are we now. What is the current condition? Most probably our current condition is far from our vision, but with the two points we can form a line.

Next we can try to define a meaningful target condition that would be in the direction of our vision. This one should be a bit more realistic to reach within a time horizon of at least couple of months. In enterprise setup the target condition could be at the end of a quarter or year half.

Once we know where we stand currently and have defined our target condition, we probably realise that there is something blocking us from advancing directly to the target. There are things that we don't know and uncertainties. We lack information. This boundary of information is called knowledge threshold. To widen the area of our knowledge and understanding, we can make experiments. Actually a lot of the process is about conducting these experiments. The next part is iterative.

1. We formulate an experiment. Something that will help us increase our knowledge threshold.
2. We list down our assumptions. What do we expect to happen.
3. We conduct the experiment.
4. We list down the results. What actually happened and how did the things go?
5. We analyse the results, reflect and learn from the experience.

Actually those 5 steps are then repeated time after time. As a companion for our experiments we will greatly benefit if we can come up with good metrics to assess our progress. Otherwise it will be difficult to measure if we are actually getting closer to the target or further away from it.

Horizon 3 Development

The following post is not that directly concentrating on software development, but more in the early stage business development in B2B field. The learnings here seem to apply to domains that are a bit slow moving, like maritime and telecommunication. Maybe they can be applied more widely, but I have no first hand experience from others. Would be interesting to hear your thoughts if you have similar experiences from other business fields.

 McKinsey's three horizons is a framework for categorising businesses that are in different stages. 

Three Horizons

Horizon 1 (later H1) is a steady running mature business. One that is no longer growing much, but generates revenue steadily. Aim in this business is to maximize profitability. 

Horizon 2 (later H2) is growth business. It is not yet necessarily profitable, but the engine of growth has been found and there's a good product-market fit. Aim is to maximize the growth while there's still market left. At the later stage the goal is to make the business profitable a.k.a become H1 business.

Horizon 3 (later H3) is new business. Usually far from profitable, maybe even no customers at all. In this category useful metrics can be found from Lean Startup. In theory companies would like to minimize the time spent in H3 and skip this part with as little effort as possible and become an H2 business.

One can see similarities in the three horizons model and Technology adoption lifecycle model. The early adopters are willing to try new things and are willing to accept some 'children's deceases' in the products partially for the possible edge they can gain from the new innovation, partially for the sheer value of being seen as pioneers or forerunners.

The Problem in H3

The problem is that one cannot advance from H3 to H2 without really having a solid, scalable solution. H3 customers might be willing to have a proof of concepts, co-develop or co-create a solution together with the solution provider, but usually customers at later stages are expecting more maturity. And there are two options: you build the basis for scalability while you are still seeking the product market fit with your H3 business or you are late and will have huge delivery pains at the beginning of your H2 journey.

Needless to say, the problem is not that trivial to solve. H3 businesses are usually startups or internal startups with limited resources and budgets. Time is their biggest enemy, because time equals salaries and other operational expences and with a long time to market you probably lose the opportunity window and some competitor gets the customers. The time constraint is the reason companies do sub-optimal design choices that result in non-scalable architectures. Instead of taking the extra time to do things properly, companies take technical debt. And when you reach the growth phase it might be really difficult to find the time to pay the debt back.

What to Measure

In my experience (B2B software development in telecommunication field), the biggest bottleneck is not software, it's customer access. The metric I propose to follow in H3 phase is how deep customer relationship you have been able to develop.

• How many meetings you have had with different people in the customer organisation?
• What are the roles and ranks of persons you have been interacting with?
• How precise questions they have asked?
• How well have you been able to understand the customer's business and identify the customer's painpoints and problems?
• Are you able to provide them with something that helps them
  a) save money
  b) get more money
  c) help them do something they couldn't before

Deepening the customer relationship takes a lot of time. So does finding new customers. That's why testing your ideas might be really slow compared to working in B2C where you can more easily reach many customers (although I'm aware that it is nowadays really difficult to get consumers attention). Keep track of your progress and you are able to make decisions based on data!

Scaling Software Development

Software development is a team sport. It is true that even a single person can make huge contributions (like Linus Torvalds on Linux), but in most cases great results are produced by great teams. In this post I will concentrate on agile software development in a setup where own products are being made. I will try to tell how I would extend the team and what kind of tools or practices could be used.

Staffing the first team

 

Product Owner

Everything starts with an idea. A good rule of thumb is that there's a problem significant enough that it is worth solving. Before coding even a single line of code, make a hypothesis of the possible solution. Then validate it as fast as possible. For example Lean Startup practices might serve you in doing this. Having a Product Owner (PO) might be a good idea. PO can start collecting potential product feature ideas and requirements into a Product Backlog.

Architect

When you are pretty sure that you have an idea worth implementing and you start creating a team, maybe the first person to recruit is the architect. Someone who will have an overall technical vision about structure of the solution.

Coders

Next you probably want to add a few more coders to speed up the development. In the early phase of the product lifecycle it's tempting to divide the responsibilities so that there's a single person responsible for a part, but I would advise against doing so. It will limit the shared code ownership and most probably create bottlenecks. All parts of codebase should be familiar to more than one person.

Design and testing

Depending a bit on the case, next I would get a designer or a tester. If the solution needs to be operated by a user, I'd go with designer. If most of the magic happens in the backend and no-one cares how butt-ugly the product is, then first concentrate on making sure things work. Don't get a tester, but a person who is familiar with testing and can create automated tests. But testers think differently than coders, so better get one onboard.

Now you probably have quite standard software development team. Either get someone who has prior knowledge about agile software development to act as scrum/kanban master or select a person from the team that is most interested to learn the topic. With the help of this person the team will start an exodus to become a self-managing, self-organising cross-functional team that turns Product Backlog items into working software.

Scaling up

 

Splitting

Natural way to scale is to increase the team size by recruiting more and more coders and maybe domain experts. Once the team is so big that regular meetings like daily scrum are no longer efficient, it's time to start thinking about how to split the team.

When you split the team, think carefully how the new teams divide the responsibilities. Let the tech people decide what suits them best. When you have the second team, make sure that also contains all needed competences, including test automation.

Centralized competences

Some roles might not be needed full time in the development teams. It might make sense to centralize these to a different team that can support multiple dev teams. Architecture and design can be such skills that they can be in a common team.

When the work is divided between multiple teams it is also a sign that your operations need to raise to a new level of professionalism. It is a good idea to recruit someone to take ownership for the documentation. Security is also more important and maybe worth having someone concentrating on it. And since there are multiple teams (possibly) working on the same codebase, someone should spend a bit more time on setting up proper integration and deployment practice. Also it is worth thinking about how the teams coordinate and synchronize their work. Some scaling framework could be beneficial. For me Scaled Agile Framework is the most familiar. It also provides guidance on how to plan and execute things when you have multiple teams and also implement continuous improvement.

Get going

When you have recruited people to fill more than one development team and staffed another team has some centralized capabilities, it is time to plan how you shift the gear. This part requires a bit more effort on planning and discussion. I find it practical to have a person write down instructions that offer not too much, but enough details about how the new setup works. Then it is time to just agree on starting day and get going. Execute the initial plan, stop to reflect how did it go, adjust and repeat. That's how iterative and incremental practices work.

Tools

There are some tools that have become almost industry standard for supporting agile software development. Some tools have a lot of different features integrated to them and can handle a big part of the development pipeline. But I will give here an example of pretty traditional setup.

Backlog handling

For handling the Product Backlog, a pretty easy choice is Atlassian Jira. You can create and prioritise backlog items, track bugs and follow progress. If you are using Scrum, Jira offers possibilities for having burn down charts for your sprints. You can also easily visualise the workflow with kanban board and customize the columns to reflect your development process steps (like coding, code review, testing, etc.)

Version Control

The only version control tool that I would recommend is Git. There are multiple commercial tools that you can use that offer different additional benefits. Here are a few: GitHub, BitBucket, GitLab. Access rights control to the source code is probably the main thing, but maybe next in line is the possibility to use pull requests. Instead of pushing things straight to master you should consider a workflow that fosters shared code ownership and transparency. Code should be reviewed by someone else than the writer before merging.

Continuous Integration

Some Continuous Integration (CI) system will help you to automate your process. If the code needs to be compiled, the system will do it. In addition it can start the execution of automated tests, usually starting with unit tests. Some examples of CI systems are Jenkins, Drone, Bamboo, CircleCI, TeamCity and Travis.

Static Code Analysis

For static assessment of your codebase quality I would recommend adding a tool like SonarQube to your pipeline. It can help you measure how readable your code is and how good your test automation harness is. It will cover also security vulnerabilities.

Deployment 

Then you probably need some place to deploy your solution. Either you invest in hardware or you use cloud services. The most common public cloud platforms are AWS, Azure and Google Cloud. If you are using containers, you can orchestrate them with Kubernetes. If you can spend a bit more bucks, you can use an enterprise solution like OpenShift.

Documentation

Quite a standard way to build and maintain living documentation is through Confluence. Pages have version control and editing is very similar as in Wikipedia. They can be exported in multiple formats, such as pdf, word or html.

Possible pitfalls

 

Recruitment

If creating awesome applications and products that users love would be easy, everyone would do it. But it's not so simple. For starters, there's a shortage of skilled workforce. This means that people who know the craft also know their value. And since the whole world is getting digital, there are lots of companies that are willing and able to fight for the talent and offer high salaries and different perks. So, even if you can recruit a team, you might lose members because some other company 'buys them out'.

Culture

Another thing to understand is that the results that an organisation is able to produce are a lot more dependent on how well the people work together than how good the individuals are. It doesn't mean that you can achieve great results with mediocre people. But it does mean that even with highly skilled persons you can fail miserably if they don't get along. Culture makes a huge difference. If people feel safe to show their vulnerability and admit mistakes, everyone will benefit. With retrospectives and conscious continuous improvement efforts teams and teams of teams can raise to a whole new level of performance.

Edit 1: Added some sub-headers for easier navigation of topics.

Story about Software Lifecycle

This is a tale of a software lifecycle. It's fiction, but into what extent - I won't tell. It has been inspired by real events.

The Beginning 

About seven years ago a big consumer company wanted to renew their customer web portal. They didn't have own software development department, so they hired a team of external consultants for the task. Consultants came from two different companies. One was a smaller company with senior specialists. They did the architectural design. The other company was bigger. Already from the beginning the plan was that the bigger company would maintain the portal. Their developers were less senior, but the plan was that they would learn during the building phase.

The portal was a big success. It even won prices. When the intensive building period was over, the smaller consultancy company went to do other things and the other company began to maintain the portal. From now on I'll call them supplier (or team A).

For quite a few years everything went well. there was one person on the customer's side who was in close contact with the supplier. Supplier had a dedicated team and an architect/scrum master. New features were being built and things worked smoothly.

Maturity

Time passed. The customer relationship was so intense that at one point the architect needed to blow the whistle and take some time off. The person was replaced by another architect. The developers who were involved in the early phase were also in the early phase of their careers. And it is quite understandable that after a few years they wanted to do something else. Some changed roles, some went to work in other companies. If you are familiar with the job market in software industry today, you know that there are plenty of opportunities for skilled developers. People can easily vote with their feet. From maintenance point of view this is a real pain.

New people, who weren't familiar with the codebase, had a big struggle getting into productive mode. Without really rigorous attention to architectural quality, software tends to get more complex and more difficult to maintain. And when this is combined with staff turnover, the overall architectural picture gets lost.

Unfortunately, when there are no senior members in the technical staff, the balance between business and technological needs gets disturbed. Business grieves features and visible things. For the business, development speed (how many new features you get with x amount of money) and performance (how quickly things happen when you click) are relevant. What happens behind the scenes is not. The development team should speak out for the technological needs.

There's a dependency between development speed and codebase complexity. With low automated test coverage and high coupling, introducing new changes is always a potential source of unwanted regression. But for a person observing the development from the outside, this simply appears as slow and costly development that produces poor quality.

Back to the story. The customer didn't want to spend so much on the maintenance and so the supplier scaled down the size of the development team. Or the team size was kept about the same, but they were working for another customer. Organizational changes happened on both sides, with the customer and with the supplier.

The customer was unhappy with the development results and felt that they needed to take a tighter control. Team was heavily micromanaged. Daily scrum meetings turned into reporting and command and control sessions. The development team didn't like this and it accelerated the staff turnover even more.

The Renewal

The supplier had seen that it was getting very difficult to find people who were familiar with the technology. Without consulting the customer, they made a plan how to renew the portal to current technology. The benefit would be that there was much more skillful labor available in the job market and that the development speed would increase dramatically. The software architecture had deteriorated into a big ball of mud, but by applying certain changes, the user interface could be separated.

Due to the understandable lack of trust, the customer had hired an external consultant to aid them in technological decisions. Actually this person was also one of the people who originally participated in making of the original portal. Thus he knew it well and didn't see a need for changes. The supplier was trying to push the idea, but things got postponed. After six months, the supplier had hired a technology guru who could fluently demonstrate how the changes could be implemented. It changed the customer's mind. The plans were the same, they were just presented smoothly by a charismatic person.

When the renewal project finally got green light, the customer insisted that there would be a "dream team" working on it. There would be team members from the supplier (let's call them team A) and team members from the other smaller company (let's call them team B). Architect and scrum master were appointed from the smaller company and the customer acted as the project manager. Customer strongly demanded that the development should take place on site, in team B's premises. 

Before the actual development started, there were planning meetings where the plan was discussed, argued and fought over. Architect from team B questioned all design decisions that came from team A. During this period both the technology guru and the most senior developer in this new technology resigned. They had made their decisions about how fruitful the co-operation between the companies would be and didn't want to live in continuous argument.

Team A had had a team lead who was the main contact between the customer and the supplier. But for this project the customer said that they didn't need his services, since the customer's own representative was managing the project. Team A also had an architect, but he was stripped of his power, since the achitect was appointed from team B. During all this time, team A was still contractually responsible for the portal.

Teams didn't collaborate that well and the project fell into crisis. Even though there had been numerous planning sessions before the project started (that were mostly used for arguing), the plan regarding the user interface was still rather abstract. Stories had not been refined and for example the styleguide for the whole site was only one story. The work estimates were too small, since they were given by more senior people than who were left in the team.

The End

The team lead, who wasn't needed for guiding the project, resigned. This wasn't communicated with the customer. Soon the whole renewal project was cancelled. The customer made a decision that they would end their contract with team A and team B would maintain the portal in the future.

Learnings

There are probably quite a few things to learn from this and mistakes were made in many occasions. But here are at least some takeaways:

• Pay attention to technical quality. Feature development is important, but without proper code and architectural caretaking software will rot over time.
• Technologies have lifecycle too. I dare you: try to find COBOL or Smalltalk developers. Make a plan for renewal early enough.
• You catch more flies with honey. If you want people (your own employees or suppliers) to walk the extra mile, treat them properly. Collaborate rather than command.
• Or from the supplier perspective: if you are faced with a challenging customer relationship, add a buffer role into the interface. Some people might even enjoy the challenge.
• Don't pit suppliers against each other. Rather insist that they collaborate.

End note: Hopefully the story made you think. If you see events around you that resemble this story, be careful. It's never too late to change the direction ...until it's too late.

Photos by Ariel Besagar, chuttersnap, frank mckenna, Matt Botsford & Filip Mroz on Unsplash

Value Stream Mapping SIPOC

I was this week in a workshop where we were introduced to a nice set of lean tools. 5 x why, fishbone and kano model were visited briefly, but most of the time we concentrated on value stream mapping. To share the knowledge I will tell you about it in more detail.

We used SIPOC model. The abbreviation comes from the words

• Suppliers
• Inputs
• Process
• Outputs
• Customer

In this example we were creating a breakfast toast for one of our family members. So customers in this case were husband/wife or child.

Outputs can differ if the different customers (or customer segments) have different needs. In our case the child wanted a toast with jam and special attention that the toast isn't burnt. Spouse wanted a cheese sandwich and all the facilities need to be cleaned. No crumbs.

Inputs are all the things we need in the beginning. In the toast example we need a plate, knife, jam, cheese, butter, bread (two different types) and heat.

All the inputs have a supplier. In this case we were thinking where in our kitchen they are located. Not really who made the knife. But the knife is in drawer, butter and jam in the fridge. Heat is provided by the toaster and plate in the cupboard.

Finally, when these pretty evident things are covered we can start to think about the process. WHAT activities are needed in order to create the desired outcomes? We first make a line of post-it notes that define the activities. We can label the different activities with different colors. In our case we used green for processing, yellow for transportation, blue for storage and red for inspection.

Each WHAT phase is broken down into HOW parts. For example toasting phase can be broken down into activities of setting the temperature, putting the bread into the toaster, setting the toaster on and the bread being heated.

We used heart shaped post-its to mark all the value adding phases. In any process there are activities that add value, activities that are necessary but not value adding and thirdly activities that are waste. By identifying these we can measure how much of our activities actually are value adding compared to the whole time used. This performance indicator is known as Value Added Ratio (VAR) or Process Cycle Efficiency (PCE).

PCE = Customer Value added time / Process Cycle Time

As in our example the spouse explicitly wanted to have no crumbs, we tracked all the parts where crumbs could be produced. These phases were connected with a string. This way we can only concentrate on improving those parts to minimize the amount of crumbs.

Finally it makes sense to identify your customer touchpoints. You can goof off in many parts (well, better not to too much..) but you should make sure that you handle the customer touchpoints with care. Think about what happens before, during and after the touchpoint. How does the customer feel?

There you go. A crash course to value stream mapping using SIPOC method. If you want to learn more, I encourage you to find a lean consultant or simply try it out. I know I will.