The Risk of Unconventional Career Journey

Unconventional career journeys are risky

Often recruitment is numbers game and very staged. Recruiters are scanning through hundreds or even thousands of profiles and they have a specific criteria they compare those profiles against. Does the applicant have more than 5 years of experience in the craft? Have they been in supervisory role before? Have they managed managers? If any of the box goes without tick, in most cases they take the next application. 

Of course market situation also affects this, but if the company has got traction and there are enough applicants, this is how it goes. So without proper experience you don't even make it to the interview stage.

Box without a tick -> next applicant. 

There are less opportunities for generalists 

Because companies (and especially software engineering organisations) are traditionally built as they are, they follow this pattern: engineers (individual contributors) report to a team lead or engineering manager. These teams are then gathered into engineering departments, groups or tribes that are led by a director. Group of groups is then possibly called a unit and led by a vice president. The title for the highest ranked person depends on the company size, but could be "Head of", "Senior/Executive Vice President" or "Chief Techonology Officer".

When recruiters are filling these higher ranked roles, they are checking how the candidates have succeeded in the roles on the previous ladder. How successfully have they managed other managers or other directors? How long they have done that and in how many companies?

In this case people who have spent time in other functions (like being Product/Project Managers) or horizontal roles (like Agile Coach) have disadvantage. Their experience isn't immediately recognisable as beneficial for the role at hand. It's nice to have, but not fulfilling the requirements.

Sometimes the risk pays off 

There are roles that combine requirements from multiple crafts. Two possible mentions could be Product Engineer and Chief Product and Technology Officer (CPTO). Product Engineers are often people who are the first employees or founders of a tech startup. When you need to have someone who is able to think what the users need and turn that into a working application. With the latest advancements in AI and assistive technology, this might become more easy. If you have proper customer understanding and can explain it in words, tools like Copilot and Cursor can help you do the rest.

AI might change the game. 

CPTO role is another where two crafts come together. One needs to be knowledgeable about product management and be able to transform customer requirements into a roadmap and drive the implementation. Probably this role is more common in smaller companies, but could be considered also in bigger companies when a strong execution focus is required. And when the leadership team needs to be able to trust one person with the ownership of results. These roles can be opportunities also for generalists.

My story

Personally I feel like I stepped into the trap of being stuck on the generalist path for too long. I was once in a situation where I almost got to lead a department. I had carried out the organisational change, recruited the team leads and communicated what is going to happen. But then, when the new organisation was announced, I found myself somewhere else than in the head of this new department. Maybe the main learning was that one needs to be in really good terms with the decision makers in your 'homebase'. This is why I also see working abroad, far from the company headquarters, as a personal risk to anyone doing that. Out of sight, out of mind.

Don't forget to which organisation you report to. 

And I have had a bit too much agile coaching in my CV. People are offered positions that reflect what they have in their existing journey. Not what they are looking forward to doing next. That's why making a career shift is so difficult. If you want to do that, be prepared to take the long road. When you don't tick the previous boxes, (in most case) you won't stand a chance. 

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.

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

SAFe Evolution

I have been involved with SAFe for about five years now. We first started by taking inspiration from Dean Leffingwell's Scaling Software Agility book. Then we bumped into the SAFe big picture. I think it was something like version 2.1 back then. There were still HIP-iterations in the end (H stood for hardening) and the model was talking about Potentially Shippable Increments and Releases.

SAFe 2.5, Leffingwell LLC

Originally I fell in love with the simplicity of having on one level sprints and on another über-sprints. We were building new releases of our product a few times a year and wanted to speed up. Also, we were having quality issues due to scope extensions and schedule slippage. Our story has been presented in this case study.

Version 3.0 made it more clear that we don't have a separate value stream for architecture and business. I guess it was also due to popular demand that the hardening was dropped from the end of the release period. I still think it was quite realistic and would be for an enterprise that is new to agile. Things don't become fully automated over night. I became certified SAFe Agilist during the 3.0 version.

SAFe 3.0, Scaled Agile Inc

I had mixed feelings about version 4.0. I was really happy to see the Customer in the big picture for the first time, but adding yet another layer (Value Stream level) seemed like too much. That was probably mainly due to the fact that I weren't involved in such activities where so many layers would have been needed. In a way, I think it would be possible to add even more of these levels. After all, we are talking about scaling.

SAFe 4.0 was very handy when you hid the Value Stream level. Of course you need to make decisions based on economics in all cases and you want to apply agile architecture, but you can do it even if you don't have it in the big picture. Communities of Practice were also a welcome addition. You probably want to have some support groups for people who serve in similar roles. That's how you can benefit more from organizational level learning. During the 4.0 era I got certified as SAFe Program Consultant (SPC4.0).

SAFe 4.0, Scaled Agile Inc.

As with previous changes and additions, the new version SAFe 4.5 brings both welcome additions and things that seem to be added mainly because they are current hype. The ability to customize your big picture: Essential, Portfolio, Large Solution or Full SAFe is really good thing. I bet many companies can do with Essential or Portfolio SAFe. But it's a good thing that the more complex versions are available too.

SAFe 4.5, Scaled Agile Inc.

Then what I don't really like (this is my personal opinion), is the fact that SAFe is getting more bloated. I think in the core things are about scaling, cadence and transparency. The power triangle that makes a distinction between content, process and technical quality authority (PO, SM & Team or PM RTE & Architect). I see no need to add DevOps practices, Lean UX nor Lean Startup practices here. They are fine practices that I appreciate and use. But for example in teaching Leading SAFe course, they make things more complicated. Also, due to the fact that the slides covering those aspects don't really include much of instructor notes, I kind of feel those topics are still in an early phase.

Special rant from many of my trainees: THERE ARE WAY TOO MANY ABBREVIATIONS! MMF, WSJF, CoP, FAB, RTE, STE, CoD, CALMR, MTTR, WIP, CI, CD, CE, BUFD, MBSE, KPI, ROI (...maybe you get the point). Some of these are industry standards, but if you bump into these for the first time during your Leading SAFe class, you have quite a mouthful.

As an end note, I feel SAFe 4.5 is great, but there should be a clear separation between the core practices (regardless of configuration) and such additional practices that simply underline that SAFe is a collection of different IT industry best practices. Which it clearly is.

Designing an Organization

In software development there's a common phrase that you should employ the best people, treat them well and get out of their way. What is many times forgotten is the fact that even the best people need direction.

If I think about a company/department/any organizational unit, I'd like to know what is its goal. (One could maybe also call it a Vision.) What is it trying to achieve? What is the purpose for having such unit? It's not mandatory, but beneficial, if the purpose for existence is noble or somehow larger than an individual.

Once you have found your purpose, share it with everyone. Talk about it continuously. Make it clear for all who are involved. Next, think about what matters would be needed to pursue the shared vision. What kind of organization would be most capable? What roles should different people take?

Then staff the organization. For each person, make it clear what is their purpose. How do they help in reaching the common goal? Do it in a transparent way so that others will also understand. Now you can let the magic happen. If you are in an expert organization, each person should know best what they should do. Or at least better than their bosses.

And don't think you're done. You will never be. Even if you don't like it, the world around you changes. You will need to adjust your goal. And your organization. Rinse and repeat.

Defining and Documenting Processes

I have previously been a process owner. I've improved existing processes via different tools and techniques. Audited practices and interviewed actors, even chopped down the activities to a value stream map. But never before (that I can recall) have I been involved in the definition of a process.

In this case the actual process exists (people do actions in a certain order and with a desired outcome in mind), but it isn't documented. There are neither no metrics defined to see if the process is working fine or not.

To be honest, there is documentation. The problem is that there is too much documentation and it's scattered around different places in the intranet. So, in this case I'd be willing to abandon the old documents, try to extract the current process through interviews and workshops and write it down as simply as possible. Fortunately there are very nice tools available in the parent company that can be utilized.

Some general tips to avoid pitfalls (that seem rather common):

1. Keep things simple. Don't go too much into details.
2. Integrity. You don't want to have 18 different ways to describe a process flow.
3. Visulization is power. Figures clarify the message.
4. Somebody should have ownership of the documentation. That will help keep it alive.

 The list isn't exhaustive. But it will get you started.

Reaching the Next Level

When a new programmer starts writing code, s/he requires detailed specifications and clear requirements. The understanding is on a level "I need to get this piece of code working". There's not very much thought given on what happens outside this routine or how things are connected.

On the next level, the coder understands that the piece of code s/he's writing is a piece of a larger system. This system exists for some purpose, but the purpose isn't necessarily clear for the person. But generally s/he understands the system is important for the company and probably generates financial benefits (i.e. is sold).

Reaching the next level is already quite challenging. At this point the developer starts to think about the customers' business. How do the customers make their money? (...that can be then invested. Maybe in software. Maybe even on the solution you are developing...) And when you understand how the customers make money, you understand their priorities and needs. What is important for them and critical for their business.

There might be intermediate levels between the ones I mentioned, but I think this covers the basic steps. I'd encourage all developers to try to advance on these steps. The higher you are, the better you can fill your customers' needs and thus the more valuable you become. I'm not saying that code writing is easy. I'm simply saying that being able to write code AND understand the business is a tad harder and rare. Development on this path starts from understanding the user. 

(Sometimes the decision maker for software purchase is not the same as the user. Users might be only influencers in a complex network. But let's leave this out of scope for now. )

How to Set Up a System Testing Team

In my previous post I touched the topic of legacy modification. It is a difficult stunt to pull. Or well, in a perfect world with a well maintained codebase and outstanding automated test coverage it could be easy, but in reality I think that's rare.

One of the things that makes modifying legacy software especially difficult is the regression. When the system is strongly coupled, almost every little change can produce unforeseen consequences. (Yes, the Butterfly effect!) To counter-attack the diabolic regression effects your best bet is to invest in a test automation harness. But until your test harness is truly solid, you need to make do with manual testing.

In our setup we have two distinct periods: the Development period and the Stabilization period. During the Development period our scrum teams work normally in sprints. They concentrate on creating the new added value that has been agreed on in the Release Planning. Adding new code into the mainline is guarded with automated tests (unit tests + system level tests) and only allowed through pull-requests. Unfortunately due to the limited coverage, this is not enough to guarantee that things stay in good shape.

Development

Development

Stabilization

During the Stabilization period we stop adding new features and concentrate on testing the existing functionality. In practice this means testing manually those parts that are not covered by the automated tests. (This might be called classic hardening anti-pattern and frowned upon, but in this setup it's a must. New development meets Definition of Done, but it's the regression that gives us headache.)

Now this setup sounds a bit dumb. Why do we let the quality deteriorate and problems creep into the mainline and wait to be uncovered during stabilization? Wouldn't it be wiser to detect the problems early on?

Well, that's why we came up with System Testing virtual team. At least now in the beginning it consists of each teams' tester and scrum master. Reasoning behind this resourcing is that testers should naturally be interested in their product's overall quality. And unreleasable software is a really big impediment, thus the scrum masters. The concept is actually quite close to Scrum of Scrums. One main benefit is also that the teams will become aware of what the others have been doing.

The virtual team will meet biweekly for a full day of testing. Each day will be like a mini sprint: beginning with a planning session and ending with a review and retrospective. There's still plenty of forming and storming to do, but I have really high hopes for the activity. Already during the first session they were able to catch tens of bugs that would have most probably otherwise stayed under the radar (at least) until the Stabilization period!

Paved with Good Intentions

How Local Optimization May Result in Failure 

Sometimes when you remove a rusty bolt from a system of nuts and bolts and clean it up, it may not fit the original context anymore. In the course of time the rust has become part of the system and should be also taken into account.

In a complex software legacy system this phenomenon may manifest when a certain subsystem is refactored or rewritten. Technically the new part may be superior and fulfill the original specifications, but the changes may still result in nasty regression issues. During the past years the layer of application logic has been built on top of the faulty behavior (the rust).

Same applies in organizational context. High-performance team may outrun the system around it. It may produce results faster than the other parts can consume. This can create queues and waste. Results can be even worse when the sub optimization happens on the unit level. For example when R&D is able to produce results faster than can be delivered or specified.

Usually increasing performance is desirable, but some gotchas should be avoided. If you  want to remedy the possible problems, I’d suggest a system view. Try to improve the overall flow of value through the system. Tweak the parts, but don’t fall for the local optimization. Aim to decrease the lead time and measure things from the customers’ perspective.

Importance of Environment in an Agile Transformation

I attended today a SAFe 4.0 event arranged by a Finnish training company called Nitor Delta. As a guest speaker they Michael Stump from the Scaled Agile Inc. The event was also a good meeting place for SAFe practitioners. I must say that I saw quite a few familiar faces. And met many new people who I can hopefully later exchange experiences with.

After writing a case study, my company has drawn a lot of attention from other (potential) SAFe adopters. I have a bit mixed feelings about it. Of course I'm happy and proud about the attention, but being a Finn, it's difficult to handle the situation. And then again, since I see all the daily difficulties we deal with, I sometimes feel tempted to say "..but we still face these difficulties". But maybe there's no need. I guess everyone understands that things are in reality much more complex than in theory.

From http://finnishnightmares.blogspot.fi

But from the conversations that I participated after Michael had finished his presentation I learned that environment matters a great deal in SAFe/Agile adoptions and transformations. First I was somewhat against the idea of training everyone at the beginning of the adoption process, but maybe my first impression fails me there. In some cases I think even training is not enough, but some people should get their brains totally rewired. I mean, if you have done something in the same way for decades (or even years), it could be overwhelming to modify your daily routines.

If I think about possible factors why the transformation was successful in our case, I could easily list at least a few. There was a big management support. Previous and current heads of R&D were supportive for the idea and also the Chief Quality Officer. I think also the CEO saw potential in the new practices.

We had already been trained in Scrum when the big organizational change was initiated. All developers had received training in Scrum essentials and every Scrum Master and Product Owner was certified. Scrum Master and tester Communities of Practice were also formed right at the start. So good practices had distribution channels.

Release Process was established even though at first we didn't plan the releases. But the decision to shorten the release cycle was made. Release Manager, a person who would facilitate the release planning and execution was also appointed right away.

Then I think a big deal of the change can be credited to a couple of champions. People who were in key roles (RTE, Owner of Software Development Process, Chief Portfolio Officer, line management of R&D) made big contributions. Having a vision of how things could be done was important, but just as important was the support from these champions. And finally the support and engagement of employees. Everyone wasn't eager to embrace the change at first, but enough many were.

During the conversations with other companies I have realized that there are other, more subtle things that supported the transformation. Some that I had never even thought of since they are rooted so deep in the culture and operations. The organization is not flat, but there are exceptionally good possibilities to access information, suggest new ideas and to participate in the decision making. Also the developers are treated as experts. And there's one company value that I hold in the highest respect: Enjoy Working Together.

In the development money is not an issue. I mean, there's no unlimited budget, but people in development get to fully concentrate on the contents. If something is considered worth doing and there's clear potential, it will be done. There's no sharing of the blanket between different business units. (I have never needed to worry about CapEx or OpEx.)

As a conclusion, I think there were quite a few things that made the transformation possible. Some are such that people living inside the system do not even perceive. In a way I'd be tempted to say they don't realize how lucky they are. So let me conclude my post with a few pictures.

Office Breakfast

Foosball table

Hackathon trophy

Software Development - More Than Coding

Think about software development. I'm assuming you have an image of someone writing code in your mind. Well software development is that, also. But it's also much, much more.

In my company I'm responsible for the software development in this more broader sense. When I think about software development, everything begins from the customers. Developing software is solving customers' problems. Selecting what problems to tackle as a company is a strategic choice. Strategy narrows down what you develop and helps the company focus. Probably it also states in which markets you want to compete in.

Strategy helps the company define it's portfolio. What customer problems we want to solve and what kind of solutions we offer? The solutions can be products or services. Strategy should guide you in this. If it doesn't, refine the strategy.

Let's now assume that in your offering/portfolio you have product(s). Each product should have a vision. What the product will be in the future? What customer problems will it solve when it will be in it's ultimate, final form. (This form will never see the daylight. Vision serves as a distant goal, something to strive for. It's an idealisation that will be even more magnificent when you get closer.)

Vision will help you define a roadmap. Where as vision can be hazy, the roadmap should be really concrete and tangible. I think of roadmap as a guidebook for the next steps toward the vision. If your strategy is planned for the next 5-10 years, roadmap could cover maybe 3 years. It's worth noting that it's still a high level plan and as for any agile plan, subject to changes.

In software development roadmap is implemented in releases of new software versions. They are usually developed in iterative and incremental fashion. Old functionality is modified and improved with new features and bugs and defects are fixed. Many times companies try to shorten their release cycle. The ultimate case would be Continuous Deployment where every change would be deployed to customers. But this is very much industry specific. In some cases the overhead of taking new software version into use is so big that customers don't want to do that often. Then it's practical to select a release cycle that suits both the company and the customers.

In agile development, software is usually created by small teams in an iterative fashion. The length of these iterations or sprints is usually limited to less than a month, a little bit depending on the selected methodology. Sprints are like mini-projects; they are planned, executed and in the end there are sessions for examining the results and for learning from the experience. ...and then cycle starts over again.

Daily work in sprints is carried out by the development team. Developers are experts in their field and select the most fitting methods for the implementation. They have the authority for carrying out daily decisions.

We got to the part where the coder writes source code. But as there are many layers in onion, there are many layers in software development. Writing the code is just one of them. Never the less, it's an important craft if the software is to be of any use and even more so if it is to be maintained.

Developing Metrics for Development

Last month I wrote about my intention to try Cycle Time as a metric for software development. Back then it was still hypothetical, now it's real. Maybe it's still a bit early to draw any final conclusions, but it's already evident that I failed miserably in communicating the reasoning behind the change. And the criticism is well deserved.

I selected the average Cycle Time during past month as the metric for each team. In a way it is a good metric and gives indication about how quickly the value was realized after the work on a backlog item was started. But all backlog items aren't equal and also work type and intensity differ during the release cycle. In the beginning of the release cycle teams mostly work on the new development. Nearing the end the period emphasis is shifted more towards testing and bug fixing. Issue life cycle tends to be much shorter with bugs than when creating new functionality.

It is also questionable if one monthly average number can help in decision making, in essence serve as an actionable metric. You can see the trends in longer time intervals, not much more than that. Another angle is that a team can be really mature and produce outstanding results even though they don't split their Stories into very small parts. Their average deviation can be small and thus predictability high.

Then again I feel that the metric got a little unfair criticism when it was compared with Lead Time. In the end the company is interested in how the customers experience our products and services (Customer Experience = CX). But this includes many topics that are out of scope for software development. Like the company brand(s), how salesmen conduct their business and how the customers are served by the customer service. I think the software development part of the system (company) can greatly affect the User Experience (UX).

 

I would love to get the big picture correct. So personally I feel that the CX is more important than UX alone and Lead Time more important than Cycle Time. But in both cases the internal part is relevant component of the whole and deserves a metric of it's own. (It would be so cool if I could somehow bundle measuring UX and Cycle Time somehow... Probably there's no such easy connection. I think relationship between Lead Time and Customer Experience is much easier to show.)

Now the current bleeding edge is to try using the whole information provided by the JIRA Control Chart instead of simply one number. I haven't yet figured any cons, but on the pro side you get trend lines of where the performance is developing and standard deviations. Of course you can still identify the release cycle from this data, but you can draw other conclusions too. Increases in rolling average or standard deviation can signal trouble. And when the figures are followed regularly, the team can be aided in a timely fashion.

 

Currently I feel like I'm making too rushed decisions. I'd like to involve other people more and ask for their input already before I make an experiment. Now I mostly just measure the impact and make amendments, but I'd like to concentrate on this more. Let's see if the Santa Claus and New Year will bring a difference. In case this will be my last blog post this year, I already wish you all Merry Christmas and Happy New Year!

Complexity of Multiple Development Locations

There are multiple reasons why companies spread research and development activities into multiple countries. In some smaller countries it might even be that the job market is not big enough to cover all the needs or that at least talent is really hard to find. That's why it is many times natural to spread activities to locations where the talent pools are bigger. Also the salary level can be a tempting factor especially in cost competitive countries, like India.

But there are certain challenges that are good to keep in mind before taking the step. I have no hidden agendas, my intention is to simply state some things that you might want to consider before starting activities in a new location.

Time-zone differences are good to take into account. Of course they can even be a positive thing if you are looking for 24/7 response times in services and you need to follow the sun. But if you are attempting to have distributed teams (members in more than one time-zone), they will have a limited number of common hours. There are some 'sharing the pain' approaches to this, but none the less it's a real challenge.

I think that if at all possible, people who work together should meet face to face at least in the beginning of their common journey. That helps to build trust and makes the team work easier. It's also easier to explain things and build understanding while being physically close. While this is nice, it will of course create some expenses when people need to travel. Again by far no show stopper but something to consider.

Having multiple development sites has an effect on the communication also. With one site you can rely mostly on physical boards and getting people together, but with multiple sites you need to have proper technology. Things like online backlog tools and communication software become a must. And I think many will find chat tools like Flowdock or Slack beneficial. Internet connection speed will also prove to be important. This depends also on your products, but if you need to transfer gigabytes of data there's a big performance penalty if moving files takes hours rather than minutes or seconds. Thus the local infrastructure also plays a large role.

Job rotation pace also varies between countries. Somewhere it might be possible to stay with one employer for the whole career (maybe not realistic nowadays anymore) whilst in some countries people tend to switch jobs every couple of years. If employee turnaround is really rapid, tens of percents annually, building silent knowledge might be difficult. I mean such information that slowly accumulates while you learn more and more about your field. I think rapid job rotation is also where bad for good team spirit. It's not easy to build trust between people who often change.

Cultural differences should be also taken into account. Countries differ in many things. For example Finland, USA and India are really different. To better understand one another it is good to study a bit what kind of things are valued in the other culture. One nice site to check the differences between nations is here. There you can check how the six pre-selected factors differ. It might explain why your colleagues behave as they do.

Inflation rates are also really different between nations. For example in Finland the tech salaries are high, but there's hardly any inflation. In India it's vice versa. Salaries are in general smaller, but they are raised in bigger chunks and more often. And one of my guidelines is that in the global economy talent is cheap nowhere.

Final thing that comes to my mind is the local laws and amount of bureaucracy. I guess many times the amount of bureaucracy can be bundled with the amount of hierarchy, but that's just my assumption. (What I mean is that if you always need to get bosses bosses boss's signature, you are probably in a hierarchical and bureaucratic setup.) Having a local representative who knows the culture while starting activities up is probably priceless.

Well that was my not so short list of things to consider. Topics are not in any specific or prioritized order. But hopefully they will be useful for people who are pondering about spreading activities to new locations. Make sure you understand the challenges. Some are just risks that may or may not realize, but some of these you will encounter for sure. But if your plan is clear and you are doing it for the right reasons, you have a good change to succeed.

By the way, if you are academically interested in the topic, you might want to check out DD-SCALE project.

From Forecasting to Cycle Time

I like measuring for the sake of improvement. I believe that measuring something helps to understand its nature. And by measuring you might learn if something is good or bad and going to positive or negative direction.

We have been using so called forecast hit-rate to measure how well the Scrum Teams are able to predict their velocity. It's the result of dividing planned number of Story Points with the actually realized number of Story Points for a Sprint. But in case the number of stories is small, there's easily large deviations when things don't perfectly as planned. And usually things don't go perfectly as planned.

Also this measure can result in some rather nasty dysfunctions. Teams start to favor keeping the forecast instead of trying to maximize the amount of customer value in a Sprint. Or even though some Story becomes obsolete it isn't dropped because that would flaw the statistics. This isn't nice.

We use Atlassian JIRA and JIRA Agile for our Backlogs and Scrum boards. (I guess I should start calling it JIRA Software soon.) It offers a handy Velocity Chart where one can follow these planned vs. completed results. This is essentially the source of our forecast hit-rate information.

But due to all the possible events that affect the Scrum Teams and the #NoEstimates movement that gains momentum also in our company, the data has a really high variance. Even after couple of years it shows no signs of stabilizing. (Of course it can argued that is a systemic dysfunction. As it is. But let's not go there.)

Another tempting alternative for this metric that I've been thinking about is Cycle Time. Average time that a Backlog item takes between the start of work until it is completed. Let's assume that such metric would be easily available and that there would be target on it or that management would follow the number. What kind of behavior would this drive?

My assumption is that it would make the Stories smaller. That teams would strive to get things done faster instead of having mammoth size stories. So In the end there would be a bigger number of smaller Stories and tasks that could be made in shorter time. I would like that. Also it would fit nicely with #NoEstimates.

Since this is still simply hypothetical, I don't have any results yet. But this is an experiment that I'm about to try.