Being Agile is not easy

No wonder that many companies and people say they are Agile, but when asked if they are programming in pairs, if they are test oriented or if they work 40 hours weekly, most times the answer is "not necessarily" or "more or less" or even "no, but we develop in sprints".

Being Agile is not easy.

At least we, the Agilistas, are aware that simply not being Agile is even more difficult.

Even with the adaptable agile methodologies, as Kanban for example, be Agile means a change in behavior, paradigms and to many people, a change of principles and personality (if that is possible). A major difficulty, at least in my personal experience, is having to develop together with someone who claims to be agile because it's fashionable, but not even believes in agile values and uses any argument and excuses to justify why not doing pair programming, not refactoring, not sharing the code, not developing unit tests and, especially, not focusing on delivering something executable at the end of an iteration. Even harder than being agile is explaining to a person who thinks is being agile that he or she is not.
  (I want to quote here this other post that I found interesting: The emotional reaction to Agile adoption)

Even for someone who is actually Agile, it is extremely common skip some agile practices for indiscipline and laziness. I will not deny that it has happened to me countless times. When you are too absorbed and pressed with momentary and isolated problems, it is usual to lose perception of the global consequences of indiscipline. The problem increases considerably when the quality of work is not visible by others in the team or if you are not pair programming and there is nobody to inspect your work besides yourself.

In many cases, a tool that "forces" and "guarantees" the performance of the agile practices can greatly help a development team. I fully understand that human interaction is the most relevant factor to agile adoption, and that nothing can replace it. But I also believe that not all people have the agile values in nature, that even the agile pros can often be undisciplined and that simple reliance on individual effort is not always a success factor. An additional tool to aid human interactions (such as communication, sharing, respect, trust, ...) when an agile development team is being incipient can be a very efficient solution.



 The advantages of the LiveSource Toolkit

Watch our DEMO video: http://www.screencast-o-matic.com/watch/cX6oVdTPZ

LiveSource is a Web tool that ensures the source code will no longer be hidden behind a complex file server access, but it will always be shared by the whole development team at a click away on your web browser. And further, this code will also be understood by non-programmers. At least, if the code is not understandable, the LiveSource Toolkit will let the problem be exposed in a way that programmers will not be able to argue with their technical jargon, so incomprehensible otherwise. It is a new technology for your software, clarifying the darkness of programming into an easy to read, step by step summary of the content.

LiveSource creates a medium that helps both stakeholders and programmers to work together on code in a high-level manner, to better improve the pair programming between programmers and even non-programmers.

Figure 1. A screen shot from the LiveSource Toolkit that displays the source code and an easy to ready filter of this source code.

Excerpted from a Tic Tac Toe game software project.

(Click on image to see enlargement)

The Figure 1 above is a screen shot from the LiveSource Toolkit. Notice that all data on the left frame was extracted from the source code displayed on the right. The left frame is just a filter of domain information relevant to a stakeholder.

Once a development team starts to apply the  Ubiquitous Language within the source code, a new series of applicability for this source begin to emerge. LiveSource focuses on extracting the source code all the benefits generated by the use of ubiquitous language.


LiveSource publishes in a document’s format the true reality of a software project. What is not already implemented in the source code will be shown clearly, without having to go through parallel documentation or reporting tools like emails, bug tracking, task sheets, etc., where this reality can be easily masked by those responsible.

LiveSource also integrates user stories and tasking more tightly with codebase. If programmers insert domain information in the source code and also use ubiquitous language, turning this source code on a User Story or a Requirement is just a matter of extracting, filtering and formatting text from the code. Then, the team can automatically have a series of requirements listed as a scope view of the software.

Observe a Requirements list below extracted from the source code of a Tic Tac Toe sample project:

Figure 2. Scope View through the Requirements List (Click on image to see enlargement)

Figure 3. Source files view. (Click on image to see enlargement)

As the requirements listed above on the left is a direct view (and filtered) from the source code files listed on the right, there's no way a programmer or a project manager, or anyone else in the development team, can manipulate this data to show greater productivity than what really has taken place.

Compare Figure 2 with Figure 3, see how easier it is to read and understand the structure and meaning of the source code after the LiveSource filters.




Unit Testing

LiveSource also shows accurately the presence or absence of unit tests for a given unit of code.

Figure 4. Link between a source file and its unit testing.

(Click on image to see enlargement)

Live Task Board 

Because we are able to extract user stories straight from the source code with the use of ubiquitous language, we could create a tool that calls Live Task Board.

The Live Task Board is a dynamic and realistic view of the current status of the software. It can automatically update itself, because its content is extracted directly from the source code and not from a database of stories that have to be updated in parallel or stories written in paper on the wall that need to be physically moved by the team members daily.

If the developers stratify the software planning activities in simple as possible tasks, very minimal in its size, as minimal as a single development class, the complexity of the user stories becomes more understandable and accurately estimated.

Figure 5. The Live Task Board

(Click on image to see enlargement)

It is fully understandable the wonderful effects of a simply task board on the wall in front of the development team, especially during a Scrum Stand Up Meeting. This means an evolution compared to traditional development models, with their extremely complex and unrealistic timelines. The idea of LiveSource is not to replace the interaction moments between the team, bringing one more tool to be used by developers, but to further enhance communication, leaving the manual task of updating the artifacts to be performed by a computer. It provids much more time for the team to discuss issues related to the tasks themselves.

The team can project the Live Task Board on the wall and continue adding post-its to the projected screen. At the time a programmer is generating the source code for a specific task, the information from the post-its can be used as code documentation and thus the related task automatically returns to the Live Task Board, all electronically and much more permanent.

Viewing the source code in a filtered and clean manner, gives the programmer an immediate idea of what needs to be improved. It causes them extreme discomfort to view their work so clearly when is not done well. It is a situation that only real experience with LiveSource can demonstrate its full extent.

Now imagine the impact of a confusing code being viewed by everyone on the team. No programmer will like to be responsible for this code. And possibly will not be, since the tendency of the programmer will be to prioritize refactoring, reducing the complexity of the source code considerably.

That is why LiveSource can be considered a tool to increase software quality. Because it allows great visibility to what is actually being developed.

The idea is, with LiveSource you can not disguise when you're not being agile. Not even to yourself.

Then, don't forget to send us your comments!

LiveSource - an Agile Toolkit

View more presentations from Alline Watkins

 No Rigths Reserved. Please copy us!

Why some programmers don't like transparency

Ineffective communication is clearly the weak point of several software development projects. The causes can be diverse and the consequences catastrophic. Looking more deeply to these causes, we identified two major ramifications of the problem:
       - the interaction between the product owners and the end users and
       - the interaction between stakeholders and developers.

Communication between the owner who is paying for the development of the software and the users who actually use it has been widely studied by the Lean Development, with practical and extremely effective results for those who are actually willing to minimize the problem (Product-Market Fit, Minimum Viable Product, Lean Code, ...). No magic solution yet found, but it is understood that the work must be in conjunction with the direct participation, unrestricted and as early as possible by the end users in the software development process. Learn more about Lean Development here, or about Lean Startups here.

The other branch of the problem of communication in building software is the gap created between project developers and the stakeholders (project managers, company directors, business experts, ...). Let's bring the conversation from the lofty abstraction that is the usual context for such conversations, down to the brass tacks available to us through closer involvement with actual code.

Experience on both sides of the communication divide (as stakeholders and as developers), has led us to believe that a deeper understanding of the psychology behind such interactions contains a solution. 

Is not hard to see the huge conflict of interest that most development companies just generate within their own environment. When interests are in conflict, information came to mean a source of power, directly affecting the transparency and effectiveness of communications.
How many programmers have not heard from their managers the annoying phrase: "Why do you want to know that?"?
How many stakeholders have already faced totally fuzzy development diagrams, beginning with the "Gang of Four" and ending with no terms that can be understood?

Like it or not, developers are motivated to keep their code hidden from those they are accountable to. Their specialized technical knowledge provides a layer of protection from attack for bad technical decisions and sloppy work.

Even if a programmer is producing excellent code, but also works in an environment strictly hierarchical, unlike an Agile team, this developer is probably at the bottom of the blame chain and will still have the tendency to hide artifacts, because it is the only way to be protected in turbulent situations. A typical defense mechanism used by programmers is to use language and jargon that are deliberately obtuse to the stakeholders.

Stakeholders are typically specialized in a field other than software engineering. Code is black magic to them and they are required to invest blind faith in the technical team to build them a quality product. They can’t speak programmer language, but need deeper insight into the technical cost of what they are requesting. 

We know that transparency is key to most of the eXtreme Programming values (citing courage, communication, feedback and respect). The Live Source Toolkit gives stakeholders or any non-technical person a non-intimidating window into code and a concrete medium for communicating with developers in familiar language. We are advocating that open dialog in front of the reality of the source code brings a confidence that can't be provided anywhere else. It will be the stakeholder's responsibility to supply feedback with respect and the programmer's responsibility to maintain the courage and clarity of communication.

In summary, we are building a tool to go beyond social interaction without replacing it. We are building a medium to enable a conversation with transparency, not only a case tool.

June & Alline

 No Rights Reserved. Please copy us!

User language inside the source code - The Ubiquitous Language

"We understand each other"  (James Shore)

http://jamesshore.com/Agile-Book/ubiquitous_language.html

• Does your source code lack knowledge?
• If one of the developers on your team left work now, would others be able to make sense of it?
• Is it a multiple lined mess, impossible to understand even for the one who wrote it?

Software development is by its nature a series of translations and compromises. What the end user wants, what the customer is willing to pay for, and what is technically feasible rarely combine to form a unified set of features. A deeper understanding between technical and non-technical people is needed, in particular at the communication divide between Stakeholders and Developers.

The LiveSource Toolkit helps you to develop a domain-specific ubiquitous language inside your source code and shows you how to use your codebase as a source for your requirements and documentation, improving communication for the whole team.

"Programmers should speak the language of domain experts to avoid miscommunication, delays, and errors. To avoid mental translation between domain language and code, design your software to use the language of the domain. Reflect in code how users of the softwarethink and speak about their work. One powerful approach is to create a domain model. 

The ubiquitous language is a living language. Domain experts influence design and code and the issues discovered while coding influence domain experts. When you discover discrepancies, it's an opportunity for conversation and joint discovery. Then update your design to reflect the results."   (Ubiquitous Language in 99 words - James Shore)

End Users are Ubiquitous

Not every software project has a dedicated business analyst or a domain expert. But every software must have users. Also, every software should be written for the users.

In general, on a development team the technical language is understood only by developers, the domain language normally understood only by domain experts. But, to achieve success, the end user language should  be understood by everyone. The end user language should be the ubiquitous one.

User Language good in Code?


The whole idea behind an ubiquitous language is that it is pervasive everywhere; in all project related communication, all the way down to the technical level. The idea is to preserve the business intention in the code and have the code mirror the real world as much as possible.

Source code is a little more limited in that you have to avoid keywords on a programming-language-specific basis, but other than that, the advantages are numerous; the programmers don’t have to make the mental translation from the language of code to the language of the domain resulting in less bugs, the domain experts don’t have to read the “Gang of Four” and can more accurately describe their needs, and both programmers and domain experts should be able to understand the end user's language. Driving the design based on the domain in this manner shows how closing the gap between domain and programming language leads to better code.

Most Agilists agree that a shared (ubiquitous) language improves communication between technical and non-technical people. Ensuring a strong tie to the code reinforces the language and ensures it's thorough use.

A User Story BEFORE and AFTER Ubiquitous Language

When the ubiquitous language is already being applied in high-level documents of the project, makes it much easier for developers to identify which technical jargon should be avoided in the source code.
Notice how the two stories below may communicate the same message, even if the domain language is being directly applied to the second one.

(Excerpted from a Tic TacToe Game)

BEFORE    Move      When the user clicks on the grid,      the system shows 0 or X depending on which one is the current user.

AFTER    Player Move When the player clicks on the game grid, the game shows the symbol 0 ou X depending on which one is the current player.

A class BEFORE and AFTER Ubiquitous Language

You will probably notice that it becomes easier to understand the code when you use

domain language while programming. There is much less guessing on the programmer's

intent, eliminating a lot of confusion for the one that is going to maintain it.

(Excerpted from a Tic Tac Toe Game source code)

BEFORE      /**  * Add the string O or X to a cell in the grid. */ public class  ShowCellGrid{ public static void  displayUser (Grid grid, Cell cell) {             if (!Initialization.flag   && Initialization.gameStatus.getSequence() == null   && isEmpty(grid, cell)) {  Initialization.flag = true;  String mk= showString(Initialization.gameStatus        .getCurrentUser().getUserString());  grid.setHTML(cell.getRowIndex(), cell.getCellIndex(), mk);  Initialization.gameStatus.getStatus()[cell.getRowIndex()][cell .getCellIndex()] = Initialization.gameStatus .getCurrentUser(); GameEnd.checkEnd(Initialization.gameStatus, cell.getRowIndex(), cell.getCellIndex());        } (...) }

AFTER    /** * Performs a move in the game. */ public class  PlayerMove { /** * When the player clicks in a cell, the game draws an O or a X on the     *  game grid depending on which player's turn it is. */ public static void   makeMove  (GameGrid gameGrid, Cell cell) {         if (!GameInitialization.waitingMoveFlag && GameInitialization.currentGameStatus.getSequenceWinner()  == null && isCellEmpty(gameGrid, cell)) { GameInitialization.waitingMoveFlag = true; String marker = showPlayerIcon(GameInitialization. currentGameStatus.getCurrentPlayer().getPlayerIcon()); gameGrid.setHTML(cell.getRowIndex(), cell.getCellIndex(), marker); GameInitialization.currentGameStatus.getGameMoves() [cell.getRowIndex()][cell.getCellIndex()] =  GameInitialization.currentGameStatus.getCurrentPlayer(); CheckWinner.checkForWinner(GameInitialization. currentGameStatus,cell.getRowIndex(), cell.getCellIndex());         } (...) }

Now, which one below would a Stakeholder better understand?

The contents of both tables below were extracted from the classes above.
Small changes in this matter has a huge impact on the code's general knowledge.

What we demonstrate here is that, once developers begin to introduce Ubiquitous Language 

within their source code, a lot of possibilities like filtering and searching becomes possible 

and useful to others who do not necessarily understand the technical terms.

(Excerpted from a Tic Tac Toe Game source code)

BEFORE    Show Cell Grid    Add the String O or X to a cell in the grid. Display User        Is Empty

AFTER    Player Move    Performs a move in the game. Make Move        When the player clicks in a cell, the game draws an O or a X on the game grid depending on which player's turn it is. Is Cell Empty        The Player can select a cell only if it wasn't already selected yet.

Using Ubiquitous Language in source code may seem simple, but it's not. In fact it implies a big paradigm shift for programmers who are accustomed to use their technical terms back and forth, as examples "EntityBeans","AssyncronousCalls", "DTO's ", etc...

Replacing these terms (which often not even other programmers can easily understand) and using words that are more self-explanatory in a Stakeholder's perspective, demand time and a lot of refactoring by programmers. It will not be in a day for code to become ubiquitous. A gradual and continuous progress is to be expected.

And speaking of self-explanatory words, the ideal nomenclature to use in a code is one that, when you are explaining the software to someone, it doesn't require saying another word beyond the proper nomenclature itself. For example, a variable should be called "Connection" or "DatabaseConnection"? A function should be called "IsNull" or "IsEmailEmpty"?

 No Rights Reserved. Please copy us!