SAFe

Can You Really Play Agile SAFe?

Agile SAFe has been touted by some as being a good solution for the implementation of agile in larger organisations.

However, ever since the idea was first initiated it has been a cause of controversy and disagreement in the agile community. It is helpful to assess whether organisations can really play agile SAFe, considering its benefits and challenges. It is also useful to think about practical factors associated with its implementation, to try and make any use of agile SAFe as beneficial as possible for organisations. These points are considered below.

What Is Agile SAFe?

Before progressing, it is important to understand what is meant by agile SAFe. SAFe is an approach that was put forward in 2011, with a view to aiding software development teams to get improved products to market at a greater speed. SAFe stands for Scaled Agile Framework, and since its conception, organisations have been working to build tools that can help with its implementation within larger organisations. SAFe is a framework that aims to help in situations where scale is a factor. Working within SAFe, there is thought to be an improved collaboration, especially across different teams, and the making of decisions is centralised. SAFe generally works with a Scrum central to the process, but there is a larger sprint which operates across several teams. Each of these teams uses smaller sprints.

Benefits Of SAFe

Advocates of the SAFe approach argue that this framework allows its users to use agile at scale. It is suggested that SAFe offers an increased level of agility and a more thorough agile implementation. Proponents of the approach argue that while SAFe may not be as effective as putting a pure agile system in place, in fact, it does at least offer a starting point for bigger organisations to put in place more of an agile system. It is therefore suggested that SAFe is not really an absolute target, but rather that it may be used to get organisations moving in a direction towards real agility. It provides an opportunity for large organisations to gain some of the benefits of agile when they otherwise might not be able to. This may be considered to benefit enough by some organisations.

Challenges With SAFe

While SAFe appeared at first to offer an excellent solution as a scaled approach, in fact, evidence suggests that it has not delivered the hoped-for benefits. One of the problems with it has been unrealistic expectations within organisations. It is tempting to believe that SAFe can deliver magical results with little energy expended to achieve this. This is not the case. SAFe requires a transformation of mindsets, not just a few days of training. In fact, in 2017 the Association for Project Management found that mindset change is more important than changing methods. As such, SAFe requires fundamental change to organisational activities and behaviour to make it a success. This takes years rather than months to bring about, so it requires significant commitment and effort. It is not a wonder drug that can suddenly deliver tremendous results. In my experience, business leaders do not necessarily appreciate this. Those who believe SAFe is not helpful also argue that no organisation has ever said that it has been hugely beneficial for them. This is problematic.

Thoughts On Adopting Agile SAFe

Many agile experts argue that SAFe should not be adopted as it is not bona fide agile. Further, SAFe has been dubbed "unSAFe" by some of these same individuals. It is felt that SAFe works against one of the fundamental principles of an agile approach, that of focusing on people and their interactions rather than tools and processes. While on paper it might seem that this framework will offer flexibility, it goes against this when it is aimed to implement it from a practical perspective.

On the other hand, it cannot be ignored that agile SAFe may offer some benefits for organisations that want to start along the journey to true agility, and that this framework does offer an important opportunity for larger organisations that might otherwise not be able to make agile work. While SAFe may be a very imperfect solution, it does help with starting to address some of the challenges of project management within larger organisations.

At best, however, it is worth noting that agile SAFe is likely to only work in some organisations, and even then, only some of the time. Each organisation will need to consider its own circumstances and the extent to which it can work on transformation towards an agile mindset as an end goal, for this to be of benefit.

For those that do want to play agile SAFe, it is highly recommended to put in place monitoring and measurement of certain goals. After all, any change ought to deliver benefits including some sort of return on investment. It is worth considering metrics that measure customer satisfaction, productivity, quality (fewer defects), cycle time and release time, stabilisation and employee satisfaction to identify if any of these have improved as a result of putting in place agile SAFe. If not, then the program is not worthwhile.

Summary

Agile SAFe has created a lot of controversy in the agile community. While SAFe does have the potential to bring about some change in working towards a scaled agile approach in larger organisations, there are serious concerns that it may be seen as a "wonder drug" and that many organisations do not put the time or effort required into delivering the transformation of mindsets needed to be truly agile. This can lead to SAFe being considered "unSAFe". Those large organisations that do want to implement SAFe should perhaps view it as an important starting point along the road to eventually becoming truly agile, realising that the journey will take years rather than months. Having in place a system of measurements to ensure that return on investment is achieved through the use of such a program is highly recommended for those organisations that want to play agile SAFe.

See the original article on BA Times.

Do your company have People or Resources?

First of all, I would like to make the corporative approach I'll be using to talk about people and resources clear to everyone.

People - Individuals who have feelings, believes, values, preferences, ambitions, passions and a need to be constantly motivated.

Resources - Everything needed to get something done in a project that has a cost and a production rate embedded. Eventually, when human effort is needed, people might be used as resources.

Now that we clearly understand the difference, let's talk about how companies misuse both, people and resources on its workdays.

It is very common to see companies (especially the Brazilian ones) in a rush to hire people to be used as resources in a given project. And worse, most of the times they try to get the most qualified people for the lowest wages. The problem is that this practice entails in dealing with a set of known issues. If you wanna have a strong corporative culture that will grow multidisciplinary, mature and self-managed teams that will boost your company, this is the wrong way. 

You've got to remember that those resources are people. Putting them together in a team expecting productivity and interaction among them just isn't gonna work. Your company must have a desired employee profile to be fulfilled before hiring. You can't just put an inattentive person in a team full of details driven people. What you think will happen? The answer is very simple, both team and person will be frustrated at the very first interaction, and that's your fault! As result, you'll get low-quality deliverables, deadline breaking, high turnover and money loss due to constant training for new employees (if you train them).

Try to hire people that are like-minded to your company's objectives and policies so your teams may have more engagement in their daily tasks having the big picture in mind.

In another hand, even having team like-minded with your company's culture you still can't forget that they're people. They need to be respected, they need to feel safe and motivated. Throwing tons of tasks to be delivered in record time on then just because they've shown their value as a team isn't gonna work either. There is a very sharp line between motivation and limitation and even knowing it is not easy to find out, you must try.

Treat people like people. If your employees are happy, motivated and confident, probably your customers will be too. 

If your company have a resource-centric culture, people that work for you will treat your company as a resource too, that is, it can be replaced at any time.

When your company have a people-centric culture you will see the advantages of it which I can explain in a future article.

What is SDLC and why do we need it?

In short, SDLC is a software development process. In this post, I will only talk about a few points that I judge important because besides important it's an embracing matter.

SDLC means Software Development Life Cycle. Is a software production process which aims great quality along with low costs and short terms. This process has a detailed plan about how to develop, alter, maintain and replace a software system.


The SDLC has many distinct phases but the most important is to plan, design, build, test and deploy. Some of the most popular development models that use SDLC are:

- Waterfall model
- Spiral model
- Agile model
- Iterative model
- etc.

Obviously that each model has its particularities, which consequently changes or customizes SDLC according to its purpose. However, despite the model being used, it's considered a good practice in SDLC usage to follow:

1 - Conception

• Identify the current problems: What don't we want? Identify the weakness and strengths of the actual system with improvement as a goal.

2 - Elaboration

• Plan: What do we want? Define the requirements of the new software, the resources and effort demanded. Don't forget to list the risks.
  
• Design: How do we get what we want? Translate the new system requirements into functional specifications (it depends on what model is been used) with participation and approval of all stakeholders.

Fail on this might cause the project cancellation or at least overrun its costs.

3 - Construction

• Development: let's create what we want! This phase creates the solution by generating all its code.
  
• Test: Did we get what we wanted? Search for bugs and inefficiencies and correct them until the software meets its specifications.
  
• Deploy: Let's start using what we wanted! This phase is executed with some limitations and depending on end-user feedback some adjustments might be needed.
  
• Maintenance: Let's get this closet to what we want! When used in the real world the solution might not be perfect as expected. Further conditions in the real world might demand some updates on the software to keep it efficient.

Benefits of SDLC

If done right, it can deliver a higher level of management, control and documentation. Developers understand what are they building and why. Everyone agrees on the established objective and the path to achieving it. Also, everyone understands the cost and resources needed.

There are many pitfalls in SDLC usage. It can become a roadblock instead of a facilitator. To fail on the execution of the main phases of SDLC independently of the motivation (cost reduction, meet deadlines, culture and etc.) might bring to you undesired results.

Tools

There are many tools that allow you to manage your project with a satisfactory level of customization to meet company needs.

Here in Montreal we use Redmine to support our SDLC. We're customizing it and maturing the process as the projects are delivered.

It's not easy, it takes time and demands perseverance as you will be breaking paradigms, changing the company's culture and take people out of their comfort zone.


Be insightful and reap the fruits of the SDLC executed in full in the not-so-distant future.

How do you see yourself ten years from now?

This comparison between 2009 and 2019 at social media encouraged me to do some reflection about my achievements. I spent some time to see how I am now and how I was ten years ago. And most important, how I am now and how I want to be ten years from now.

To some people, this kind of reflection might be something to be proud of. To a few people, this might mean nothing as they're at same as they were ten years ago. But, to other people, this might be a motive of great frustration due to some lost or some regression.

The fact is that on our daily tasks we caught ourselves living impulsively not considering a more significant objective or purpose. The problem is that if we take too long to have this perception, there is a risk of being awarded great frustration when looking behind.

But, enough reflection for today. This article's objective is to talk about the next ten years from a planning perspective. I want to encourage you to have a life project, no matter if it is professional, personal or social. Having a project helps you to define an objective, define the required resources to achieve it and how and when you'll make it.

Here follow a few tips that can help you create, execute and accomplish your life project:

1 - Define an objective

Also known as a scope, it means where you want to go and what will be the obtained result after all the done effort.

Define tangible objectives that add value and also are reachable. If you miss one of these characteristics there is a chance of your project fails.

Start with small objectives and define bigger objectives as you achieve them.

2 - Define effort and resources needed

Find out what's gonna take to reach your goal. It might be financial resources, material resources, human resources, intellectual resources and etc. It might be a personal effort, third-party effort, manual effort, mechanical effort, digital and etc. Make sure you have all you need to continue your journey towards your objective timely.

If any resource or effort needed to achieve your objective is not available, your project stops, and for that, you'll have to plan it again. The lack of resources and efforts can even make your project unviable.

Be aware so your resources don't become an objective in smaller projects, but if so, do what you have to do.

3 - Project deadline

Any project must have a deadline, and its execution needs to be sliced in tasks. Define a deadline for your project and also a start and delivery date to the smaller tasks. Remember that tasks consume resources and demand effort, and besides that, they can be predecessors or successors to other tasks with a dependency level between them.

To know how what and when to do things is indispensable to the project's success. It's in the execution of smaller tasks within the given time that you'll have KPIs (Key Performance Indicators).

The project may be delayed or anticipated. What can not happen is give away the objective promptly due to time. If a project is delivered too late, its purpose might not be as valuable as it was on project's start.

4 - Enumerate risk and action plans

Any project is subject to risks, no matter if the risks are an internal or external agent or if they are known or unknown issues. It might be resource unavailability, unforeseen events, objective changes, etc. The fact is that you'll have to enumerate as many risks as you can and establish an action plan for each one in case they become a reality.

As you establish risks, see the impact that may be caused by each one. Some risks have a minimum impact on your project. Some risks cause a problem but they can be mitigated, but there are risks that can make your project unviable.

5 - Write down everything

There is no problem at all in projecting something to your life on your mind only, but surely the action of writing down in a paper, document or sheet makes it formal and externalize your purpose, making you deal with it in a different manner.

Give emphasis to victories and small deliveries, take note of your problems and learn with them. Check if you aren't leaving the path set at the beginning of the project and be persistent. There are some projects that are problematic ones and they demand a lot of you.

Make your project, execute it and deliver something to yourself that used to be virtually impossible to reach before. You will be surprised rather with the achievement or the learned lesson.

Business Analyst Career Path. Where Will You End Up?!

Your career path as a business analyst is highly dependent on your preferences and strengths as an individual.

Not everyone who starts out who is currently a business analyst not necessarily stays there very long.

In my mind, there are basically 4 high-level trajectories your career might go depending on whether you go the BA Specialist route, management route, subject matter expert route or choose to make a lateral movement along the way. So let's break down each.

Business Analyst Specialist route

First, when I say BA Specialist, I mean a person who has decided to hold their skills as a business analyst. They are masters of all competencies in the business analyst body of knowledge and they are well-versed on all the knowledge areas.

This person starts out as a junior business analyst or an entry-level business analyst and travels to level 2, which is a senior business analyst and so forth.

If you go this route your skill set will more cycling drive you to be an enterprise architect, which is kind of a super business analyst. The quick version is that you look at the business as a whole and not just to an individual or silo, and determine strategies for how IT as a whole cant help meet objectives.

Management route

This is pretty straightforward and suitable for people who have a passion to help others grow in their career. 

At this point, you are a mentor to other business analysts and are likely to work as a business analyst lead or manager. Is important to remember that being a manager doesn't mean you can't be something else. For example, enterprise architects might have business analysts working with them.

The Subject Matter Expert (SME) route

The SME route has many flavours and usually revolves around a particular industry like business division or technology. 

Some examples are health information systems BA in the health industry or a human resources information systems BA for the HR's division of companies or a sales force BA specializing in the implementation of sells force for sells organizations.

Industry or subdivisions SME often move into a direct partnership with the business sort of things or just cross over into the business altogether because they're so well-versed in the ins and outs.

Technology experts are most likely to become consultants and help companies adapt to technology successfully.

Making lateral moves route

Last but not least, this has many flavours but the short version of it is that a good business analyst has to dive in the skillsets of many professions like user experience designers, project management, process analysts, product ownership and the list goes on. If business analysts find one of these careers interesting than they can refocus their career in that direction fairly easily.

Do I really need an IT certificate?

"The mind that opens up to a new idea never returns to its original size." - Albert Einstein

 
Because we're passing through the great era of "Digital Transformation," besides the market, the IT sector is being influenced too.  Among several changes that are happening, I want to talk about a specific matter, which is the growing incentive and facilitation to get IT certifications.

A few years ago, to get an IT certification (no matter what speciality), was something that demand effort, dedication and most times, was expensive. The certified professionals were more valued and some of them even were part of a select group, depending on what certification they had.

Nowadays many companies are providing easier ways to get certifications at foundation levels, which in some cases can even be free of charge. This is very common in fashionable matters like Scrum, Agile, DevOPS and etc.

We can clearly see this "certification fever" on LinkedIn when some company decides to make a campaign of study material and certification issuing free of charge.

But, is this a problem? Actually no. What happens is that the fact of certifications at foundation level being popularized creates a tendency of devaluation of those same certificates. A natural reaction of someone who had a hard time studying and expanded a lot of money to get the same certificate in a higher level.

But then did the free, entry-level certifications lost its value? No, but you'll need to be careful to not to become just another professional taken by the fashion of the moment.

I believe that a certification changes the person's mindset. It's impossible that someone who studies for any certification keeps the same old way of thinking. The practice and the experience expands the knowledge acquired and make ir solid. Experience without certification is almost equivalent to certification without experience. Whoever seeks a certification must seek his immersion into the market to put that knowledge into practice.

Knowledge takes no space. We're living the era of knowledge but, unfortunately, there are people who still want to restrain information.