This is a guest blog about agile development by Makoto Sakai / SRA (Software Research Associates, Inc.) and akipii / XPJUG Kansai (eXtreme Programming Japan User Group at Kansai).
Ultimately we found that Ticket Driven Development can be widely applied, and not only in Japan. In this article, we will explain why Ticket Driven Development is of interest in Japan, and how it is used.
Characteristics of software development in Japan
In Japan, lots of teams in gaming and web application development have started to adopt agile practices. However, due to constraints imposed by management in these companies they really follow a Waterfall methodology – making their software development process more of a cascade than agile. This is due in large part to the culture in Japan which includes a contract based on trust. There are four areas where people are blocked in their agile adoption in Japan:
- Complex, large-scale software have been developed, which is sometimes called “System of system”
- The entrusted contracts are concluded after confirming the specifications so that multiple organizations can develop in a short period of time (of course, changes to the specification happen as well)
- Standardization of development that is based on the waterfall from the 1980s are in progress
- We emphasized data-centric using a DBMS, and it delayed spread of object-oriented
Ticket Driven Development
Ticket Driven Development is a method of managing tasks in the software development lifecycle using an issue tracking system like Jira. It is called Ticket Driven Development for the user story that represents the customer value an agile software development team will deliver. Of course, Ticket Driven Development doesn’t mean there are no bugs – bugs are also issues which the team members can use to associate source to backlog.
The basic rule is “No Issue, No Commit!”, and as such every commit will have a story or bug associated with it. Managing the source code of a project with an issue for every commit ensures:
1.Issues and source are integrated to ease source code management
- Get ease of maintenance by the ticket history and the association with configuration management
- By integrating the various tools, you can manage information at one place
2. Communication is focused on the issue
- Because it reduces unnecessary communication, you can concentrate on the work with a steady rhythm
- Make communication easier with shy team members
3. An electronic kanban board makes it distributed development teams reality
- Since it is possible to share information smoothly even in remote areas, you can respond flexibly to changes
- Since you can report in the aggregated perspective of teams or individuals, it makes project management or self-management easier
4. Automation of the process by workflow
- By the workflow, you can automate the review process, deployment, merging and more
- The ScrumMaster doesn’t have to follow up with individual team members
- The team never misses a step, like code review
Why is Ticket Driven Development attracting attention?
For the following reasons, the situation seems to be changing in Japan.
- Pressure from management for cost cutting exercises, they are no longer able to secure a sufficient budget that incorporates a buffer for changes to the specification
- Business needs are changing more frequently due to external pressures (trying to compete with companies outside Japan)
- It becomes difficult to handle statistically management information (software metrics) since software is diversified
- With increasing popularity of dynamic languages like Ruby, sequential development has become essential
As such, it has become necessary to adopt agile development practices in Japan. And these challenges are not unique to the Japanese market. Ticket Driven Development is attracting attention for the following reasons:
- Since working space is small, it is difficult to secure physical task boards to a wall and find meeting space – electronic tools rule
- Anxiety for large-scale development due to a lack of know-how – start small and learn as we progress
- Structural problem such as that the person with authority and the related team present in different locations – empower distributed teams
- Fear of losing the continuity of management information – have one source of knowledge
Usage scenarios of Ticket Driven Development
A few unique usages of Ticket Driven Development are as followings:
1) Agile development with being digitalized and automated
Ticket Driven Development is adopted as agile development which has less constraint and is more efficient.We also have a case study that they show the performance of agile development using test-driven development and use BTS or ITS for fault management, then migrate to analog task cards.
2) Adaptable waterfall development that can respond agilely to changes
Ticket Driven Development can be used for the purpose of streamlining communication and development work related to specification changes.By making process lightweight, you are able to respond promptly to changes.Supporting the multiple releases using the milestone of BTS or ITS, it makes process easier to adapt.
3) Distributed development in multiple locations
Work order tickets for use in distributed development sometimes called Ticket Driven Development as well.In this case, tickets are not always integrated with configuration management.
4) Application to business systems using the workflow and file associations
In addition to use in a DevOps where you manage issues by the tickets ranging from development to maintenance, the usage has spread to the IT general control and general operations.
Conclusion
The trend of Ticket Driven Development arose from circumstances unique to Japan. However, it is not particularly limited to Japan. It is available for use in software development or system development in general.I think when we organize effective usage with a number of case studies, “Ticket Driven Development” becomes more widely used.
Next
There are seven known practices around TiDD as follows:
- No ticket, no commit
- No ticket, no work
- Iteration is Version, or continuous delivery is practiced
- Tickets follow repositories in version control system
- Manage tasks with tickets by dividing them
- Inventory tickets
- Pair work
If you are interested in these practices and want to know the details, please leave a comment or directly contact the author @sakaba37 or @akipii.