Monday, December 18, 2017

Techniques for an efficient agile retrospective

Inspect and adapt processes is a practice known for a long time and, even today, used by many companies to ensure continuous improvement. It is common, at the end of traditional projects, for the team to meet, together with management, to capture lessons learned in order to benefit future projects.

Although this approach is valid, it often happens that projects are totally different and teams are formed by other people. That is, the context is very different and you can not use the same path of success. In addition, the vast majority of projects usually take months or even years to complete.

These facts indicate that problems encountered over the course of the project will be raised and discussed only at the end, that is, when the project is over and nothing more can be done.

Often, people no longer remember the troubles that happened during the earlier development period. Others remember, but do not want to upset their colleagues or the management and end up repressing the information.

Agile methods often work on short cycles, delivering incremental parts of the product and not just at the end of the project. Retrospectives were adapted to occur at the end of each of these cycles. This is why it is so important because it is possible to reflect over short periods of time and not only when the project is over.



Conducting Retrospectives

Basically, in a retrospective the team stops and analyzes their way of working. There are several ways of conducting retrospectives, the most common of which is the discussion of the following three points:

  • What went well in the sprint? This question helps team members recognize and share the good points, that is, good practices that they should continue to apply in the next sprints.
  • What did not go well in the sprint? Here members are encouraged to look at difficult challenges they faced and obstacles they encountered.
  • What actions can we take so that problems do not recur? This question allows ideas to be raised for improvement actions in order not to go through the same problem.

Reflecting on days or weeks of work brings a lot of benefits to the project and to the people who work on it.

Perhaps, the biggest advantage of doing this reflection in short periods of time, is that the memory is still fresh. If something was bothering anyone, he or she probably still remembers it well. As the project is still in progress, this discomfort can be reported and resolved for the continuation of the project.

The same is true for good practices used by team members. If it is considered beneficial to the project, it can be adopted by the entire team to improve the progress of the project.

Another important factor in hindsight in agile projects is that after the problems and obstacles have been raised, action plans are drawn up for them, by the team itself. This means that the team analyzes what happened, defines the actions and then performs on them themselv. Since it was the team that defined the actions, the commitment is much greater than if they were imposed by management.

By being a staff-only meeting, people tend to feel safer and more comfortable talking freely about their frustrations. In addition, retrospectives tend to discuss problems without raising guilt or making accusations. For this reason, it is important to focus on resolving these barriers and dividing responsibilities among team members so that changes will actually happen.

A key point is the learning obtained in retrospectives. The learning culture germinates the moment a team realizes its deficiencies and begins to take regular steps towards improvement. Implementing improvement practices is necessary so that team members do not repeat the same mistakes in the future. They evolve as individuals and contribute as better team players.

It is also very valuable to capture the positive aspects, that is, all that was good. Recognize hard work, identify and share successful practices so that they continue to be applied by the team.

Continuing practice of retrospectives results in finding more efficient ways of working and delivering better value to customers. With every retrospective the team grows and improves their efficiency. 

It is worth mentioning that there are many teams that ignore retrospectives in order not to waste time. However, ignoring the Retrospective meeting causes the feedback to not be shared between the team, leaving no chance for improvements that the team could work on.

How to structure an efficient retrospective

First meeting point

Each team member notes on post-its the strengths and weaknesses of a sprint.

Different colors can be used to differentiate positive points from negative points.

The Scrum Master is responsible for giving a time limit so that the team is focused on the objective of individually evaluating what it considered good and what it considered bad in the sprint in evaluation. 10 minutes is a good time to keep the team focused on this first stage of the meeting. Of course we devalue the time required in function of the total time that was stipulated for the retrospective.

Second meeting point

Each team member presents the positive points he or she has raised and the team discusses them.

After all the positive points have been presented, all of the team's negative points are presented one by one and the team evaluates them and tries to come up with a solution for each one.

The Scrum Master supports the team to focus on the main objective of the meeting: Raise solutions for improvements.

The importance of providing solutions to problems

It is no use for the team to discuss the whole meeting about  problems of a sprint and to end it without any proposed solution to them. The problems will remain. The Scrum Master should lead the team so that at the end of the meeting there are concrete solutions to what will be done to improve each negative point. 

Of course realizing that the team is not mature yet the Scrum Master can propose ideas for the team to work on, discuss and improve them according to what the team judges best for the improvement of their work.

Conclusion

If you were to remember just one thing from this blog article, it should be that restropective meetings are important to grow your team and improve their efficiency in their current and future projects. The second most important point is that your retrospectives should have a clear structure and be directed towards identifying and discussing actionable ideas for improvement.

Sunday, December 10, 2017

How to integrate UX with Agile Methods

Agile Methods are common in software development and the use of these methods has been practiced in many companies and teams for several years. However, it is often difficult to fit the design of UX (User Experience) into this type of work methodology. 

At what time does the design come in? At the beginning? At the end? In the middle? 

In this article we will take a look at some of concepts and best practices that can help agile teams to improve the user experience in their projects.




Agile vs. UX

These two approaches use different ways of allocating resources in a project. On the one hand, through short iterations, agile methods focus efforts to deliver small sets of software functionality to customers as quickly as possible. On the other hand, the User Experience approach advocates spending efforts on researching and analyzing user behavior before development begins. Using Agile Methods, the product is often launched quickly, without the UX process being completed or at least being started.

In Agile Methods the development versions are periodically delivered to customers. Feedback from these clients influences the current implementation cycle and directs the planning of future cycles. The customer is not a person outside the product team, who buys or uses the product, it interferes with the product team's decision making.

While these feedbacks are precious for the development team, they are often limited by the scope of the current development sprint. Furthermore, in order to really gather a good understanding of the user experience, it is often necessary to observe the behavior of the user while he or she is using and interacting with the application. 

Undoubtedly there are several ways to integrate UX and agile methodologies and the right thing is to choose the way that best suits your situation and availability of resources.

While it is important to have UX experts, people who know the basics about information architecture, interaction design, visual design and all themes related to the user experience, UX should be a concern of all people on the team. There is no reason for the PO and team members not to worry about the issue and leave everything in the hands of a specialist. 

All members of the agile team should know the basics of UX.


Practices to integrate UX and Agile Methods

The best practice for incorporating UX with Agile Methods is to build a regular cadence of engagement with the user. The purpose is to engage users to investigate their experience in using the product, to investigate their behavior and sequence of activities when using the software. For this, it is recommended to incorporate usability tests in all stages of the development process in order to improve the UX of the software as well as to promote a closer proximity between the product, the brand and the user.

Here are some suggestions for user participation that can help to improve the user experience:

  • Research:
    User Experience research activities and requirements gathering depend on whether what is going to be developed is a new functionality or an improvement on an existing one. For a completely new functionality, users are interviewed to investigate their needs and understand the domain, context, and limitations of the user regarding the new tool. For the improvement of an existing one, it is recommended a usability test with the functionality in question to identify the good parts that should be maintained or emphasized and the bad parts that cause problems to the users.
  • Usability tests with prototypes:
    Defined the scope of the iteration it is recommended to make a low fidelity prototype and test it with internal users who are real users of the software and who will perform operations level tasks. It is interesting to have at least two different solutions for the test. The feedback you collect helps validate the concept.
  • Usability tests with MVP (Minimum Viable Product):
    Once the solution is defined an MVP is developed to be tested with external users. Observing users interacting with the system and performing key tasks allows you to evaluate the hierarchy of information and your experience with the interface. Feedback is real, and you can apply it directly to improve the experience.


The need for constant testing is the main reason for faster and cheaper analyzes. This method has a huge impact on collaboration among those involved in a project because it deepens the understanding of the users in the product development process in the team, and this is a very powerful approach. However, the difficulty in performing these tests is known. In order for the team to achieve a higher level of credibility, it is necessary to educate all members about usability practices.


Agile practices that can be incorporated into UX

As we have seen, agile methods and UX design, despite having different concepts, can be integrated to generate a final result that brings more efficiency and satisfaction to the client.

Plan the entire product for 6 months and then release. It gives us the possibility of the product being outdated even before its launch. This is one of the reasons agile methods are being incorporated by so many companies and other disciplines like UX.

In UX the application of techniques like Kanban has become very popular very fast with the help of agile concepts. Today we have many UX professionals creating their own kanbans to solve problems in a collaborative, fast and effective way. Most kanbans aim to bring the product user closer to the team responsible for product development.

Following this precept, below are some characteristics of the agility to assist in the tasks of UX design:

  • Anticipate the design as soon as possible:
    A common situation for the design team is that they need to receive more input from the client or the research team before they begin to design the screens. But this attitude goes completely against the "agile" philosophy. Make some deductions, work with some assumptions, fork out a few paths - but anticipate the design as soon as possible. When the inputs come in, you make adaptations to design and incorporate new features. But almost always the skeleton of the functionality you are designing will not change, whatever input it may be.
  • Accept changes and uncertainties:
    If you are always the first to complain when the client asks you to change something or send something important at the time, agile methods may not be for you. Accept that your designs are changeable and use this to your advantage. Gradually you will realize that these changes are making your product more robust and more consistent. Be an optimist, above all else.
  • Get out of your desk more often:
    In such projects many decisions are made in informal conversations. Be out of your desk with more frequency. When a decision is made without everyone's present, help to communicate it clearly to all, and more importantly, communicate to the Product Owner. Being aware of what is being spoken around you can prevent miscommunication problems from happening. Do not be  afraid to get in the middle of someone's conversation when you feel like you should be a part of it.
  • Keep a shared library:
    Establish constant meetings with the team to align in detail how each element of the screen should work. When you come to some conclusion, update your documentation so that everything is standardized - or else communicate the new standard to everyone. Keep a library of UI patterns somewhere easily accessible, so that the next screens that are drawn already contain these formats and avoid duplicity of styles.
  • Meet often but shorter:
    One of the great advantages of agile methods (such as Scrum) is the daily meeting. In addition to this initial meeting, plan your day in advance and schedule other meetings with each of the areas - but always in that 15-minute format with no delays. Often the initial impression is that in a few days there will be nothing to talk about in these meetings, but when the project progresses and new unforseen issues arise this impression gets quickly disproved. Make sure to stay on focus. Don't let your project status meeting digress into some discussion about the implementation details. Schedule seperate meetings instead. 
  • Align quality expectations:
    It is common that at the beginning of the project, when people do not know each other, misalignments exist regarding the expected quality of the final product. That is why it is important to make these quality goals clear.



Lean UX: An agile alternative for traditional UX

Traditionally, User Experience Design and its variables of Interaction Design, User Interface Design, Information Architecture, among others, are work based on deliverables. These deliverables are structures that define stages of a UX project, such as: Wireframes, Sitemaps, Flows, among others.

Lean UX came exactly to focus the daily update of all these deliverables to spend that time more deeply on the user experience and its variables within the project.

Have a prototype to validate internally and test externally. The key here is to gather feedback from everyone, as it is much easier to make meaningful and low-cost changes when the product is still at an early development stage. That's why Lean UX is so well-suited for creating an MVP.

Conclusion

User experience plays an important role in the perceived quality of your application. Use this to your advantage by incorporating UX design early in your development and project planning, regardless of the methodology used - be it agile or traditional.

Saturday, December 2, 2017

Gamification in the context of software development

Software development is a prolonged and demanding activity that requires not only a deep cognitive engagement but also creativity. Software developers, who repeatedly solve challenging problems and acquire new skills to do so, can lose their intrinsic motivation over time, which inevitably leads to the progressive degradation of the quality of their work. 

In the recent years, researchers and software development companies alike have started to explore the ways in which gamification could be applied in the context of software development to provide positive reinforcement and a sense of accomplishment to software developers. 



What Is Gamification? 

In their influential book "For the Win: How Game Thinking Can Revolutionize Your Business" Kevin Werbach and Dan Hunter define gamification as the use of game elements and game design techniques in non-game contexts. 

The concept of gamification is sometimes confused with game theory, which is the study of mathematical models of conflict and cooperation between intelligent, rational decision-makers. Whereas game theory is concerned with the human desire to maximize gains and minimize losses, gamification is all about "turning something not a game into a game" as Richard Bartle, the inventor of the first MUD (Multi-User Dungeon) game, defined gamification.

What Is a Game?

To understand how to turn something that is not a game into a game, we need to first understand what are the core defining characteristics of all games.

According to Jane McGonigal, the author of "Reality is Broken: Why Games Make Us Better and How They Can Change the World" all games have the following defining characteristics: 

  • Goal: The goal of a game gives players something to strive for and motivates them to play the game as it was intended to be played. Without a goal, players would have to explore how the game can be interacted with, which, while entertaining, would be unproductive in the context of software development. 
  • Rules: As counter-intuitive as it may sound, rules boost creativity by providing direction. In a famous experiment, Haught-Tromp and colleagues recruited 64 undergraduates and asked them to write a series of rhymes. One half of the participants were given eight specific nouns, while the other half could use any nouns. "Participants generated more creative rhymes when they had to work with the externally imposed constraint of a given noun", wrote the judges who evaluated the rhymes. 
  • Feedback system: The feedback system serves two purposes: first, it provides positive encouragement when players successfully reach the goal of the game; second, it informs players how much they need to improve in order to successfully reach the goal of the game in case they fail to do so. 
  • Voluntary participation: Kene Boun My and Benoît Chalvignac have studied the effect of voluntary participation in the context of a collective-good experiment and discovered that voluntary participation could induce a recovery of cooperation levels when the payoff yielded by the exit option is high enough, so that the usually observed decay of average contribution levels can be counteracted. Without voluntary participation, games stop being games and turn into tasks, and tasks don’t have the same positive effect when it comes to overcoming unnecessary obstacles as games.


Examples of Gamification

Perhaps the best-known example of gamification in practice, one that most software developers are already familiar with, is the popular question-and-answer site for developers Stack Overflow, which describes itself as the largest, most trusted online community for developers to learn, share their programming knowledge, and build their careers.

On Stack Overflow, users can receive reward points and badges for answering the questions of other users or spreading links to questions and answers via social media websites. According to Stack Overflow’s help center, a person is awarded 10 reputation points for receiving an upvote on an answer given to a question and 5 reputation points for receiving an upvote on a submitted question.

Another particularly relevant example of gamification is Visual Studio Achievements. This extension for Visual Studio allows software developers to earn achievements for performing various coding feats or exploring some of the less-known features of Visual Studio.

Gamifying Software Development 

"Gamification, if applied to software development, may provide several advantages. First, because of its rewarding mechanisms, it may motivate developers to learn new technologies and increase their productivity (e.g., the Visual Studio Achievements). Second, it may improve the quality of their work if adopted to encourage best practices (e.g., testing, code conventions, etc.). From a management perspective, it may be used as input to give economic incentives and to support the evaluation of employees as well as of teams", claim researchers Daniel J. Dubois and Giordano Tamburrelli.

According to Pew Research Center, 53 percent of technology stakeholders said that the use of gamification would be widespread by 2020, and the other 42 percent predicted that gamification would play an important role, but would not be as widespread.
Clearly, gamification has its place in software development, and there are already several gamification frameworks for software development, some using cognitive principles, while others are focusing on improving the quality of the software development lifecycle.

Most gamification frameworks and real-world implementations use the PLB Triad. "Points, Badges, and Leaderboards are … widely used in gamification systems, because they appear to work moderately well as extrinsic motivators", state the researchers from the University of Lugano, Switzerland

To introduce gamification systems, such as the PLB Triad, on a real or virtual system, it’s necessary to understand where to derive value from to encourage a certain behavior, and it's also necessary to design sufficiently interesting activities and avoid tension with other motivational structures. 

The Swiss researchers argue that because adopting a gamification system means modifying the behavior of people and influencing their routine, the adoption might actually backfire. "As such, it represents a delicate matter that may negatively impact well-functioning parts of the system. Put simply: Adding a reward to a boring task may help to motivate the user, but will not turn it into an engaging activity."

Conclusion

While gamification may be the future of certain types of software development, a great deal of caution should be exercised when implementing game-design elements and game principles to improve productivity, learning, and motivation of software developers. There are many individual and contextual differences that need to be accounted for to design a functional gamification system, and large-scale, successful implementations of gamification principles are still fairly scarce. 

Gamification frameworks intended for the context of software development can serve as an excellent starting point and help  companies avoid many potentially costly mistakes.

Sources












Friday, November 17, 2017

How Agile Methods can promote the Digital Transformation in Companies

Lately, much has been said about digital transformation, a concept that goes beyond automating processes, and shows that business models are no longer immobilized, that is, business models must be created and changed continuously. Technologies like Cloud Computing, Big Data, Mobile Payment, IoT (Internet of Things) and Artificial Intelligence offer a great potential for companies that are ready to invest into them and are willing to embrace change.


A new reality in the speed of business changes and disruptive technologies

For the longest time the organizational and management model of companies was based on the concept of operational stability, designed to withstand change. When these eventually arise, companies create long-term strategic projects that try to incorporate all the likely changes they see happening. The goal is to create a new model, also stable, that is long lasting. And the cycle repeats itself. The mental model is clear: long periods of stability, followed by a large break, adaptation to the new model and the consequent stabilization in the new context.

Obviously, this mental model permeated the IT governance guidelines and models. Their processes and methods clearly reflect the quest for stability and resistance to change. It is a vision of slow and gradual change, often backed by bureaucratic hurdles from an extensive list of management approvals.

Due to rapid technological evolution, companies are turning and creating unexpected competition for the market giants. For example, the creation of Uber in the taxi industry, Airbnb in the hotel industry, Netflix in the film and entertainment industry, Whatsapp in the communications industry, among others that directly influence previously stalled and changed business models using what technology currently has to offer as a way to position itself again in a competitive way in the market, causing a rupture in traditional business models, for new forms of business we named disruptive business models.

More and more business innovations are software based and digital businesses move very quickly simply because software changes much faster than physical things. This affects all business sectors. Some have already been affected, others will soon be affected. Rare will be those who will be more or less immune to these ruptures. And even sectors that are considered immune are subject to disruption when the boundaries between the industry sectors themselves begin to collapse. The competition may come unexpectedly from both a software company and from a completely different industry.
That is why many companies are adopting the agile methods in their way of working and are seeing that it is not only a process improvement, but a new strategic need. When it comes to agile methodology, the big challenge is to create agile mindset. It does not only mean having the skills and know-how, but also cultivating an agile team, being supported by the top management of the organization.

Digital Transformation needs Cultural Transformation

Numerous aspects involve organizational changes and new management practices and structure are resilient to be incorporated into corporate culture. Major changes are only possible if there is a change in the way of thinking. In speech, it is common to hear about innovative practices, but what you see in reality are organizations trying to embrace them in the old fashion. This fear is common even in companies that begin to adhere to the agile culture modestly in some areas, indicating that there is a concern in broadening the concept. As long as the transformation does not pass through the company as a whole, it will not produce results. It will only work when it reaches values and infects all employees.

Without this transformation, organizations will have more difficulty coping with the changing times of the digital economy. After all, it is no use bringing technologies that have been developed in this model if the company still does not live this reality. Technological solutions will not solve the way of thinking. So, what happens is a new product being used the old way. Agile Culture has a series of principles that help users receive the news and even direct projects for success, generating more business value and economy.

In times of crisis, recession and change, it is necessary to save, show results, be ready to change direction quickly, focus on delivering greater value in the shortest possible time and cost. It is a daily effort to try to achieve, with a single shot, the right target. Everyone looks for a way to be different, but it's no use just adopting technology. You have to conduct it and implement it in the right way, to the right audience and at the right time.

The beginning of the new dynamic is difficult and requires patience, but in times of need an opportunity to do something different is born. The change is continuous: what we heard as a trend yesterday has already become a reality today and the company can only grow if the organizational structure is ready to receive technological modernization.

Agile Methods to promote the Digital Transformation

Given this scenario of constant change, how can agile methodology help in the delivery of digital transformation? Simple: Unlike traditional methodologies, which require a lot of time to deliver something to the customer, one of the principles of the agile method is to satisfy the customer through deliveries in short timeframes in a continuous and advanced way, always keeping in mind the most important: The added value.

Often delivering something on the shortest time scale, between two to three weeks, causes the customer to see the added value and progress of the product. When we deliver value added, we need to keep three points in mind: 
  • Cost (how much does it cost to do this part of the product?)
  • Business (how much return will this part of the product bring to the business as a whole) and 
  • ROI (how long will it take to get the return on investment?)

Now imagine a project for mobile payment, following the traditional methodology, in which the customer would only receive the product ready, according to the agreed scope after a few months. Are the requirements raised by the client the same as those agreed upon at the beginning of the project? Did the technologies for this type of project have not changed during this period?

Using the agile method there is a better management of the change of requirements, since it assumes that the initial requirements will be altered, even later, that can create a competitive advantage for the client and still be a differential for the company that provides the service.

Another important point when we speak of agile method is the quality question, which is guaranteed through the correct application of best practices, in which frequent tests are performed on each of the functionalities, allowing the identification of any problem in advance necessary for the delivery product is completed within the deadline and specifications agreed with the customer.

Digital transformation today is a reality that has been growing and revolutionizing the IT market. Companies that still use development and delivery methodologies with bureaucratic practices and processes are bound to lose market share to competitors. To prevent this from happening, new processes work as allies and must be adopted by everyone in the company.

DevOps to facilitate the Digital Transformation

Fully integrated with the agility model, the DevOps concept when it comes to software development is also a process that facilitates Digital Transformation.

Traditionally, models such as ITIL have been used for a long time to control change processes by reducing the frequency of these changes and triggering controls if one occurs. In general the traditional process accumulates the changes and makes deliveries at once. The famous changes of releases. This expectation is one of the causes of many user areas investing not because they want to, but by necessity, in the famous "Shadow IT" initiatives, leveraged by offering new cloud alternatives, beyond the reach of IT rigidity. Delivering too late is the same as not delivering, because it does not meet the demand of the business: it was the solution to the problem of yesterday, not to today!

DevOps has another vision: its philosophy is of continuous delivery, with small pieces of code each time. It believes that changes in the business context happen so quickly and so often that waiting to accumulate all of them is putting the business at risk.
Adopting DevOps is not something that happens from one day to another. It is a conceptual change and a mental model. Demand knowledge of new practices and intensive use of technology to automate the software development process to the fullest. Many companies will have greater difficulties due to regulatory issues. Others with an immense legacy of systems are likely to maintain traditional processes in some of their systems and adopt methods such as DevOps in customer facing systems that exploit mobility.

Agility is a mental model. You need to embrace it in your mind before you can start to employ it in your business processes. 

Conclusion

The first step is to recognize that the traditional model has already aged. The second is the decision to embrace change. Agile and DevOps involves new practices such as continuous delivery of new features in small doses, use of dedicated, cross-functional and small teams, loose coupling architecture, automated environment processes, integration and continuous testing and interactive and collaborative environment, with users, operation and development acting together, without friction between sectors, as we see today.

From there, fill the gap of expertise, adopt technologies to automate processes and make cultural and organizational changes, dealing with the inevitable psychological barriers (adverse reaction to changes in the status quo, disbelief, etc.). 

Do you embrace and promote change and adoption of new and agile working patterns in your organization, or do you sit back and watch those who are imprisoned in their old thinking models manage it towards it's collapse?

Saturday, November 11, 2017

Cross Site Scripting (XSS)

Cybercrime has been at an all time high in recent history, with many corporations and online services having suffered through some significant cyber attacks which have been harmful to the safety and privacy of their own data as well as that of their clients. 

Every day new exploits are being discovered or combined in a new clever way, making protection of sensitive customer data increasingly difficult.

One of the more common attack vectors is called Cross Site Scripting. In fact it continues to make it into the OWASP Top 10 Application Security Risks Report year after year.



Cross Site Scripting (or XSS) is a technique by which an attacker gains access to the user session through clever placement and execution of his own malicous code into vulnerable web applications. Instead of attacking the website or service directly, the goal is to hijack the already established session of a user, allowing the attacker to then impersonate his victim.

When properly exploited, a sucessfull Cross Site Scripting attack can have devastating consequences, as it grants the attacker full control over the user session, which in turn allows him to access and modify otherwise protected data.

There are essentially three different types of Cross Site Scripting attacks:

1. Stored XSS

Also known as Persistent XSS or Type I XSS, stored XSS is arguably the worst form of Cross Site Scripting vulnerability. Stored XSS occurs when an attacker is able to sneak his payload into a website in a way that exposes it to other visitors of the site. The perpetrator finds a vulnerability in the website and injects a malicious script into it. This script is designed to collect tokens and session cookies from any user who accesses it. Often times the attacker exploits weak input validation mechanisms of the website in question, allowing him to insert clientside javascript code into the site, for example through a comment field. When other users visit the site, the inserted script gets executed on their computer and transmits their session cookies to the attacker.

A stored XSS attack has a much larger and widespread effect than that of a reflected one primarily because it comes into action each time the webpage is visited, causing harm without even requiring the user to click or enter a particular link. 

These type of XSS attacks generally occur on popular pages, specifically social media sites and sharing platforms with high amounts of traffic, as once exploited, they can spread and grow exponentially in a very short amount of time.

2. Reflected XSS

This is one of the most common and basic forms of web vulnerabilities. In this type of XSS attack, the malicious script is not directly injected into the website but instead requires the user to click on an specially prepared link first. This link is sent to them through email or any other means of communication. When clicked on, the link will take them to the website, where the malicious script will then be embedded into it and "reflected" to the browser. Since the command is coming from the website itself which is a trusted source, albeit reflected, the browser lets it run.

3. DOM Based XSS

When a browser receives the HTML content of the server, it builds the so-called Document Object Model (DOM), allowing client-side scripts to interact with all the different elements of the page. It is an object oriented in-memory representation of the web page.

DOM Based XSS attacks aim to inject the payload into the DOM using vulerabilities of the existing client-side scripts of the targeted website, making them very difficult to detect.

Recent research has found that about 77% of the top 5.000 URL's from Alexa harbor known vulnerabilities in their clientside JavaScript code, making them susceptible to DOM based XSS attacks. 

Measures to prevent XSS attacks

In order to minimize the risk of a sucessfull attack against users of your website or service you should make sure to implement proper input data validation and URL encoding. Ask your users not to click on any links they receive by E-Mail and encourage them to enter the addresses manually into their browser instead.

Most importantly, keep your thrid party frameworks and libraries up-to-date to protect your users against known security vulnerabilities in them.

Saturday, November 4, 2017

Design Thinking and Agile Development

Over the years, software development methodologies have evolved in terms of the sophistication and volume of information needed to develop systems in increasingly complex and integrated environments. With this historical evolution, the main focus was on quality, that is, thus ensuring that traditional software development problems were solved.

All this work ended up generating an excessive load of work, as well as a volume of information often redundant and unnecessary. In order to solve this problem, several studies were done, looking for ways to dampen the software development process, applying the principles of lean thinking, recovering agility lost over time.

In this article we will look at a theme that has been talked about quite a bit in recent years: Design Thinking. But what is the relation between Design Thinking and Agile Development? That's what we'll discover here. 

First, let's take a closer look at the general concept of Design Thinking.


Basic Concepts of Design Thinking

When we talk about this subject, we must first understand that Design Thinking is not a process or a methodology, but rather a philosophy (or way of seeing design) that seeks solutions mainly to analyze the user and its context under different angles and perspectives.

Design Thinking is a new way of thinking and tackling problems. A new mental model.

This approach has some fundamental aspects, such as: Immersion, Analysis and Synthesis, Ideation and Prototyping.



Immersion

Immersion is the initial phase, that is, at which point the project team approaches the context of the problem, both from the point of view of the client and the user.

Analysis and Synthesis

I believe that this is one of the most important moments, because this is where we will begin to have insights for possible ideas, generating some artifacts like personas, empathy map, user journey, among many others.

Ideation

It is the time when the team will begin to generate ideas to solve the identified problems, having as support material the insights created in the previous stage. It is very common to use collective creativity activities (such as brainstorming) and prioritization. It is important to remember that in this phase, it is critical that the team be diversified (developers, designers, business people, administrators, marketing, among others), because the more different skills and experiences are involved, the more ideas will emerge. In the end the team will have several hypotheses prioritized to be validated.

Prototype

At a time when the hypotheses are no longer so abstract and they become something more tangible. In general, paper prototypes are made because of speed and ease of work, but there are also digital prototypes. In either case, they may have low, medium or high fidelity relative to the final "product." After its construction, it is time to validate them with the possible users of your project, product or service. At the end of this phase, the unvalidated hypotheses return to the previous phases to be reworked, otherwise they are only discarded once and for all.

As you can see, Design Thinking is a very collaborative approach, user-oriented (all of its context) and, although it seems to be complex, it is quite simple to apply. But the question is what does all this have in common with the agile world?


Integration between Design Thinking and Agile Development

The motivation for this integration arises from the limitation of each of the approaches: Agile methodologies are limited in relation to practices aimed at understanding the problem to be solved. On the other hand, Design Thinking explores implementation of the products.

It is noticeable that Design Thinking is perfectly aligned with the agile manifesto. Its collaborative aspect shows us that the participation of all stakeholders in the initial stages of the project brings great benefits for all, especially for the client. Only this factor already covers three of the four values found in the agile mindset.

We emphasize that these steps need not be done just at the beginning of the project. Like Scrum, Design Thinking also works as a framework, and can be tailored to your needs throughout the project. However, it is necessary to respect its premises, that is, not leave aside the collaborative aspect and neither the users and their contexts.

It is also clear that Design Thinking is a great way to raise requirements that are totally focused on the needs of users, and can bring very interesting results, such as the greater adherence of your project to your target audience and, consequently, making the return on investment faster for the customer.

However, to be able to identify the needs of the user, it is important that the team is aware that this is not just a "designer thing", that is, its multidisciplinary aspect is paramount to its success, reflecting only the essence of design.

Another point that stands out is that its application within the agile context results in a strand called Agile UX, that is, using the principles of Design Thinking and Lean UX within the Scrum sprint.

The last point that we perceive is its relation with Visual Thinking, that is, to be able to structure ideas in a visual way. Some of the techniques used in Design Thinking are a good example of this issue (business model canvas and map of empathy, for example), and serve as inspiration for facilitation techniques in important ceremonies such as the Sprint Retrospective and even Sprint Zero (or Pre-Game) of Scrum for example.

Therefore, we can verify that the relationship between the agile world and the Design Thinking is much closer than it seems, having as essential factor the collaboration and the multidisciplinarity, being able to bring very good results for all sides. Another interesting point is that by having these characteristics, everyone involved feels more responsible for the project which is a great way to increase the engagement of the team and even the client.

The integration between the two, Design Thinking and Agile Development, is already a reality in companies of the digital world. Where projects are often treated as startups, they are innovative and extremely designed.


A Challenge: Design Thinking and fast development cycles

A challenge encountered in working with Design Thinking and with agile methods is the need to make fast developments cycles. To meet this need, a widely accepted and applied concept is the MVP (Minimum Viable Product).

It consists of developing the product in smaller scales, however, focusing on meeting the expectations, already generating value for the customer. The classic illustration that represents a comparison between iterative development and MVP shows that already in a first delivery the product is already functional and allows the user to perceive its value.

The MVP technique is largely adopted by the followers of agile methods - this method also presents an excellent integration with Design Thinking, since it shares the same principles regarding prototyping.

The combination of these methods allows a significant simplification and acceleration of creative work and solution development, so organizations, companies and individuals can approach the pace at which innovations are being implemented in the digital age, further fueling competitiveness. Are you prepared?

Thursday, October 19, 2017

What is Water-Scrum-Fall?

According to Forrester, although Agile software development has gained tremendous popularity, the reality is that the approach many organizations follow is constrained by both organizational culture and intuitive governance.

"Organizations are increasingly adopting Agile software development methodologies through a combination of bottom-up adoption and top-down change. However, the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels Water-Scrum-Fall," explains Dave West, Director of Research and Vice President at Forrester.

Water-Scrum-fall is typically regarded as a hybrid agile way of working, which originates from the fact that the practitioners of agile methodologies focus on the domain they are most familiar with: software development.

While some, such as Andy Hiles, who gave a talk about Water-Scrum-Fall at the first Agile Greece Summit, believe that Water-Scrum-Fall can be used as a stepping stone to agility, others, such as Cameron McKenzie, a former software engineer who currently specializes in Agile development are convinced that using Water-Scrum-Fall only creates problems and resentment.

To help you come to your own conclusions, we are taking a closer look at both the Waterfall and the Scrum approach, comparing the two and then examining how they relate to the Water-Scrum-Fall approach. 



Waterfall

The Waterfall approach is commonly described as a linear-sequential life cycle model. In other words, the software development process follows clearly defined stages, each of which follows the previous one. 

The typical stages are:

  • Requirement analysis: The requirements of the product to be developed are gathered and captured in a requirement specification document.  
  • System design: Based on the gathered requirements, the design of the product is prepared and used to specify the product’s expected hardware and system requirements.
  • Implementation: Based on the design, small programs, called units, are developed individually and tested for their functionality. 
  • Integration and verification: The developed units are integrated together, and the product as a whole is verified.
  • Deployment: The product is deployed in the customer environment or released into the market.
  • Maintenance: The deployed product is maintained and, optionally, improved.


Each of these stages may take several months, so it often takes a long time for a product to be deployed. The Waterfall approach necessitates that planning is completed before any work begins, which means that it's usually completed before it is entirely understood what the project entails. When system design problems are discovered after the implementation had already begun, the project goes back to the planning stage and starts over.

Scrum

Scrum is a popular implementation of Agile, which is a set of values and principles for software development, described in the Agile Manifesto.

As Andy Hiles says, "Agile is a mindset, a set of guidelines, Scrum is a framework that can be deployed, it has strict rules and events to follow, they are not the same thing. Agile thinking exposes our inability to deliver fast; it drives out what the customer actually wants and improves quality by providing multiple opportunities for continuous feedback, which in turn focuses the developers towards how to build the right thing right."

Scrum breaks down the development process into several smaller pieces, called events, building a minimal feature set and getting the product ready to ship:

  • Sprint: The basic unit of development in Scrum, restricted to a specific duration. Each Sprint starts with planning. 
  • Sprint Planning: The team discusses and agrees on the scope of work that is intended to be done.
  • Daily Scrum: The team synchronizes activities and creates a plan for the next 24 hours during a 15-minute time-boxed event.
  • Sprint Review: Held at the end of the Sprint to review the work that was completed and the planned work that was not completed.
  • Sprint Retrospective: The opportunity for the team to inspect itself and create a plan for improvements.

A sprint typically takes less than a month and is repeated over and over again, each time resulting in a new incremental release. It’s not uncommon for a shippable product to be created only after the second or the third Sprint.  

Scrum defines three key roles that are needed for the framework to work:

  • Product owner: Responsible for defining the features that are needed in the product. 
  • Scrum master: Responsible for protecting the team and the process, running the meetings, and keeping things going.
  • Team: Includes the developers, testers, writers, and anyone else involved in the product development. 


Scrum produces three Artifacts, or documents:

  • Product backlog: Where product owners create a prioritized list of features, known as user stories. The product backlog evolves and changes priorities with each Sprint. 
  • Sprint backlog: The highest priority user stories go into the sprint backlog and are committed to for the next sprint. 
  • Burndown chart: Shows the progress during a sprint on a completion of tasks in the Sprint backlog.


Waterfall Versus Scrum
  
With the Waterfall approach, the software development process is seen as one monolithic project, and the development team releases working software to an operations team at the end of the project. On the other hand, Scrum would approach the development of the same project as a series of very small projects called, Sprints. The development team would release working software periodically until the entire software product is complete.

Water-Scrum-Fall

The Water-Scrum-Fall approach originated from the desire of many organizations to adopt Agile software development methodologies combined with the fact that Agile adoption has been led by Agile practitioners, who naturally focus on domains they can influence: the Scrum team itself. Those domains that fall outside their control, project planning and release management, still follow the traditional Waterfall approach. 

According to Margaret Rouse, Water-Scrum-Fall is "A flexible approach that embraces both traditional and Agile development principles and allows development teams to use whatever practices and techniques best meet the needs of the problem being solved."

As such, software development is often divided into three distinct phases: a period of detailed design and planning, the development using the Scrum approach, and a strict and managed product delivery. Just like the Waterfall approach, the Water-Scrum-Fall approach is ruled by fixed contract terms and lengthy deployment times.
According to Dave West, one vice president of development said, "We have to spend time upfront with the business building the requirements and plans to ensure that we know what they want, and they know how long it is going to take and how much it is going to cost. The problems start when the business does not know what they want, or the architecture is new to us."

West advises that application development and delivery professionals should realize that spending too much time upfront will not increase the quality of the release. Documents should introduce the problem area and allow high-level planning to commence as quickly as possible, while rapid feedback from the customer thanks to frequent software releases and better integration of the release process into the development team ensure early availability of usable software. 

"Apart from describing Water-Scrum-Fall as a kick-off stepping stone to agility, I am struggling to find any real benefit," states Hiles. For this and other reasons, the Water-Scrum-Fall approach is often described as an anti-pattern. "This anti-pattern has been widely implemented across the public sector, but it can also be found in commercial organizations, particularly those at enterprise scale. Various Agile scaling frameworks (e.g., Agility Path) have been developed in an attempt to provide a remedy," concludes agilepatterns.org.

Conclusion

The Water-Scrum-Fall approach often results from a botched Agile transformation and creates an environment with many pitfalls of the Waterfall approach but with limited benefits of the Scrum approach. Several remedies for the Water-Scrum-Fall anti-pattern have been developed, including Agility Path and other scaling frameworks.

Sources







Saturday, October 14, 2017

SOLID - 5. The Dependency Inversion Principle

All good things must come to an end, and so must this blog post series on the five SOLID design principles. But, before we dive into the topic and discuss the last remaining principle, remember that the five are a team that belongs together.

You will find it difficult to violate only one of the five without violating another one aswell. It just might not be obvious to you at the time.



You can read up on my other articles on SOLID here:


The Dependency Inversion Principle


The Dependency Inversion Principle says that:

  • High level modules should not rely on low level modules. Both should depend on abstractions
  • Abstractions should not depend on details. Details must depend on abstractions.

Reversing dependency causes a client to not be fragile to changes related to implementation details. That is, changing the detail does not break the client. In addition, the same client can be reused with another implementation detail.

Let's make this clearer with examples. 

Look at the classic example of the button and the lamp, where both the Button and Lamp classes are concrete classes:

public class Button
{
    private Lamp _lamp;
    public void TurnOn()
    {
        if (condition)
            _lamp.Light();
    }
}

The above design violates the DIP since Button depends on a concrete class Lamp. That is, Button knows implementation details instead of identifying an abstraction for the design.
What abstraction would that be? Button must be able to handle some action and turn on or off some device, whatever it is: a lamp, an engine, an alarm, etc.

Inverting Dependence

The solution below reverses the button dependency for the lamp, making both now depend on the abstraction Device:

public class Button
{
    private IDevice _device;
    public void TurnOn()
    {
        if (condition)
            _device.TurnOn();
    }
}

public interface IDevice
{
    void TurnOn();
    void TurnOff();
}

public class Lamp : IDevice
{
    public void TurnOn()
    {
    }
    public void TurnOff()
    {
    }
}

Dependency Inversion Principle and software architecture

The Dependency Inversion Principle is one of the pillars for good software architecture, problem-solving focused, and flexible implementation details such as databases, web services, file read / write, and so on.

This principle reinforces that abstraction is more related to its client than to the server (the abstraction class). In the example shown above, Device (the abstraction) is directly connected to the client (Button). Its implementation (Lamp) is a mere detail.
Thus, Device would be in the same package (or component) of the Button and not together with its Lamp implementation.

Another very common example of this pattern is the use of the Repository pattern. In this case, we apply the Dependency Inversion Principle so that our domain depends on an abstraction of the Repository, being totally isolated of details about persistence.

Taking the interface to the client, we are saying "the client works this way" and who implements the interface (in another component) must meet this requirement. That is, the interface will only change by necessity of the client.

Finally, when there are multiple clients in separate components for the same interface, it stays in a separate component. Going back to Button's example, when you put Device in a component itself (neither with the client nor with the server), it could be used by Button and any other object capable of turning on / off a device.

Conclusion

The Principle of Dependency Inversion is an essential principle for good object-oriented design, while the opposite leads to a cast and procedural design. Identifying abstractions and reversing dependencies ensures that the software is more flexible and robust, being better prepared for change.

So with this we close the series on the SOLID principles, which together form a set of good practices that we should have in our utility belt and that we should apply whenever we can to improve the quality of software design and architecture.