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