Thursday, May 24, 2018

Most Common Mistakes During the Transition to Agile (Part 2) | Supreme Agile

תוצאת תמונה עבור ‪agile transformation‬‏
When examining the last few years, we can see the extended amount of organizations that use Agile frameworks (Especially Scrum) as the preferred software development methodology. Some organizations had a massive success implementing and adopting Agile. While other organizations achieved partial success due to well-known problems that I will cover in this article.

Well, how can it be that organizations fail to adopt Agile? This is despite the fact that it is well known, there are many implementers, coaches and endless knowledge on the internet that is available for everyone. 

Well, the answer is not surprising and relatively simple. Agile is a document with a set of principles and values that are interpreted differently by different people. The direct result of this interpretation is the creation of too many ways to implement the method and the abandon of the real spirit of what this document really represents. 

This article will present some of the most common pitfalls made in organizations while implementing Agile. My recommendation for you is to pay attention to each one of the items described below and to ensure that you avoid them to achieve a successful transition process. 

Mistake #13 – Playing the “Blame” Game

Scrum uses ‘Teams’ and not ‘individuals’ therefore it is hugely important that all team members will work together to achieve a common goal. As part of this approach, scrum teams will succeed or fail as a single unit; there is no room for blaming one person or another.

There is huge importance that the team will understand this from the beginning. Any other approach will not contribute to the sense of collaborative ownership, Innovation and a solid learning environment that will allow the team to grow. 

Mistake #14 –Unsuitable Physical Environment

Scrum embraces “Face-to-face” communication. Therefore, we must ensure the physical environment allows the Scrum team to work together in the same physical area (We must ensure the team will get the environment that will allow them to work as a single unit).

In addition, the environment must be a physically supportive so to allow the team to perform the different Scrum ceremonies. The location should allow the team to focus on the meeting agenda and to remove any external interruptions that can affect their concentration.

Mistake #15 – Bottom-Up instead of Top-Down

I saw so many implementations that completely fail due to the missing understanding that you cannot scale Agile prior to resolving the more basic issues that you will find in almost all Agile transitions. Once the organization decided to make an Agile transition, we should start by resolving the most common problems first; these problems related to communication issues, organization culture and the state of mind.

To allow the organization to scale an Agile project; you first need to resolve these basic issues, so try to start from Bottom-Up instead of Top-Down, once you have the building blocks at a team level, you can add the second level of scaling Agile. 

Mistake #16 – The Agile Mindset

There is a Hugh difference between ‘Doing Agile’ and ‘Being Agile’; the most important factor that differentiates between them is the mindset of the people involved in the process. Agile demands a different mindset from what people used to have in old traditional methodologies (e.g. waterfall).

Know this; you will fail to make a successful transition if your clients will keep their old habits that rely on a previous mindset. Your main goal should be to change this mindset by showing them the Hugh benefits of Agile. This includes why it is good for them as well as for the organization.

Mistake #17 – It is easy to do it if you understand it

I think that it is a basic assumption that people will be more dedicated to any change if they first understand the logical reasons that led to the change. People need to understand why Agile was chosen as the preferred approach to handle the organization goals and what are the ‘principles and values’ they will need to embrace in order to succeed.

Mistake #18 – Micro Management

Following the Agile manifesto, there is no room for micromanagement, scrum masters, Product Owners and even the scrum facilitators are not allowed to determine the amount of work that the team will accomplish per iteration, Assign tasks or tell the team members what to do.

Scrum provides ceremonies whose primary function is to increase visibility, communication and the transparency of the current project state.

Mistake #19 – Commitment is just a buzzword

It is simple, without real commitment you will fail at anything in life. This is the same as setting a goal to reduce 20Kg from your weight without making a real change in your current lifestyle. Agile is no different. To be able to make a successful transition, it is not enough to want it, people must be truly committed to the process with the understanding that they will need to make major changes in their state of mind and how they work.  Believe me, it is not obvious that people will agree to do it once they really understand the consequences.

Mistake #20 – Agile is a never-ending journey

I really don’t like to describe it as a mistake, but once you choose to be Agile you need to understand that it’s a never-ending journey of learning. It is most probably the best way for the organization to keep consistent growth.

Mistake #21 – Planning in Agile? What for?

Planning is a key part of any Agile project. This is especially important once we start to make a transition from traditional methodologies. The common pitfall I often see in many organizations is the misunderstanding that planning can be ignored because Agile does not use upfront planning, this is wrong!!

In Agile, there is no “Less” planning, the main difference is that we do it differently. Instead of doing one major planning at the start of the project (Traditional Methods), we now perform a “High-Level” planning at the start of the project and then consequently micro-planning is conducted rapidly prior to the start of each new iteration. 

Mistake #22 – Documentation in Agile? Really?

We are doing Agile, so there is no reason to use Documentation anymore! Well, No. although the Agile manifesto species that we should aim for a “Working Software” instead of “Comprehensive Documentation” it does not say anything about ignoring documentation or not using it at the different phases of the project.

The main difference in Agile is we can do it per iteration and not in a single static document at the start of the project (due to obvious reasons of maintenance and changed requirements that arise during the project).

Mistake #23 – Relying on “Best Practices”

In the last five years, I was involved in more than 50 Agile transitions that were made in both small and large organizations. During this time I come to a single conclusion that each transition is different, there are no best practices that you can take and enforce on one organization because it worked in another. Each transition is different because the factors are not the same for all organizations, just think about the organizational culture, team majority and the organization real readiness to make the change.

My best TIP that closes this article is to not use any “Guide” book, Checklist or “Best Practices” during Agile transitions. instead, investigate the organization, its state of mind, the organization needs and goals. Only once you understand these areas then you can start to build a worthy plan to perform a successful transition, any other solution will fail even before you had the chance to try it. 

Thursday, May 17, 2018

What does it mean to be an Agile tester? | Supreme Agile

In the recent years, the software industry has made a massive transition towards more advanced software development techniques. These are replacing the traditional SDLC methodologies that are now much less attractive for organizations. This is especially true for those that need to deliver their products faster in the consistently increasing competitive software industry.

If you are part of this world, you are probably aware that agile software development is the number one alternative method used by the organization. There are many reasons for this. The main reasons are that it embraces team collaboration, increases transparency, lower costs, increases ROI for the customer and has the ability to deliver product faster and within shorter timeframes.

However, this article is about testing. Therefore, it is more important to understand the new role of an 'Agile' tester in this “new world” 

The testing processes

In traditional testing, testers would start their tests (Dynamic tests, Static tests can start earlier) only after the coding phase was completed. The basic process was the test team receives a build that meets the testing 'Entry' criteria from their development team. Once received, the testers would run their preliminary written tests based on traditional test documentation such as STP/D. they would try their best knowledge effort and skills to uncover defects.

In an agile project, testers are involved in the project from the beginning. This includes many activities such as requirements (PBI's) gathering, working simultaneity with developers and the actual testing per iteration. This means the demand from testers has increased. The testers would need to have both the technical and personal skills to contribute to the team so they are able to deliver high-quality products.

What's An Agile Tester is all about?

An Agile tester should be a professional tester who has the knowledge and experience in the quality assurance (Tools, Advanced test methods Etc.) field. This would allow him to support and assist the team (That usually contains more developers) to meet the quality challenges the team may encounter throughout the project.

The Agile tester must be capable to work in a continually changed environment. Thus making the test effort more difficult and challenging than in traditional SLDCs (There is no time to prepare test cases with an unrealistic number of steps or even write an in-depth test plan).

The Agile tester must be a quick learner to understand the customer needs. This is in order to assist the PO and the team to understand the real customer software requirements. This would also allow him to facilitate testing for a particular sprint (Remember DoD of a user story will not approve without the necessary tests).

The Agile tester must have the correct attitude.  This is crucial to their ability to succeed as an agile team member. The correct attitude will allow the team to see another view of the product from a client perspective. It will assist the team to gain a better understanding of what the customer really needs.

The Agile tester must possess great communication skills. This is because there is no separation between the different departments any longer. As a team member, the tester will have to work closely with other team members, especially the developers. Therefore the tester must have the skills to drive testing in his team in order to increase quality, reduce technical debt and automated all tests that can be automated. 

Monday, May 14, 2018

Testers are not the "Quality" officers in a Agile teams | Supreme Agile

What makes a team really "Agile"? To me, an agile team is one that follows the simple values and principles of the Agile Manifesto but knows how to take them a step further. Although the Agile Manifesto created the foundations of all it’s frameworks (Scrum, EP, Lean Etc.), it’s still not a religion that the team should follow blindly.

An Agile team should have the power to learn new things. They should combine artifacts that work great in other frameworks, innovate new development techniques and find the balance between an Agile Spirit and what is more practical that works for them.

There is one thing an Agile team must follow and that is the simple mission that the customer is the most important stakeholder. Therefore the team should always focus on making on delivering the best possible product that meets the customer’s requirements.

From my experience, if a team focuses on this single mission.  It will formulate a team that will deliver the best quality product. In addition, the team will become disciplined (work as a single unit), always search for new learning materials to help them succeed with the project goals. Most importantly it would allow them to share their knowledge, experience, and skills with each other.

In conclusion, the most successful projects are those who focus on customer requirement, have a team of great people who worked together without any ego and senior management allow the team to maximize both their technical and personal abilities. 

And what about the quality owner?

Starting from the end, there is a reason I wrote this long introduction. If you focused on it, it should be clear to you why there is not "Quality" officer in a Scrum team. This is because it goes against the whole idea of collaborative work. Quality is a state of mind, it starts from the very basic phases which involve all team members. If done correctly, the quality ownership jointly shared among all team members and not only the tester.

From my personal point of view, the Agile tester is just a new role name created to allow a more efficient transformation from traditional methodologies. Think about a company that worked in waterfall SDLC. The company had 100 pure testers in a single department, now the organization decided to start transitioning to Agile SDLC. This results in massive concerns rising from this department (You will see it in any transitions) about what their role will be in the new Scrum teams.

One option is to release all testers that are not suitable to work in this methodology (Believe me that if it was simple, you will saw it more often).  This is least preferred option by most organizations. The second option, often used, is to "Sell" these kind of employees as "Agile Tester", "Quality Champion", Quality enforcer etc. (Ask yourself are there new names for other crucial roles such as "Agile Developer", "Agile DBA" or any other names that may sound better but just the same).

Let us be clear, the set of skills and personality that make someone great as a Tester within an Agile team is almost the same as those used in other SDLC methodologies. The main difference is that in an Agile team, the Tester is part of a wider team that includes also developers, analysts, DBA's and sometimes even other testers.

In addition, the Agile tester should not see himself as the team quality officer and this takes the responsibility for all quality related issues (It is a catastrophe ready to happen). 
Throughout my career, I have seen many failed teams seeking to “protect” customers from "terrible" team members who do not know enough about quality. From an Agile perspective, this is the last thing you want to hear from one of your team members.

A true tester in an Agile team (If it easier for you, call it an agile tester (AT)…) is a person who has the knowledge and experience to know that quality is related to all aspects of the project. Part of this includes full stakeholders involvement. If there are missing quality aspects, it’s become his responsibility to gather and share information about the missing quality artifacts. As part of this process, the AT can do it with the other team members or/and the product owner. The AT can also act as a bridge to other quality issues that may affect other teams.

Testers in Agile teams, as well as other team members who have the right skills and mindset, are continually looking for new ways for the team to do a better job of producing high-quality software. The main point here is to know that any team member can do it, this function/responsibility is not solely owned by the agile "Tester". It should be the effort of the entire team.

To conclude: the best Agile groups were built by developers, without any pure testers who had the current state of mind and understanding of the importance of quality.

Testers in agile teams, what’s next?

As I described at the beginning of this article, testers in Agile teams are just another team member who contributes to the main goal. Testers are not quality officers and are not solely responsible for the quality deliverables. The bottom line is Agile teams should include personnel who have the relevant skills and knowledge to meet the overall goal of the project as well as quality objectives.

Testers in agile teams, like their agile teammates, enjoy acquiring new knowledge and skills that allow them to undertake new challenges from project to project or even from sprint to sprint.  Testers should NOT limit themselves to handle only testing issues. This would be a Hugh mistake for both them and the team. Testers must view themselves as equal to any other team member that can address any kind of issue that might arise during the project (as long as they have the necessary skills, experience, and knowledge).

Agile teams can benefit from their testers (again, only if they have what it really takes to be part of the team) in many different areas such as: 
  • Testers can provide some great insights into what it takes to improve the quality of the product.
  • Testers can help to define the "Definition of Done (DoD)" of user stories.
  • Testers can add creativity and new ideas to perform a robust testing process.
  • Testers can help the team to design, Write and execute both manual and automated tests.
  • Testers can help the team to understand the testing scope of PBi's to provide better time estimations.
  • Testers can participate at all levels of the project and add their vision about the project requirements, Design and testability.
  • Testers have an instinct and wide understanding of where and how the software might fail. Therefore, can assist the team developers to write a better code.
  • Testers can help other team members to write tests in different testing layers (Unit, Component, integration, and system).
  • Testers should have a wide perspective and vision about the product, as such, they can assist the team and the PO to create more elegant solutions.
  • Testers can do test reviews for other team members to ensure good coverage and testability. 

My Presentations