After a few years, I started noticing one thing: In the last days of a sprint, everyone was rushing to deliver everything they had done in the previous two weeks to avoid carry-overs, frequently taking unnecessary risks.

Why? Couldn’t some tasks wait for next week? Was the delivery of every task before the weekend that critical? No, it wasn’t. We did it because “Carry-overs are bad.”

Scrum Is Not Agile Enough

I came to the conclusion that Scrum placed too much emphasis on process — or at least people paid to much attention to it:

• Delivering a story on the last day of a sprint was OK. But the next Monday, it was a carry-over.
• If you needed to do unexpected work (bugs, problems in production, etc.), it would affect your time and consequently make you fail the commitment you made in the planning meeting.
• The most used metric to evaluate success is commitment vs. done, which compares the stories that you committed at the beginning of the sprint and what stories you accomplished (I won’t even bother to mention what problems this can bring).

Scrum was not guiding us anymore. It was limiting us.

With all the points mentioned above, the team started to feel frustrated, and it affected the quality of the work produced. People cared more about delivering in time than delivering with the desired level of quality.

At this point, we started to research other possible agile frameworks that would be a better fit for our work method.

We found Kanban.

What Is Kanban?

Kanban is a work management framework that was first introduced by the Toyota Production System back in the ’40s. At this time, Toyota used a visual board with three columns: Requested, In Progress, Done. This framework allowed Toyota to allocate resources better when there was a bottleneck in some areas in the production line.

Kanban was then adapted to the technology industry when people saw the benefits it could bring to the speed of delivery.

Scrum vs. Kanban

In recent years, Scrum and Kanban have been fighting for the position of the leading agile framework. Despite Scrum being the current #1 agile framework, Kanban is becoming more adopted over the years. But how do these two frameworks compare?

Having Scrum as a base:

• Kanban has no timeboxed iterations (sprints).
• Kanban does not require story estimation.
• Kanbandoes not have the concept of commitment. Items enter the flow as they need to be done.
• Kanbanprovides several metrics that measure the time that a story takes on the board.
• Kanban does not require a Scrum Master (obviously).

Kanban offers more flexibility to the team. Stories flow more freely than they would in Scrum. But with great freedom comes great responsibility. Despite not having a commitment every two weeks, other metrics must be used to evaluate the team’s performance, such as cycle time and throughput.

It’s All About Metrics

You can’t measure your success (or lack thereof) without having metrics that allow you to assess your progress.

The Scrum metrics

Scrum uses these metrics and graphs:

• Velocity: the number of story points delivered each sprint
• Commitment vs. Done: the percentage of stories that were committed and delivered
• Burndown chart: a graph that shows the evolution of the stories of a given sprint

These metrics hardly help you to improve your workflow.

Velocitydoesn’t measure the speed of delivery. It counts the number of story points that were delivered. If a story ends up taking longer than estimated, this metric would no longer mean anything.

Commitment vs. Done should never be a metric. It compares what was delivered vs. what was committed. Needless to say, this can bring people to close and reopen tasks for them to be “Done.”

The burndown chart is something that I personally never paid too much attention to — mainly because it often looked like this:

Why does this happen? You begin with an empty board and start, let’s say, three stories in parallel. These stories are likely moving forward all at the same time, which means that you’ll see these massive drops in the burndown chart. Furthermore, if you have one tester who is supposed to test all the stories, you will have a bottleneck.

The Kanban metrics

From my perspective, metrics are the strongest points of Kanban. It has a pool of different metrics that allow you to better understand what is going on with your team, such as:

• Throughput: the number of stories that are delivered within a given timespan
• Cycle time: The number of days it takes to deliver a story after it is started. This uses confidence intervals. The most common to look at is 85% confidence.
• Cumulative flow diagram: Allows you to have a visual look at how the stories flow in your board. It should look like a combed whale.

There is a plug-in for Jira that provides all these metrics out of the box. It is called ActionableAgile for Jira — Agile Metrics. You can explore your team’s metrics using the same software you use to manage your work.

We Adapted It to Our Team

Pure Kanban does not require you to do several activities that are necessary for Scrum. However, it gives you the flexibility to do them if you foresee value in adding them to your workflow.

Retrospective meetings are one of the most important meetings for a team. It’s where you can look to what you’ve accomplished, what didn’t go so well, and how you can improve. It’s a safe place where you can expose your problems and congratulate those who have done an excellent job.

Despite not being something required in Kanban (in Scrum, it is done at the end of each sprint), we saw value in it and kept it. In fact, we started to do them weekly instead of every two weeks, allowing us to have a quicker response when some problem arises. We also use these meetings to have a look over the team’s metrics and check for problems and bottlenecks.

Another optional activity that we chose to keep was the story estimation during the refinements. In Scrum, estimates are used to have a better understanding of what fits in a sprint. Since Kanban has no sprints, you would guess that this had no use.

Wrong!

Estimating a story helps to make sure that everyone has the same idea of what is to be done in a story. If someone votes 8 and other people vote 3, it’s clear that the story needs further discussion. Someone could be accounting for a problem that others are not aware of or the other way around, where someone includes extra work that is not to be considered in that story.

To estimate stimulates discussion.

When this happens, it’s clear that not everyone has a clear understanding of what needs to be done.

Another frequent scenario is when the whole team votes for high value (typically, everything above 8). A high value means uncertainty. There is either too much to do or the task has a high level of complexity that makes people uncomfortable. The best practice, in this case, is to split the story into smaller stories with more explicit objectives.

Final Thoughts

Scrum will always have a place in our hearts as the first widespread agile methodology. But as companies are turning to continuous deployment, having a timeboxed sprint no longer makes sense.

There will always be some specific projects where Scrum is the way to go. As companies become more agile over time, though, Kanban will rise to replace Scrum as the most used agile framework.

Original article published at medium.com. Read full article here

The software development world is an always-changing environment. Every year, thousands of new frameworks, technologies, and patterns enter the market. These new options lead people to ask whether they’re using the right ones.

“Am I making a mistake by using an old framework when xpto is out now and claims to make my life a lot easier?”

By their nature, a developer is a person who loves technology. Even more so, when the technology is a new one that not many people have tried. Our thirst for knowledge and trying new things is insatiable. There’s a huge adrenaline rush flowing in our veins when we’re creating something new.

Excitement over your profession can be incredible — when correctly managed.

How Can Enthusiasm Over New Things Be Something to Worry About?

It feels like a paradox. Why worry when our programmers are motivated, positive, and thrilled about something new?

Because excitement over a new solution, approach, technology, or pattern, can lead to people overlooking older solutions and claiming, “XPTO.js is the way to go. We should migrate the whole platform to this new framework now!”

The first time it happens, you may think: “OK, we’ll be spending a few months on the migration, but ultimately we’ll end up with a better, more up-to-date product.” After six months of doing nothing but migration, you finally return to focus on business-related features.

One year later, a wild, unique, revolutionary, over-the-edge new database engine appears. Developers are whispering that this is the future and that we’ll be outdated if we don’t change from QSL to Sacandra.

But this time, migrating all the data brings more risks with it. You decide to take the risk. But instead of six months, your team takes more than a year to complete the migration. There were several differences of paradigm between the technologies. There was almost no information about it on the internet and no knowledge about it within your team. Consequently, your customer support got worse, since the engineering team was focused on migrating to a new technology, rather than serving the customers who keep the business alive.

This is Called Hype-Driven Development

Marek Kirejczyk was one of the first (if not the actual first) people to introduce this topic. Hype-driven development (HDD) is developing software and making decisions based on what’s hot at the moment, rather than actual needs.

In his article, he mentions the various types of HDD, such as the conference driven developer, the stack overflow driven developer, or my personal favorite, the loudest guy driven decisions.

There are several examples of hype-driven development out there. Some include, but are not restricted to, NoSQL, Micro-service architectures, and JavaScript frameworks. In these three cases, we verified a lot of excitement around them. Entire conferences and forums went wild evangelizing these solutions. This led to people implementing them, often for the wrong reasons — because they looked cool, not because they actually needed them.

Make Conscious Decisions!

Every framework/solution/pattern/technology was designed to solve a specific problem. Period. This doesn’t make them better than the others — they simply solve a given problem better.

As a professional, you should always ask yourself what the best solution to your problem is. The answer cmay be the most recent, hot micro-service, or it may be the old, side-kicked, unloved monolith. It just depends on the problem you need to solve.

There are no silver bullets.

You will never find a solution that solves all of your problems. It simply does not exist. Every solution will have strong and weak points. When you advise someone to use a particular solution, make sure you match the problem to the most appropriate solution.

How to Detect a Hype-Driven Developer

Bear in mind that often, hype-driven developers are not necessarily hype-driven all the time. is not an HDD all the time. Usually, it happens on topics of interest to the individual.

There are a few questions you can ask yourself to help you recognize when you’re making a decision based on hype:

• Are you aware of the trade-offs that the new solution brings?
• Do you know the specific problem that it was designed to solve?
• Does the solution have proven efficiency in solving a problem similar to yours?
• Do you know the actual benefits the new solution will bring and how much time it will take to get a return on the investment of migrating?

If you answer noto these questions, you’re probably making an emotional decision rather than a rational one. In this case, I advise you to meet with your team, expose the pros and cons of the migration, and check whether it pays off.

Final Notes

As a developer, you’re the source of truth when it comes to technical decisions. This power comes with the great responsibility of advising your management correctly.

Stay up-to-date with everything that’s released every year and make sure you understand the pros and cons of each. Be a connoisseur when it comes to technology — that’s the way to be a great engineer, not recommending something just because you heard about it at a conference.

First posted at: medium.com. Original article here

In a world that is depending more on technology each day that comes by, the need for IT professionals (let it be software engineers, infrastructure engineers, data scientists, etc.) is turning into an HR nightmare. Finding people that are also looking for a job is almost impossible, and it’s tough to compete with the salaries of the big companies.

However, these profiles are being built in universities like never before. The goal is to fight the need that exists in the market.

But somehow, society still has many misconceptions about what these people can do. I know I’ve heard many of these.

Here are the top misconceptions I have heard about the job I do.

1. Programmers Can Hack My Webcam

This is always fun to hear. And it appears to be motivated by Hollywood.

A programmer is someone that writes computer code and builds software applications. He is not (necessarily) a security expert that knows all the flaws and how to exploit them. And even if he was, that doesn’t mean that he would do that for the sake of looking cool. Most of them only try to exploit systems in a controlled environment while looking for failures that may need to be fixed.

Though a programmer could learn how to do this, most of them have better things to do than trying to hack your webcam.

You’re not that cool.

2. Programmers Don’t Have a Life

Remember Milton from Office Space? Do you think most programmers are introverts, no-lifers, hard-talkers as he is? Think again.

Most developers I’ve had the honor to know are the most hardcore rockers, binge-drinkers, and fun people I’ve ever known. Sure, there is every now and then someone that meets the “stereotype” correctly, but that is not even 1%.

Programmers usually like to meet to grab a few drinks after work on Friday to socialize and relax after a week of hard work.

3. Programmers Can Fix Your PC/Printer

No, mom. I didn’t learn that in college.

Many people still think that someone that takes a degree in computer science should know everything that concerns computers, from hardware to software, peripherals, the best computer specs in the market, what cell phone they should buy.

No. Just stop.

You won’t ask an architect to fix your broken wall, are you? Then why ask a programmer to fix your broken PC? He won’t know anything that is not publicly accessible via Google.

Don’t be lazy. It’s not the programmer’s job to do your research for you.

4. Programmers Are Very Intelligent People

When people don’t understand something, they tend to believe that people who do are superior to them. “They must have a greater intellect in order to be able to understand this difficult matter” — they think.

Not the case.

I’m not going to lie. You have very bright minds in software engineering that can create beautiful logic and put it into code. But most are perfectly reasonable people that happen to like to create new things. Fortunately, they also chose the right area. I believe this happens in every profession. You have both outstanding professionals that turn their job into art, but most are regular people, doing their job.

Programmers are not superior beings with big brains. Probably anyone could do this job if they wanted to.

5. Programming Is a Man’s Job

I’ve heard this by many women friends of mine. Often, when they were talking about how hard it was to get a job in whatever the degree they had, and I suggested a career switch to software engineering.

This way of think is merely ridiculous.

In an age where everyone is fighting for equal rights, equal opportunities, and equal salaries, having someone discarding a career path because it was a “men’s job” is no longer acceptable.

Are there mostly men in going to these college degrees? Yes. Many men love this job.

Does that mean that women should discard that job? Absolutely not. The same way that a man shouldn’t feel intimidated to go to a nurse or education school (where the demographics are more female).

There is no reason for women to discard this career. If they do, it’s because they don’t want to become programmers — plain simple.

6. Programmers Are Great at Math

The one moment where I really needed advanced math skills was at college, to finish all four math courses. Besides that, for about four years that I’ve been working as a Software Engineer, I never needed to use any advanced math to do my job.

This depends on what you are doing at the moment. If you work with VR or videogame development, you will need advanced math skills. But most of the jobs out there are not for these profiles. Usually are more enterprise applications that need maintenance and new features.

Long story short: if you’re bad at math and want to become a programmer, you will have a bad time during college (if you go to college), but it won’t affect you that much on your professional career.

7. Programmers Spend All of Their Time Coding and Looking at Black Screens

What if I told you that I have days where I don’t write a single line of code? You would probably ask: “What do you do, then?”

The job of a software engineer is much more than just writing code.

Before starting to write code, the team needs to plan, estimate, and analyze what is to be done. Plus, we have several meetings where the team gathers to decide how to solve a specific problem. On top of that, we also do code reviews and alignment meetings with other teams.

If you asked me what portion of my time I used to write code, I’d say about 40–50%. The rest of the time I’m doing other activities that require my attention to either allow me to do my job or unblock other people.

8. Programmers Know All the Code Syntax Out of Memory

The process of coding is closer to a way of thinking than writing. The big challenge is to think like a machine and write the actions for the machine to execute.

No programmer writes as fast as you see in movies neither know all the syntax out of memory. We don’t need to. Google is here for a reason.

After some time using the same commands over and over again, many of them will get stuck in your head. But you don’t need to force yourself to memorize them.

With dozens of programming languages out there, it’s impossible to know the syntax of them all. But if you have the right way of thinking, you will just need to translate your thoughts to the language that you need. Plus, the syntax of most languages is very identical between each other.

Final Thought

Programming will become something that everyone knows a little bit about. In the same way that you have history lessons at school, you will also have programming lessons. Over time, that will turn into a better understanding of this activity, and fewer misconceptions will be made as a consequence.

It will also help with the lack of professionals that are needed in the market, by exposing kids to this profession, that many don’t get to know until college.

8 Misconceptions About Programmers That Will Change Your Opinion About Them => Read the original article here

But what is this, really?

According to Wikipedia, legacy code is:

“Code inserted into modern software for the purpose of maintaining an older or previously supported feature.”

In other words, code developed in different circumstances, to support an old feature that is part of your product.

In reality, the most common cause for this to happen is when reality changes. Software is developed, taking into account several requirements for each feature. These requirements are essentially from two types: functional and non-functional. The first type tightly connects to the business you are in. It reflects what your product is supposed to do, describing business rules and restrictions. The second type links to restrictions that are related to the environment of your business. It refers to problems such as availability, security, performance, and reliability.

When looking at these two types of requirements, it’s easy to see which one is more subject to change. As your business changes, your product also must change. Usually, this leads to changes in code that you initially didn’t think of, and causes it to have a more flawed design than you wished.

Legacy code creation is directly proportional to the number of change requests that you get

This relation brings a question: “If that’s true, how do you kill legacy when you’re in a highly volatile business?”

Quick answer: you don’t. 

In this case, it is common for the business to change more often than you develop your product, which leads to having new features that are born legacy.

If your product serves a highly volatile business, you don’t kill legacy. You manage it

Managing legacy

A legacy-free product is a product that serves no purpose. We all need to remember that software only exists to support specific business needs and that those needs will change. Frequently. That’s why the only software that can be legacy-free is the one that serves no business.

As much as you try, you will always have your fair share of legacy code. And that’s a good thing! It means that it is useful enough for someone to need a change.

Isolate your legacy code

Legacy code is typically code that was already tested in the most challenging environment of all: production. It usually means that those features are stable and solve the problem, as described in the first requirements.

Avoid keeping maintenance on that code. If new requirements arrive, only then consider the migration to a new service.

Understand the value of those features

And I mean money-wise. Not personal or emotional value. If it is a significant part of your income, it may be worth the time to rethink how it should be implemented. But it’s common for the legacy features to have more costs than benefits. These costs increase even more when you take into account the maintenance costs. In this case, the best you can do is to set a date for that given feature to be deprecated. After that date, delete the code that is no longer used. Otherwise, it will cause entropy. And if you need it, you still have it in version control.

Legacy Code vs. Technical Debt

These two concepts are often mistakenly used. It is common to hear someone saying: “I hate to work in the application X because it is legacy.” This accusation is hardly true. A legacy product doesn’t necessarily have a poorly written code. One thing is an application that supports an old feature, designed for another reality. Another is an application that has lousy code, hard to read, and with dependencies all over the place.

But why are those concepts so often connected?

Since 2008 we’ve seen a boom of startups rising from nowhere. Everyone went wild, implementing their ideas, and trying to put them to the market. “The early bird gets the worm” is an old proverb.

Most companies were competing with time itself and needed to put their product live as soon as possible.

Rush is the enemy of perfection

The business needs require any startup to have their products shipped before there was any time to think or evaluate possible alternatives to the fastest solution. It led to most MVPs to be shipped without much attention to code quality, especially when it comes to readability and scalability. There were other priorities in the game. That’s why most legacy products (which are common to be the company’s MVPs) are full of technical debt.

But slowness is enemy of objective

However, this is needed for a company to survive. As I mentioned before, any software is just a tool that supports a business. We should never forget that. If these startups didn’t place their products in the market as fast as they did, they would probably not be here anymore.

Respect your legacy!