Tag Archives: agile

On The Illusion of Controlling People’s Time

Software Engineering is going through an identity crisis. The old school has failed because of too much control, moving people away from what they really have to deliver. The new school, or agile fever, is more focused on humanities, directing all the attention to human beings. This approach practically decimated the old school, showing that writing software is not an exact science. It is actually unpredictable and cannot be done without creativity, inspiration and transpiration. Maybe the old school, which insists to exist, got confused by the fact that software execution, data processing, and system and hardware design are engineering stuff, but it doesn’t mean that developing those stuff is also engineering. On the contrary… it’s human and social.

When I see managers trying to measure the time spent on people’s daily activities, I understand they are taking into consideration only the transpiration of their teams and completely ignoring the creativity and inspiration. These two last aspects are so subjective that it’s hard to compare their manifestation on different people. How to compare artists? We may find artists’ comparisons out there, but they heavily rely on who is producing the comparison. Let’s ask ourselves: why on earth would someone use quantitative criteria, such as time and money, to measure and compare subjective matters?

Measurements are only useful when we’re capable of making comparisons with them in an objective way. We compare the date of our birth with the calendar to know our age. In times of crisis, we pay attention to our water, gaz and electricity consumption and make comparisons, finding ways to save money. Climate is measured because we need to decide which clothes to wear or which precautions to take by comparing with previous experiences or common sense. Notice we put measured subjects into perspective to understand the real dimension, the scale, the direction, and then we’re able to reason about trends, behaviours, issues, patterns, etc.

When it comes to subjective matters, we might be able to make comparisons, but measurements are just useless in this case. Actually, we can come closer with a lot of statistical methods, multi-variable analysis, multi-criteria craziness, but do we really have time and resources to produce all these analyses in a daily basis, and even take the risk of being probabilistically far from what it’s expected? It sounds complicated, isn’t it? That’s because it is. 🙂

In software development, every activity is different from one another. It’s impracticable to precisely compare two activities even if they look the same and are done by the same person. It’s all subjective, otherwise it would be easy to put the project on schedule by adding more people in the team. We know that since 1975, when Frederick Brooks published “The Mythical Man-Month“. So, when a manager asks their developers to inform the time spent in every activity, he/she is in fact collecting lies (or non-truths). If he/she prepares a report with those collected times, this is going to be the spread of an even bigger lie (or useless information).

But why lies? There are two good explanations for that:

  1. most people don’t track exactly how much time they spent on their activities, thus they actually inform safer figures, which are usually higher than reality;
  2. time control gives a feeling of surveillance, making developers believe their manager wants to know whether they are really working or not, thus they smartly add some extra time to mask non-productive time.

Managers should also be aware that time control also kills creativity. When developers have new ideas, potentially useful for the project, they cannot simply turn them into activities because of scope constraints or just because those ideas are not clear enough to be described. Without activities, developers cannot report their time. Therefore, if they spend too much time working on their ideas, it will look like huge time gaps for their managers.

Eventually, managers are moved to implement time control because of visible procrastination. I remember once when a new project was starting, a big room was allocated to a team of 12 people, and the project manager asked the team to choose their places in the room. There were 15 places available, 12 with monitors facing the wall and 3 with monitors facing the door. Guess which places were left available? That’s right! The three ones facing the door 😀 I remember the symphony of mouse clicks and sudden movements when the manager walked through the room. That was so funny! 😀 But time control wouldn’t solve that problem because inputing time on activities is also a distraction. Anything that is not building deliverables is a distraction. We may never eliminate them, but we can always reduce them. The solution for procrastination, in a single word, is: Motivation!

But, is time control totally out of sense? It has some sense when the work is fully based on time, which is the case of consultants payed hourly. This is about their business model, not software engineering. That’s a good practice for consultants to inform to customers how many hours they had spent because it’s directly related to their payments. Notice that this kind of service is for a short period of time and for highly specialised skills. However, we are talking about software projects that last longer.

Finding ways to motivate your team is the best strategy to put them on track and fully productive. Every form of control that threats their feelings will put them down. Motivation doesn’t need to be monetary or entertaining. Sometimes, it’s enough to show their wins, how important is their work for society, how it changed people’s lives, and why it’s important to keep doing what they’re doing.

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more. For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from on task to another, it changes the mode in which you work. – Paul Graham

Architects Need a Pragmatic Software Development Process

I have been a non-stop software architect since 2006. During my experience, I realized that it’s really hard to perform the role of architect in an organization that doesn’t have a software development process or have it too simplified. When the development is not fairly organized, project managers don’t find a room in their schedule to implement architectural recommendations. They probably have time, people and resources, but since they don’t have a precise idea of the team’s productivity, they feel afraid of accepting new non-functional requirements or changing existing ones. I’ve noticed that, in a chaotic environment, people become excessively pragmatic, averse to changes.

Architects expect that the organization adopts a more predictable and transparent software process. This way, it’s possible to visualize the impact of recommendations and negotiate when they are going to be implemented. They minimally expect a process that has iterations inspired on the classical PDCA (Plan, Do, Check and Act) cycle because it has loops with feedback, which are the foundation for continuous improvement.

The figure below depicts what could be considered as a pragmatic software process.

Iterations are overlapped in time in order to optimize people allocation, use of resources and guarantee the feedback from previous iterations. Each iteration is performed in a fixed period of time. This time depends on the context and it tends to fall as the organization gains more maturity. An iteration is composed of 4 phases (plan, do, check and act) and 5 events that may occur according to the planning. They are:

  • T1: It represents the beginning of the iteration, starting with its planning. The scope of the planning covers only the period of the current iteration. It should not be mixed with the general project planning, which is produced in one of the initial iterations to plan all other iterations. All members of the team participate in the planning.
  • T2: The execution of what was planned for the iteration starts. All members of the team must have something to do within the scope of the iteration. Nothing planned for future iterations should be done in the current iteration. People may produce all sort of output, such as documents, code, reports, meeting minutes, etc.
  • T3: Everything that is produced should be checked. Documents should be reviewed, code should be tested, user interfaces and integrations with other systems should be tested, etc. All found issues must be registered to be solved in due time.
  • T4: Solve all issues found during the check phase and release all planned deliverables. Everybody should deliver something. In case time is not enough to solve some found issues, they must be included in the planning of the next iteration with the highest priority. Statistics should be produced during this phase in order to compare the planning with the execution. The planning of the next iteration also starts at this point, taking advantage of the experience from the previous iteration.
  • T5: Once everything is released, the current iteration finishes. T2 of the next iteration immediately starts because most of people and resources are already available.

T1 to T5 repeats several times, in a fixed period of time, until the end of the project. This suggestion is process-agnostic, thus it can be implemented no matter what software process we claim to have in place or any other modern process we can think of.

In addition to the process, there are also some good practices:

  1. Consider everything that describes how the system implements business needs as use cases. It can also be functional and nonfunctional requirements, user stories, scenarios, etc; but there must be only one sort of artefact to describe business needs.
  2. Write use cases in a way that the text can be reused to: a) help business people to visualize how their needs will work; b) guide testers on the exploratory tests; and c) help the support team to prepare the user manual.
  3. Avoid technical terms in use cases. If really needed, technical details may be documented in another artefact, such as use case realizations.
  4. If needed, create use case realizations using UML models only. Representing use case realisations as documents implies on a huge overhead. Any necessary textual information can be added in the comments area of UML’s elements.
  5. Fix the size of use cases according to the effort to realize it. For example: we can fix that the maximum size of a use case is 1 week. If the estimation is higher than that, then the use case must be divided in two others. If the estimation is far lower than that, then the use case must be merged with another closely related use case. By simply counting the number of use cases we immediately know the effort and the resources required to execute the project. This fixed number is a parameter to compare the planning with the execution. By performing this comparison after every iteration, we gradually know how precise our estimations are becoming.
  6. Use a wiki to document use cases and other required documentations, such as test cases, release notes, etc. Create a wiki page for each use case and use signs to indicate what is still pending to be released. The advantages of the wiki are: a) use cases are immediately available for all stakeholders as they are gathered; b) stakeholders can follow the evolution of the use cases by following updates in the page; c) it’s possible to know everyone who contributed to the use case and what exactly they did; and d) it’s possible to add comments to use cases, preserving all the discussion around it.
  7. If the organization has business processes, which is another thing that architects also love, then put references in the business process’ activities pointing to the use cases that implement them. A reference is a link to the page where the use case is published on the wiki.
  8. Follow up use cases using an issue tracking system, such as Jira. Each use case must have a corresponding Jira ticket and every detail of the use case’s planning, execution, checking and delivery must be registered in that ticket. The advantages of linking Jira tickets with use cases are: a) Jira tickets represent the execution of the planning and their figures can be compared with the planning, generating statistics on which managers can rely on; b) we know exactly every person who contributed to the use case, what they did, and for how long; and c) it’s an important source of lessons learned.
  9. Test, test, test! It must be an obsessive compulsive behaviour. Nothing goes out without passing through the extensive test session.
  10. Constantly train and provide all needed bibliography to the team on the technologies in use. The more technical knowledge we have inside of the team, the highest is our capability to solve problems and increase productivity.

Working this way, everything becomes quantifiable, predictable, comparable and traceable.

From the practices above we can extract the traceability flow from business to the lowest IT level, as depicted in the figure below.

Business process elements such as swimlanes and activities may inspire actors and use cases. Use cases and actors are documented on wiki pages. Each use case and actor has a page on the wiki, which has a unique URL and can be used to refer the element on email messages, documents, Jira tickets and so on. An Jira ticket is created for each use case and it contains a link to the use case’s wiki page. This wiki page can also have a link to the ticket since it also has a unique URL. Jira tickets can be automatically linked the source code through the version control system (SVN) and declaratively linked to system’s features and user interfaces. Since it’s possible to create mock-ups in wiki pages, then we also link those wiki pages with user interfaces to compare the mock-ups with the final user interface. We finally have actors linked to security roles.

I admit that architects are not qualified to define and implement a software development process in the organization (they actually believe more in the Programming Motherfucker philosophy :D), but they are constantly willing to contribute to have one in place. As they have instruments to monitor servers, releases, tests, performance and so on, they also want project managers having instruments to estimate effort, predict events, anticipate problems and, therefore, produce better planning and results. Warning: Whatever we put in our software processes that is not quantifiable or measurable will become an expensive overhead.

Integrating Jira with Netbeans

One of the advantages of hosting your open source project at Java.net is the availability of Jira to track your issues. Jira is one of the most popular issue tracking system available on the market, which drives tool developers to support it. This is the case of Netbeans, my working IDE, and also the case of Eclipse.

I recently configured my Netbeans to access Jug Manangement‘s issues. If you want to do the same, or with another project hosted on Java.net or even connect to the Jira available on your company’s Intranet, then the following instructions may help you.

The first step is to install Jira plugin on Netbeans. In the menu, select Tools and then Plugins. Go to the tab Available Plugins and select JIRA. Follow the installation procedure and restart the IDE at the end. The figure below shows the plugin already installed. You may check as well if JIRA is in your list of Installed plugins to make sure everything went well.

In the view Services, where we connect to databases, webservers and others, we also find a new kind of service called Issue Trackers. By clicking with the right button on this service, you are about to create a connection to a issue tracker. A dialog like the following figure appears. Give any name to your connection, since this is not a predefined value. In case of Java.net, use the URL https://java.net/jira and the credentials you use to authenticate in the portal. Click on Validate to make sure that you input the values correctly and the connection with the server is working. Click on Ok to finish.

Now, you are connected but not ready to work yet. The next step is to find the issues. For that, click with the right button on the issue tracker that you just created and select the option Find Issues. It opens a new tab in the editor area where you are able to build your query as you usually do using Jira on a web browser. When you build the best query for your needs you can save it to constantly work with that. In the following figure I built a query that shows me all open issues of the project jug-management.

You can do something similar to your project and control your issues directly from the IDE. One of the main benefits of this approach is that, by restricting the use of the browser, we reduce the probability of losing the focus on the work due to other entertainment activities on the web such as news, social networks, chatting and so on.