jcfausto - Opinions, thoughts, and ideas on leadership, management, software development, and people development.

The Difference Between Systems Thinking and Reductionist Thinking In Software Development

In software development, having a Systems Thinking approach means that you start from an event or a part of a system and tries to determine its connections or relationships to other parts or events.

A Reductionist Thinking is when you break down a problem or task at hand into its simplest parts in order to understand better what the problem is about.

An example of how these two ways of thinking can be applied is described below.

Reductionist Thinking Can Help You Build The Right Solutions.

Let’s say you want to solve a particular customer problem. Based on what you know about both your customer and the problem you’ll try to come up with an idea or hypothesis for a solution. What happens is that usually the idea or hypothesis is too big to be easily and quickly implemented on your product and tested. That’s when applying reductionist thinking might help you.

In order to both reduce risk and speed up delivery, modern product and software development approaches recommend breaking the necessary work into several small deliverables.

Because you broke a large chunk of work into smaller functional parts, now you can implement and integrate them into your product within a short period of time, 1-2 weeks preferably. Also, you’ll be able to built incrementally and deliver continuously.

Animation starting from a vision of the earth and then slowly zooming into the earth to a point where a small and specific part of a city is displayed — From a big perspective into a reductionist perspective

Once that happens, you can sense customers’ response and better understand if what you’re offering as a solution is, in reality, the one that will solve your customers’ problems.

Systems Thinking Can Help You Streamline Your Product Development Process

When thinking about the way you develop your product or the way your team develops software, oftentimes you can benefit from looking at this issue with systems thinking perspective.

That means starting from the premise that your team is a sub-system of a greater system that usually goes beyond your company and in order to understand this system you’ll have to pull back your lens and look at the whole context instead of a single part.

Start With a Map

One might say: Well, I’m just a developer, I don’t care about the product, marketing, etc. It’s not wrong to think like that If you want to limit your impact to your team. However, if you understand and think about the whole value stream and solve issues with a systemic perspective, analyzing the inputs, how you process them, and the outputs, you might achieve better results and higher impact.

One way to understand better the systems is to use Value Stream Mapping techniques (VSM). But, if you don't want to complicate things at the beginning, just use a basic flow diagram to identify which are the system's components,… Click To Tweet

Derive Actions Based On Your Mapping

From this mapping, you can figure out optimizations that will yield more effective optimizations and higher impacts. We commonly refer to these optimizations as global optimizations. The contrary would be a local optimization, which might have a positive effect on a particular sub-system but won’t help the whole system to perform better.

Adding to that, there’s the idea that in a system, how fast you can go is limited by your slowest sub-system or resource. No matter how optimized a part of your systems is if the rest of it is not optimized as well you’ll just be constrained by these slowest parts.

Best Way to Change A System

It’s not easy to change systems due to its complex nature. Some time ago I’ve attended a training with Mary and Tom Poppendieck about lean software development. During the training, Mary said something that stuck into my mind:

“You don’t change complex systems with big-bang changes. The way you change complex systems is through small changes and sensing system’s reactions after each change”.
mary poppendieck

Mary’s statement resonates with me and that might be one of the reasons most transformation initiatives fail. So, the way to go when it comes to change a system is to apply small changes to it, and not big-bang changes, otherwise, the back-pressure will be high.

To Learn more: 6 characteristics of complex systems and how they relate to modern software development

The video below presents a nice introduction to Systems Thinking.

Introduction to Systems Thinking by BEE Environmental Communication

In summary, use systems thinking to understand your system. Apply small and continuous changes, measure how the systems react, repeat that continuously.

To Learn More

If you want to learn more about this topic I recommend the following books.

Good books about Systems Thinking

An Introduction To General Systems Thinking, by Gerald M. Weinberg

How To Create JIRA Workflows – Beginners Guide

June 6, 2019 / jcfausto / 0 Comments

Creating workflows in JIRA might be a daunting task if you don’t get the foundation right. As a beginner, you need to understand first some basic concepts before implementing your first workflow or adjusting an existing one. I’ll share with you 3 easy steps to create your JIRA workflow.

I’ll explain below these basic concepts and will also provide a step-by-step guide on how to set up a basic workflow in JIRA. Keep in mind that in order to create workflows in JIRA you have to have JIRA administration rights, otherwise you won’t be able to manage workflows. Also, I created this tutorial for JIRA Cloud because it’s the most recent and accessible JIRA version. Most of the ideas presented here are also applicable to hosted versions of JIRA.

The use case I’ll use as a base for this tutorial is that of person who has a project in JIRA with a default JIRA template workflow and wants to replace it with a new one customized to her team’s needs.

Basic Concepts

The work flows from a series of steps, starting at an initial step and then moving forward, and sometimes backward, step by step until its completion. A step in JIRA is known as a “status”.

Status

A status in JIRA represents the current situation for a particular issue on a given time. This one is easy to understand. For instance, we can say that a particular issue in “In progress” or “In Review”. Ths situational representation is what we call “Status”.

You can have as many statuses as you want in your workflow, but keep in mind that the less the better.

Transition

Transitions are the bridges from one status to another. A transition is an action and represents the movement of a particular work from one state to another.

For instance, one might want to “Start working” on a JIRA issue. Once you sign that you want to “Start working” on a JIRA issue, you’ll also execute a transition from the current state to a new one which says that now the issue is “In progress”.

On JIRA cloud, transitions will appear like this:

JIRA Cloud – Transition example on issue screen

On JIRA Server, transitions will be usually represented as buttons at the top menu of the edit issue screen.

Create Your First Workflow In JIRA

Step 1: Start With Pen and Paper

Before jumping into implementing the workflow in JIRA, start with pen and paper and do some research in order to understand which workflow you’ll have to create. Ask someone in the team to verbally describe their workflow. Take notes of the words they use and convert that into a list of steps.

When creating workflows in JIRA, the best way to start is with pen and paper. Talk to people and ask them to verbally describe how they work. Take notes of the words they used and convert that to a draft workflow that you can use to start… Click To Tweet

Example of a conversation that you might have

Alice: Hey Bob, I’d like to design and implement the team’s workflow in JIRA, but first I’d like to understand how the team works. Could you describe to me which steps you usually do from the moment you get something to do to the moment you consider it done?

Bob: Sure, well, usually after our planning meeting we have a set of issues we selected from our backlog as the ones we’d like to implement during the week. Then, we assign ourselves to one of the issues we’d like to work and start the development. Once the development is done, I submit the code changes to code review, then I interact with people base on their feedback and fix any issue that might be reported to me. When the code review is done, then I integrate the code. This is the last step where I do the integration of the code into the main branch, wait for the feedback from the tests, check our internal dashboards and then if everything goes well I consider this work done.

Alice: Great. I think I got it. Thank you very much for your time.

Bob: No worries

From the chat above, Alice might come up with the following list of statuses (steps):

Backlog
Selected for Development
In Progress
In Review
Integration
Done

With this list at hand, Alice can then layout the flow between these statuses and define the transitions as well.

Backlog => Selected For Development => In Progress => In Review => Integration => Done

Step 2: Create A New Workflow In JIRA

In order to create a new workflow, go to the JIRA Settings > Issues > Workflows:

Bottom left JIRA menu bar highlighting the settings option. — Bottom left menu bar

JIRA cloud settings menu with the Issues menu option highlighted — Select the “Issues” option

JIRA cloud Issues menu with the Workflow menu option highlighted — Select the “Workflows” option – If you have trouble to find this expanded menu, press [ on your keyboard or click on the hamburger menu at the top left to expand the Issues menu options.

Now that you know the hard way, I’ll share with you the shortcut. By typing the following URL you can easily access the workflows configuration screen:

https://[YOUR ID].atlassian.net/secure/admin/workflows/ListWorkflows.jspa

If you landed on the screen below you’re in the right place.

JIRA cloud workflow configuration screen — JIRA Cloud – Workflows Configuration Screen

Now, click “Add workflow” to start creating a new one.

JIRA Cloud - Workflows Configuration Screen - Add Workflow highlighted — *JIRA Cloud – Workflows Configuration Screen* – Add Workflow

Give a name to your workflow and add a description for it and click “Add”.

Once add your new workflow you’ll be presented with the “Workflow Editor” which will be similar to the one below:

JIRA Cloud - Workflow Editor - Newly Created Workflow — JIRA Cloud – Workflow Editor – Newly Created Workflow

Now let’s have some fun. I usually first add the statuses I need. In this case, they are:

Backlog
Selected for Development
In Progress
In Review
Integration
Done

JIRA Cloud workflow editor - adding a new status — JIRA Cloud workflow editor – adding a new status

Don’t mind clicking the “Allow all statuses to transition to this one”. We won’t need that. You’ll notice that for some statuses you’ll have to create new ones since they might not exist yet on your JIRA instance. Don’t worry, just click “new”, provide a description and set the correct category as exemplified below:

After you added all the statuses, it’s time to wire them up using transitions.

JIRA Workflow with all statuses in place

Click “Show transition status” at the top bar on the workflow editor and let’s move on. Now, reconnect the “Create” transition that is connected to “Open” to the “Backlog” status and delete the “Open” status by selecting it and clicking on “Remove status” as highlighted below:

JIRA Workflow - Removing a status — JIRA Workflow – Removing a status

We’re almost there, don’t give up! Now, create the remaining transitions between the statuses. Do that by hovering over the origin status, in this case, “Backlog”, and dragging your mouse until one of the connection points on the target status, which in this case will be the “Selected for Development” status. See the images below for an example:

JIRA Workflow – Connection point when hovering over a status

JIRA Cloud - Linking statuses through transitions — JIRA Cloud – Linking statuses through transitions

Now, give a name for your transition and add a description that will help people to understand what will happen when they execute this transition. Once that’s done, click “Add”, and Voilá! You just created your first transition.

Now repeat the same process for the remaining transitions and in the end you’ll have created your workflow and it should be similar to the one below:

If you reach this far, congratulations! Now you’re very close, just a few more steps and you’ll achieve what you want.

Step 3: Changing And Publishing the New Workflow

Changing The Workflow

Now we have to go to our project settings to change the project’s workflow to the one we just created.

Go to your project and click “Project Settings”.

JIRA Cloud - Project Settings — JIRA Cloud – Project Settings

Once in the project settings, click “Workflows”.

JIRA Cloud – Project settings – Workflows

You have now two options, you can either change the workflow scheme or add an existing workflow. In our case, we want to add an existing workflow. So, click on “Add workflow” > “Add existing” and choose the one you created in the previous step on the selection screen.

JIRA Cloud - Project settings - Workflows - Add Existing Workflow — *JIRA Cloud – Project settings – Workflows* – Add Existing Workflow

JIRA Cloud - Project settings - Workflows - Add Existing Workflow - Selection Screen — *JIRA Cloud – Project settings – Workflows – Add Existing Workflow* – Selection Screen

Now, click “Next”, assign all the issue types to the new workflow and click “Finish”.

JIRA Cloud - Project settings - Workflows - Add Existing - Assign Issue Types — *JIRA Cloud – Project settings – Workflows – Add Existing – Assign Issue Types*

Great, now you should see the workflow screen again with the new workflow being displayed! Great!

JIRA Cloud – Workflows – Changed but Unpublished Workflow

Publishing The Changed Workflow

Now, click “Publish”. You’ll go through a two-step process. On step 1, click “Associate”. Wait for step 2 to finish and click “Acknowledge”.

JIRA Cloud – Workflow changed – Acknowledge step

Congratulations! You did it!

Congratulations! You did it!!!

Step 4: Check The Result

I usually check after every workflow change if everything is working as expected. I advise you to do the same. Create a test issue and make sure it can flow through your workflow as expected.

Conclusion

Creating a JIRA workflow might not be as hard as you think if you just get to know some basic concepts and understand how to wire things up in JIRA. To make things easier, I prepared a one-pager that will help you with this task. You can download it for free below.

If you’re working with a different version of JIRA, perhaps JIRA Server and are having trouble to figure out how to do it, just let me know on the comments below and I’ll do my best to help you.

Disclaimer

I’m not affiliated with Atlassian, the owner, and creator of JIRA, nor receive any benefits for creating this tutorial from Atlassian. This tutorial is totally independent and based on my own experience. Any mistakes, inaccuracies or misinterpretations are my own.

When is the best time to have a meeting?

May 5, 2019 / jcfausto / 0 Comments

Deciding what is the best time of day for a meeting is not always easy. But you can learn how to make this task easier and more effective. And you’ll be surprised how easy it is to learn it.

Do you remember when was the last time you stopped to think about what would be the best time of day to hold a meeting?

I asked myself this exact same question when I read something that changed my perspective on how to define what is the best time for a meeting or to perform some types of work. And that’s what I’ll share with you in this article.

Recently I listened to a podcast where Daniel Pink, author of “When – The Scientific Secrets of Perfect Timing” was interviewed. was interviewed. At some point during the podcast, the author told something that really captured my attention and made me think about how a change on the way we decide when to do something could lead to better outcomes.

In this article, I’m particularly interested in exploring how to become better, based on Daniel’s findings, at deciding when is the best time of day to have a meeting. Without further ado, let’s take a look at a real-world example where I had to make such a decision and how I approached the decision using what I learned from Daniel.

Recently I’ve got an e-mail asking me for a quick demo on a particular topic. See below the content:

Hi Julio (and everyone),

From your XYZ presentation there was a very interesting topic on creating releases in ABC tool. I would be very interested to have a deeper look at how that works and it would be great if you could give a quick tutorial. I’ve included other people as I think we should have our processes aligned.

Maybe you could set up a short demo and use-case in the next week or so to teach us your ways 🙂

The message above is a clear example of a “when” decision. That is a very common type of decision we do every day many times per day. I’ll describe below how I used to approach such type of decision before.

Step 1

I’ll check my calendar for my available free-time slots (I’ll usually avoid Mondays).

Step 2

I’ll then, supported by the tool, figure out if all people would be available on one of the free spots. I’ll do that until I found a time where everyone would be available.

Step 3

I’ll then start chasing an available meeting room that would fit our needs.

Step 4

Finally, I’ll send the invitation.

The single criteria we use and we don’t even notice

What is the keyword in the steps described before? There is a dominant word that reflects exactly the way we think about this problem. And this word is availability.

Yes, that is the unique criteria I was used to using. And I believe it’s the one most of you might use as well.

What’s wrong with this approach?

The issue with using availability as the single variable in your decision-making process is that you’re not considering how the great majority of us go through the day in terms of focus, energy, and mood. Also, you’re not considering which types of work we do better on each stage. Daniel Pink in his book, “When – The Scientific Secrets of Perfect Timing” named these stages as: Peak, Trough, Recovery.

The author discovered while researching for his book that scientific research was pointing out that our Chronotypes matter when it comes to which type of task we have to fulfil. He also learned that If we’re not doing the right types of work at the right time we’re likely to make more mistakes and being less effective and efficient. And that’s not because we don’t know what we’re doing. It’s just because of how our body and brain work.

Daniel described that for the great majority of us, the best time of the day to perform analytic work or work that requires heads down and focus is early in the mornings, where we are at our Peak stage. There’s, of course, exceptions for those who are night owls, but that’s not the great majority of us according to the author. After lunch, we enter on the Trough stage which is a stage where we have less power to fight distractions and consequently, our focus is dispersed very easily. This particular time of the day should be dedicated to bureaucratic work. Work that doesn’t require creativity or heavy analytical thinking. At the end of the afternoon, we enter the Recovery stage. At this point, our focus increase and our mood get better. That’s the moment of the day for creative work, like brainstormings for instance.

After knowing about this fact and understanding that using just availability as a decision criteria for defining when would be better to have a meeting, one can think at some questions that could lead to a better decision and potentially a better outcome from the meeting as well.

In the case of my colleague’s e-mail, I used the following questions to help me make a better decision:

What type of meeting is this?
What do people expect from this meeting?
Will this require high levels of attention?
Will this require active involvement?
Who’s gonna be there?
1. Are there gonna be morning people?
2. Are there gonna be evening people?
Will this meeting require analytical thinking?
Will this meeting require good mood?

My answers to the questions above were:

1 – What type of meeting is this?
It’s a “tutorial” like a meeting.

2 – What do people expect from this meeting?
a) To passively consume information on how to use a particular tool, b) to know how I approach this problem inside the tool, b) To acquire knowledge to judge if that suit their needs or not.

3 – Will this require high levels of attention?
No, people will have to pay attention but it’s not a subject hard to get. So, higher levels of concentration aren’t needed.

4 – Will this require active involvement? No, they can just watch and listen to my presentation/tutorial.

5 – Who’s gonna be there?
5.1 Are there gonna be morning people?
Most people there are morning people.
5.2 Are there gonna be evening people?
No.
6 – Will this meeting require analytical thinking?
No.
7 – Will this meeting require good mood?
Not necessarily.

Based on the answers above I concluded that the best time for this meeting would be right after lunchtime, because a) this is the time where people are more suitable for meetings that don’t require analytical thinking; b) This is a good time for when people just need to consume information; c) The subject won’t require too much thinking; d) Also, we don’t need people to do creative work or good mood at all at this meeting, so having it late afternoon would also not be the best option.

Curious about the final decision?

The final decision was: I scheduled the meeting for 2 pm, right around after lunch, where people will be entering the Trough stage. They can just sit and watch me performing the tutorial/demo and interact with me a few times without having to think too much or do any hard analytical thinking.

Well, that’s a new way to look at “when” decisions and I like it. According to Daniel, in some cases, the efficiency of the work as 20% less efficient as it could be just because it was done at the wrong time of the day. In the end, it’s all about moving the right pieces of work to the right time of the day.

Have a recurrent meeting that it’s not working very well? Read “How to Fix a Broken Meeting” for an idea on how to fix a meeting that it’s not going well.

Deming’s 14 principles and Agile Software Development: A perfect match?

May 2, 2019 / jcfausto / 0 Comments

I read an article that drew my attention; the article was about W. Edwards Deming’s 14 key principles for management.

Honestly, I don’t remember to have read Deming’s principles in the past, although I knew his work from my studies on Toyota’s Production System. So, I can say that this was the first time that I actually sat and read his set of principles.

Deming wrote them in the middle 80’s; according to The W. Edwards Deming Institute[2] the 14 points were first presented in his book Out of the Crisis, published in 1986.

Out of The Crisis – by W. Edwards Deming

One can suppose that the principles are not applicable in today’s business world. However, they surprised me regarding how up to date this list of principles are comparing to what we have nowadays in terms of modern software development practices and principles.

While reading the principles I was able to immediately connect each one of them to what we — people that study, teach, and coach agile and lean inside organisations — understand as key principles to achieve business agility.

I decided then to share these thoughts that I had by writing this article that aims to inspect if one can really compare Deming’s principles to lean / agile values and principles. Below you’ll find the comparison.

Deming’s 14 principles of management

1 — Create constancy of purpose

The word “Purpose” promptly called my attention because it became very popular among agilists not due to Deming’s work but due to Daniel Pink’s book “Drive”.

This particular word, together with Mastery and Autonomy became a mantra in the agile community and is repeated over and over in almost every lean/agile talk out there. Although the word is the same, I do think that they have different meanings, especially because in Deming’s definition the word “purpose” is preceded by the word “constancy”.

I did my research and found that essentially, “constancy” means a state of being constant or unchanging or a steadfastness of mind under duress. That helped me to understand that “constancy of purpose”, in other words, means the act of being resilient and loyal to a certain principle and take this purpose into consideration in every decision that is made.

Look at how Deming formulated the principle in his book:

“Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs. [2]”

From that, I can conclude that what Deming meant is that an organisation must have a vision that will serve as a purpose and everyone inside this organisation should take that vision into account when deciding on something. Also, this concept relates to the idea of having a long-term vision and to see the organisation as a system where everyone ideally should be involved into the process of making this system better over time guided by the purpose.

From agile and lean I can remember immediately two ideas that resemble a lot this first principle; the first one is the idea that every agile organisation must have a clear vision and strategy. the second is that an organisation that wants to become agile must commit to the agile values and principles and make them the basis for every decision related to process improvement or even sometimes business decisions.

I do believe that these two ideas fit perfectly with Deming’s first principle. Don’t you think?

2 — Adopt a new philosophy

We all know that traditional management has been thoroughly reviewed and adapted over the years in order to fit into our current business age. Command and control, for instance, has proved to not be the most appropriated approach to deal with the current generation of workers. Management has moved from old management styles like this towards a more collaborative and co-operative style where responsibilities are shared and everyone is accountable for good or bad results.

This new approach is what most people, including me, believe that makes more sense today for the large majority of business out there. Almost everything nowadays is complex, full of uncertainty and in constant change. That’s the reason we must adapt fast to this new — well, not so new — scenario.

The agile and lean movement is what I do consider as the new “philosophy”. In a fast changing environment, nothing more reasonable to develop the ability to respond faster. But this ability comes with a price. It’s a radical change for many businesses, especially those well established and funded under a traditional philosophy. Some companies successfully achieve the transition, others just give up and other stays in between, with a reasonably good process and reasonably good results.

Something I learned and that connects perfectly with this principle is that any agile transformation must start by teaching the new philosophy and later adopting the process. I’m always 100% sure that if people don’t understand and stick with the purpose, the principles, the benefits won’t come as expected and the journey will be much harder than expected.

If you read until here, thank you!

Unfortunately, as you saw above, writing about the 14 principles is something that will require some time from me. I’m willing to invest this time if there is someone willing to read more 🙂 So, if you’d like to read more, please like this article and sign-up above as a sign that you want to read more.

Remaining principles to be compared:

3 — Cease dependence on inspection to achieve quality

4 — Minimise total cost

5 — Improve constantly and forever the system of production and service

6 — Institute training on the job

7 — Institute leadership

8 — Drive out fear

9 — Break down barriers between departments

10 — Eliminate slogans and exhortations

11 — Eliminate metrics that rob the pride of workmanship

12 — Remove barriers that prevent people to be proud of workmanship

13 — Institute a vigorous program of education and self-improvement

14 — Put everybody in the company to work to accomplish the transformation

Sources, so far:

[1] http://www.heartoftheart.org/?p=3810

[2] https://deming.org/management-system/fourteenpoints

[3] https://www.merriam-webster.com/dictionary/constancy

You Don’t Lose Your Job. Your Company Loses You.

April 28, 2019 / jcfausto / 0 Comments

One of my fears was to leave my country and go to another country to learn about human development and technological entrepreneurship. I pointed out that this will imply into losing my current job and will affect my comfort levels (I was in the comfort zone).

From everything above, I’d like to highlight the word “losing” in “losing my job”, because today, 6 years later my immediate feeling when I read this word was not a feeling of loss but a feeling of winning. I might have been a losing situation for my forme employer, but for me, what initially seemed as a loss was indeed a win, but at that time I couldn’t recognize that. And I’m curious to explore why did that happen and happens from time-to-time still today with me and I bet with many other people as well. Why do we say “I’m afraid of losing my job” instead of “I’m afraid my current employers will Lose me”? Why do we have so low self-esteem and we see ourselves highly dependent on our jobs?

I’m not a scientist or an expert on this matter but I have my empirical knowledge that helped me to understand some perspectives or triggers that usually led us to think like that.

The first trigger or constraint to different thinking is without a doubt: Income. If your only source of income is what you get paid as a result of the work you provide to your employer, then you might think that if you can’t provide this work anymore you Lose your income, and that is what makes you state that you’re afraid of losing your job, when in reality you’re afraid of losing your income.

If you think about this topic, the only strong bond that ties you to your employer is your income. If you somehow make you less dependent on that, you’ll start seeing things differently.

Now let’s explore other perspectives that might establish a different mindset.

Companies don’t exist without employees. The levels of dependency might vary, but they’ll depend on your services provided by people in order to exist. So, you’re the most important asset for the company followed by the company’s product, which is also created by the services you provide. Just that should be enough to give you the frame you reference you need to see yourself as key for the organisation and your organisation should see yourself the same way as well. Because we’re now facing more and more shortage of workers, it’s becoming every year more and more clear that if companies don’t start treating people well they’ll lose, and will Lose badly.

Another perspective is that you own the skills you acquired, you worked hard to assimilate them, learn them, put them in practice in order to acquire experience, and this is the value you provide to the company you’re working for. The ability to use what you know to build the company’s vision. You’re renting your services to the company and the company is paying you in exchange for your knowledge. Let’s say the company don’t need or you don’t want to provide your services to this company. That’s a perfectly fine situation, looking just at this perspective, and you should see as a natural evolution of yourself. You’ll now use your skills to help other companies that will still need your services and will pay for it.

There are a few variables that might influence your ability to make these transitions easily. If you are a specialist in an area that it’s not in high demand or it’s a very specific area, you’ll probably won’t have too many companies in that area where you can move to. That becomes a constraint for you that that’s something you should evaluate how to mitigate in order to reduce its influence on your ability to stay dependent on your current company. Another variable would be if you’re entering the market. You might not have too much experience yet, that means your options might be limited as well. Age, industry, your personal situation, all are also variables involved in the equation of employability.

What about low skilled jobs? People should aim to improve their skills. They should not accommodate and don’t improve their skills. Governments should support them to improve either by subsidising training, supporting in career planning, and through better public policies that incentivise professional development alongside social support. And they should own the responsibility to improve themselves as well. Just waiting for a magical solution that will make you more valuable in the market won’t happen.

What can employers do to help? Stop exploring people as resources. We’re not resources anymore. We’re people and we need support to grow and be fairly treated otherwise “You’ll Lose me” because I’ll find a place where I do have such conditions.

What about high skilled jobs? People should not focus only on getting money, but focus on what they really want to do professionally and take advantage of this great situation to create the best version of themselves.

In summary, there’s always a way and something you can do without depending on anyone that will minimize the impact of constraints and potentialize the influence of variables, such as experience, domain knowledge. These actions might increase your chances of having a higher level of work mobility to a point where you can say “I’m afraid this company will Lose me” instead of “I’m afraid of losing my job”. Stop for a while and do some research on how to overcome fears, how to do career planning, how to do goal setting, etc. These tools might help you a lot to adjust your frame of reference around this topic.

A Frog or A Horse?

March 2, 2019 / jcfausto / 0 Comments

What do you see on the picture below?

And now, if I turn the image 90 degress clockwise, what do you see?

Most people will see a frog on the first drawing and will still see the same frog in the second drawing, but some people will be able to see a horse in the second drawing, and a few people will recognize both the frog and the horse already when looking at the first drawing.

Which one is right? Why some people see first a frog and why others see first a horse?

Our perception of the world that surrounds us can change as quickly as we learn and absorb new knowledge and experience. And that it’s totally ok!

The way you see or understand a situation presented to you is based on the frame of reference you have at that moment in your brain. It doesn’t necessarily represent reality. What you get is an interpretation of the reality based on your beliefs and experience, your mindset.

Another person with a different background and life experience might interpret the same situation at hand differently and build a different reality. That’s the reason why is so important to be super careful about what you think and really reflect on how these thoughts and interpretations are influencing your actions and behaviours.

The problem is when you don’t recognize this dynamic and believe that the map you have, which most of the times you don’t even know that exists, is the only one that matters and the truth. That’s when people start to become pushy, dictatorial, etc.

When you don’t accept that there are other maps and consequently other interpretations of the same reality, you’ll not advance yourself as a person. You’ll be a prisoner of limited interpretations. Yes, some maps are better than others. They have a better representation of the terrain and the key for me is that one can develop a mechanism for recognizing such better maps and improving her own maps.

Acknowledging this natural law and being open to evolving your maps, your frame of reference, is what will really make a difference in terms of personal and professional evolution over time.

If you want to know more about this topic, I highly recommend reading this book: The 7 Habits of Highly Effective People.

An extra challenge for you: What do you see in the image below?

Did you see the young and elegant lady? Or…

What Is A Feature Lead?

February 27, 2019 / jcfausto / 2 Comments

There’s a lot of resources explaining more in details many roles in IT, but one in particular I think it’s not well defined or explained. The Feature Lead.

I have an overall idea of what this role should do and which behaviors or skills people on this role will have to develop or show in order to make the most out of it and really create an impact.

In order to share these thoughts I’m drafting an e-book that will bring a more detailed perspective on this subject. See below an excerpt of the first chapter.

What is a Feature Lead?

The Feature Lead is a role – a set of responsibilities – that can be deployed inside software development teams as a mean to empower people to take ownership and make decisions regarding the development of new features, creating a more fertile environment for growing self-managed teams as well as a culture of experimentation and learning.

The feature lead is the equivalent of a product owner on the technical side of things. That means that the Feature Lead will be responsible for taking care of all the technical issues that involves the development and especially the delivery of a new feature end-to-end.

Did you know?

The definition of what a “feature” is, as we know it nowadays in software development, was described by Peter Toad in 1997 in his process for software engineering called The Coad Method, that later evolved to become the Feature Driven Development process. The core of the Coad process was an artifact, created during the analysis phase, called “a feature”. It was similar to a requirement, except by the fact that it was written using a domain language which the project sponsors could understand. The main concept is that a “feature” should be written in a way that the sponsor could agree that the feature had meaning and was required in the system [1]. Doesn’t this sound like an old relative of User Stories?

Key points:

It’s a role and not a job title.
A feature lead is responsible for feature delivery.

Did you like it? See below the outline of the e-book:

6 characteristics of complex systems and how they relate to modern software development

February 24, 2019 / jcfausto / 0 Comments

When I look back to my understanding of agile and lean software development, when I first came in contact with these topics years ago, I do realize that I missed it totally at that time.

Now, some years later, I do think I have a better understanding about it to a point where I feel comfortable to share with you some ground knowledge that I came to learn later and that made me see these topics from a totally different perspective.

Why do some people say that software development is an activity in the domain of complex systems or a complex adaptive process?

At first, you have to have an overall understanding of what complexity means in software development and where it comes from. The whole concept is far more closely related to a new way of thinking on how to do things than to a formal model that you can apply. But, don’t get me wrong on that because I’m not telling that this has nothing to do with science.

Complexity is the subject of a whole research field in science. The act of programming a piece of software is something that can be simple and formal also. Thus, the complexity comes from all the other elements that are part of this process nowadays and the new way of thinking I’m referring to is mainly related on how to best handle all these interactions in order to extract optimal results out of them.

What I’ll share here is mostly empirical knowledge acquired during my journey – something based on my previous experiences. That said, let’s jump to the main characteristics of a complex system and understand how it influenced the current approaches we use nowadays in software development.

1 – Large number of inter-related elements

As far as I understand, a system is a set of inter-related elements that work together and depends on each other; no matter if simple or complex, every system will be composed this way.

Complex systems have a larger number of inter-related elements when compared to simple systems. Also, complex systems’ elements frequently are not single elements but other systems that can also be complex. Thus, we can craft a definition of a complex system as being a system of systems.

The Human Body As An Example Of A Complex System

The human body, for example, is a good example of a complex system. Our body is composed of several inter-related systems with specific intents that only have a meaning when working together and in balance. Also, the environment where we live has a huge impact on our bodies, indicating that the environment itself is also part of the system.

As well as the human body, modern software development is composed of multiple systems that only make sense when working together and in balance. The market, customer, company, stakeholders, managers, leadership, developers, office space, computer, weather, and many more components are parts of this system and can influence its performance.

No Every System’s Component Is Obvious

It might sound strange to consider the weather or the office space as part of the system right? But in fact, it isn’t. The layout of the office or the weather conditions can also play a decisive role in how effectively you are to navigate through a complex system. A decision to be made on a really hot day on an uncomfortable place can be influenced by such factors. There’s a lot of research proving that, and this is something that rarely we take into account, right?

When I see software development approaches insisting on treating people better, providing better conditions for them to work, create better work environments, I immediately connect such efforts to the fact that they’re as well part of the complex system that is supposed to build quality software and play an important role on final results.

2 – Non-linear

You might remember from your math lessons what linearity means but anyways I’d like to give a quick and dirty explanation.

Linearity is an observed property of a relationship; you have to have at least two elements interacting with each other – usually, each element provide an input – in order to observe linearity. When measuring the combined result of this interaction, a direct, constant and predictable proportionality can be observed. The result of the interactions between these elements can be represented by a straight line on a graph. Thus, linearity is the idea that combining the input of two elements will yield the sum of the respective output [1]. Increasing or decreasing one of the elements n times will result in also increasing or decreasing the result n times.

Now that we understand what linearity is, is easier to understand what is non-linearity. Non-linear relationships are unpredictable and increasing or decreasing one of the elements n times will not affect the result in the same proportion. Have you heard about the Butterfly Effect? This is a very good example of non-linearity.

Modern software development is non-linear because even a minor change can product disproportionated consequences. Click To Tweet

I bet you have heard many times that small bugs can cause big disasters, right? Did you remember what happened with NASA’s Mars climate orbiter that caused a $ 655 million machine to be useless due to a conversion issue[2]? The size of the bug/issue is not even closely similar to the size of the impact that it caused.

In day-to-day software development we made this same mistakes when we ignore for example the economics behind a decision to implement first a feature A instead of feature B, or when we ignore the impact that having a bad workplace can cause to your company’s results or even when we ignore the fact that not testing your software before shipping it to production is not a good idea nowadays if you want to iterate fast and build something sustainable by managing the technical debt you create and making things easier and safer to change later.

The size of the bug/issue is not even closely similar to the size of the impact that it caused. In day-to-day software development we made this same mistakes when we ignore for example the economics behind a decision to implement first a feature A instead of feature B, or when we ignore the impact that having a bad workplace can cause to your company’s results or even when we ignore the fact that not testing your software before shipping it to production is not a good idea nowadays if you want to iterate fast and build something sustainable by managing the technical debt you create and making things easier and safer to change later.

3 – Dynamic

The capacity of staying immutable is not something that appeals to complex systems because they change constantly and the outcomes cannot be predicted accurately. Click To Tweet

Usually, the outcome generated by a complex system is greater than the sum of its parts. In such systems, problems don’t have a unique solution. The challenge is to find one that can possibly solve temporarily the problem until the circumstances make it change again, forcing you to find a different solution for the “same problem”. Well, not exactly the same problem, although most people still believe it is. This phenomenon is called “emergence”.

To learn more: Evolutionary design.

To understand better what dynamic means for complex systems, let’s take a look in the car and the forest example. Imagine a car. Now imagine an experienced car engineer. Do you think that this engineer is capable of disassembling this car and reassemble it in a way that it stays exactly as it was initially? I do think so. Now think about the forest and all the elements that interact with it, such as the weather, the wind, the animals – including us -, and everything else that affects the forest. Do you know any engineer capable of disassembling and assembling a forest? I don’t believe so. It is impossible to define the forest exclusively as the sum of its parts because forests are complex systems that constantly change and have a relationship with lots of external systems that are also complex systems – winds, for instance.

Modern Software Development Is Dynamic

There is a principle in modern software development that says that the software design should emerge and not be defined upfront. Any clues why? Exactly! Is because while the circumstances changes – business scenario, user needs – the software design will also change in response to this “emergent” circumstance.

The best way to deal with this characteristic is to use an experimental approach that can be able to fast respond to emergent changes in the environment. In modern software development, we don’t impose solutions. Instead, we experiment in order to facilitate the path forward to be revealed. Thus, experimentation followed by sensing and concluded with a response is fundamental nowadays in software development companies.

4 – Evolutionary characteristics (co-evolution, adaptiveness)

Complex systems have a past that heavily influence the present. The decisions and happenings in the past shaped what the system is now, and this is something that cannot be reversed. This kind of systems evolves in response to environmental changes. The extent and depth of these changes are what makes the system reacts and change. This is a characteristic of evolutionary systems. Systems’ components and external elements evolve together on a series of small changes that leads to a certain momentary state.

Modern software development isn’t different. It’s heavily based on the premise that what we do should be a response to an external change. If business context, user needs, market demands, technology, change we should change as well in order to deliver the best response we can. This is something we know nowadays as “Adapt or die”.

We have seen many cases of big corporations that just disappeared because they were not able to change or adapt to modern times. Also, we constantly hear about the benefits of a start-up structure that due to its flexibility can easily change directions and explore quicker new opportunities or trends. In software development, we transitioned from the idea of specialists to the idea of generalists landing on a middle ground ofter referred to as “cross-functional” professionals. Such professionals have to expand their knowledge to other areas not directly connected to their specialty.

5 – Uncertainty

When you analyze a complex system by looking at its past, it’s somehow easy to reach the conclusion that you can predict how future events would be or that there’s a clearly defined co-relation between cause and effect that you can use for predicting future outcomes. Don’t fall into this pitfall. If you’re thinking like that, you’re forgetting that a complex system is unpredictable due to the constantly changing environments to which they are interacting with.

Modern software development is strongly dependant on the environment where it takes place. Oftentimes we refer to this environment as a “context”. I do believe that every context is different and modern software development practices should adapt to such specific contexts in order to bring any results. I’ve heard many stories on how people tried to use a certain approach that worked very well for company X but for their company it simply didn’t work. That’s because they missed considering the context. Every process, practice, a framework is created based on a certain context. If you don’t compare this context to yours when applying these ideas, you’ll certainly have trouble to make them work properly.

6 – Unordered nature

Unlike ordered systems, where cause and effect can be predicted with reasonable accuracy, complex systems can’t have such predictability. The complex interactions between its elements make cause and effect super hard to predict. Bear in mind that most systems involving living relationships are considered complex systems: people, culture, value, ecosystems, etc. And the best way to fight against this characteristic is to react to changes by using experimentation, prototypes and continuous adjustments.

Modern software development evolved into a scenario where it became unordered. Apart from very small cases where studies have shown successfully anticipation of customer behaviors, most of the time companies they to assess the current context and experiment something to see if this something is the answer that best fits the environmental needs at that particular time. Modern approaches to software development became much more adaptive and responsive to external changes nowadays.

In Conclusion

Studying and understanding what a complex system is and how we can work with it could help us understand why do we have all these different ways of developing products and why they are framed in certain ways that sometimes seems to be so uncontrolled, chaotic.

The point that all these approaches are trying to make is to find a way to enrich interactions between system’s elements, best react to environmental changes as fast as possible, and increase the chances to find the right answer for that particular moment with less cost.

Acknowledge that the work we do is complex and you’ll be on the right track. If you try to solve nowadays problems with old tools, that I’d say that you should urgently reconsider your options.

An open question for further discussion

If producing software is a complex adaptive task and in order to deal with such tasks we need to apply experimental and very flexible methods in order to find the most appropriate answer, how suitable are these large scale agile and lean approaches to software and product development?

Aren’t they too prescriptive to survive in such environments or trying to control an environment that cannot be controlled? Aren’t they trying to create order or bring linearity to a system that is by nature non-ordered and non-linear?

References:

[1] http://news.mit.edu/2010/explained-linear-0226

[2]https://www.scientificamerican.com/article/pogue-5-most-embarrassing-software-bugs-in-history/

The Truth Is In The Past. How the UNIX design philosophy inspired nowadays software development

February 17, 2019 / jcfausto / 0 Comments

I watched Jez Humble’s talk at Agile 2017 and among many insights, one particular thing caught my attention.

He based his continuous delivery philosophy on the UNIX design philosophy.

I’m a big fan of UNIX and everything it powers nowadays. However, this connection between UNIX’s design philosophy and Jez’s Continuous Delivery approach was very intriguing for me. You can watch the talk here. Skip to minute 4:30 to watch the UNIX part of it.

I’ve read the referenced paper on his slide and surprisingly enough I discovered it very up to date as for what we’re having nowadays as trends in IT. You can read the paper UNIX Time-Sharing System: Forward. (McIlroy, M.D.; Pinson, E.N.; Tague, B.A.) here.

A quick Look at UNIX system design style and some parallels I made

Make each program do one thing well. To do a new job, build an afresh rather than complicate old programs by adding new features.

This principle could perfectly be a description of the overall idea behind Microservices. Also, I can related two of the SOLID principles with it: Single Responsibility and Open Closed.

Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

This sound a lot like an API and its relatives like Design by contract, APIs first.

Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.

Impossible not to remember of a Prototype reading the principle above. Also, Iterations, Sprints, Fast feedback loops, Spikes.

Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

Workflow automation and supporting tools for software development such as IDEs, Analysers, CI/CD, Platforms, high-level languages, etc.

Opinion

An insight I had while reading the paper was realizing how pretentious or arrogant some inventors/creators are when they believe that they truly invented something revolutionary or even when we master certain skills that we ignorantly think is new but are nothing but old very good software development most of the times with a cool name or wrapped up on a framework.

This kind of material should be more available to every developer. I’m sometimes concerned with people that take courses on HTML, CSS and JS and assume they’re good developers right after finishing the course. They have so much to learn as I do even after all these years of software development. Also, all the agile movement should acknowledge that in the great majority of the cases they just made smart things invented in the past more accessible or sellable.

So in general, I started to believe that part of the truth on how to build quality and sustainable software resides in the past and it’s just waiting for us to discover it. Perhaps this will reduce a lot of the hype we’ve seen lately and we’ll be able to focus more on what we really like, well at least the great majority of us: Software Development.

3 Voices You Should Have Inside Your Team

January 18, 2019 / jcfausto / 0 Comments

This article is not about the Scrum Master, Product Owner, and Dev Team. Curious? I’ll explain what I mean.

If I ask you to propose a way to organize a team that allows the team to be as independent as possible and is also capable of enabling self-management. Which approach would you suggest?

I have the feeling that suggesting Scrum as an approach for this particular situation came to your mind. Although Scrum is a very good framework to introduce the agile way of doing work it doesn’t perform very well when it comes to helping your team to be agile. It tells you what, but it doesn’t tells you how.

I’ve seen recently many teams moving away from this standard way of setting up agile teams to a more tailored solution that takes into account the company’s culture, regulations, the type of industry. I believe that agile coaches or change agents with a certain experience have acquired sufficient knowledge to create or suggest a tailored solution that will fit better the organization’s needs.

Following a generic recipe, which is essentially what frameworks are, is not your only option when it comes to enabling an agile mindset and structure. Instead, you can think and use these generic tools as a reference, cherry picking or adapting what is there according to your environment’s needs.

For instance, you should take some time to analyze and understand where are the bottlenecks, communication ruptures, etc. Understand first the environment you’re in and after think of a solution that will survive on such conditions.

Different perspectives are what you need in order to create different experiments that will allow you to really leverage agile practices inside your teams in order to get better results. I’ve thought a lot lately about many agile related learned concepts that aren’t making much more sense anymore considering the different scenarios I saw. Contexts and people changed and I believe this is one of the reasons why I’m having such thoughts and feeling.

Having the abovementioned in mind, I’d like to share a different perspective to take into consideration when trying to build an agile team. Forget about which framework you’ll use, just make sure you have three voices inside your team.

The Three Voices

If you’re serious about autonomy and self-organisation and you really want a team that “is” and not just “do” agile than pay attention to these voices.

A team without one of these three voices will not be balanced and will most likely depend on external people that speak one of the missing voices. Still, even having all the voices, there’s no guarantee that the team will be able to self-organize because voices are just one part of the equation that results in autonomous and self-organizing teams. However, having the voices will increase your odds of success.

1 – Voice of Viability

Who takes care to check if what’s demanded is viable or not?

This voice is responsible to say to the team what are the market and business needs and what are the potential solutions to fulfill these needs.

A rough example: A company that produces software designed to manage cargo ship construction, will not likely decide to add smiles to the app’s chat because that’s not what the market is demanding. It’s not a viable solution for that particular business.

2 – Voice of Desirability

Who takes care of checking if a solution is desired?

This voice inside the team will be responsible for saying if something is being desired or not but customers. In order to do that, this voice has to understand the customer world.

It’s not very hard to imagine some viable solutions, but which ones will custorems be more willing to buy? Which ones have higher changes to succeed? These are questions that the voice of desirability is reponsible to answer.

3 – Voice of Feasibility

Who takes care of checking if what’s is viable and desired also feasible?

This is the most technical of the three voices. Usually the people that will transform the idea into something concrete – that can be consumed by users – are the ones that can express this voice and say if something is feasible or not from the technical perspective.

Make use you have these three voices inside your team, and your problem regarding autonomy and self-organization will be half-solved or at least will have higher changes of being solved.

Conclusion

If you ensure that your teams have these three voices inside and those voices can talk to each other frequently and in synergy, you’ll be able to build the framework you need for your team and organisation.

Opinions, thoughts, and ideas on leadership, management, software development, and people development.