Lean-thinking and two product views with software development

Coined from a Toyota production system for the adaptability, flexibility, and free of waste, lean-thinking has two pillars: 1. Just-in-time, 2. mistake-proofing. At the heart, lean thinking is the elimination of waste – rework, overproduction, conveyance, waiting, inventory, etc. [1]

To achieve these, In general, lean-thinking relies on user collaboration (sensitive to needs), skilled people working together (team work), producing quantities in small batches (iterative development), and simple processes (adaptability). [1]

Can lean-thinking be used for software development and how? Software development seems perfect for lean-thinking comparing to other productions, such as building a bridge, which can neither be iterative nor be adaptable. For software development, all above requirements are desirable.

What software development is different from other production is refactoring – adjustment to the implementation so far. As new feature development progressing, the code base is not simply adding in new code, the old code are usually subject to change, which sometime could be fundamental like architecture adjustments. Refactoring should happen once in a while before following iteration of development can start.

To let refactoring to have a direction, the product has to demonstrate with a design or an architecture, or a set of construction guidelines (the product solution view). No matter what they are, the team must have a clear vision and an agreement. This more technical view of the product, comparing to the business or user view of the product (the product business view) that the product owner (PO) is responsible to communicate, is created by and communicated among the developers. And, as such, a development lead is a critical role to help building the agreements and the communication, as well as planning for development and refactoring tasks.

While looking at the production team and process, the essence of lean-thinking is a pulling model – demand-driven production, being just-in-time and just-in-size.

To avoid mistake and to eliminate waste, the product requirements in the first place must be justified. This comes to the PO and the product business view. User stories, business rules and data, and UI design are among the core elements of this view.

Once both product solution view and product business view are properly addressed and communicated in a continuous basis, the detail level execution of a project, including requirements breaking down for iterations and product delivery schedules, can be planned accordingly and in a more precise manner. From project perspective, both the work schedule (time) and the quality of the product can be better planned and controlled.

I have created a tool, MineralR, meant to help PO and developers manage those two views. If you are interested in a discussion, I can be reached at shi.luan@hotmail.com.

Reference:
1. The Business Value of Agile Software Method, by David F. Rico et al.

JIRA for Agile Management Primer (1)

JIRA is a long time bug/issue tracking tool. Since it defines project concept as a set of issues that go through a life cycle of a list of states to finish, and conceptually a project really is a hierarchy of working tasks(issues), it becomes a project management tool as well. A project can be any thing, so JIRA can have very broad usage.

Actually, JIRA has been adopted by many projects, eg., jBoss, Hibernate, Zend Framework, Skype, and Apache.

Architecturally, JIRA offers integration in different ways to make itself live in a ecosystem. It supports RPC(Remote Process Call) protocols such as SOAP, XML-RPC, and REST. It integrates with IDEs such as Eclipse by using Atlassion IDE. It also integrates with source controls, such as Subversion, CVS, VSS, Git, and others. Typically, GreenHopper, a JIRA plug-in, extends JIRA for agile project management by offering framework for planning and organisation tasks, workflows and reporting, making JIRA a powerful agile development platform.

JIRA has some key concepts that help understand the model quickly.

Issue
An issue can represent many things like a software bug, a development task, a helpdesk ticket. Anything that needs to be assigned and acted on is an issue, and JIRA tracks them. At this end, an issue is abstraction of all sorts of these things. It seems that in JIRA, issues are flat, not hierarchical, but in practical cases, we often see decomposing tasks and manage them in different granularities.

Project
A project represents a collection of issues. As mentioned above, issues are hierarchical in nature, JIRA brought in Component concept that represents a logical grouping of issues within a project. This seems that JIRA uses 3-levels to manage issues, instead of treating issues being decomposed into arbitrary levels of depth, making the model easier. An issue can associate directly to a project, or associate to one or more components.

Version
Optionally, JIRA allows specifying project version to an issue. There are two types of versions: Affected Version and Fix Version, meaning the project version that the issue has been identified and the project version the issue is or will be fixed respectively.

Workflow
It represents the lifecycle that an issue walks through. It also reflects how JIRA tracks and manages issues. Following diagram (Figure 1) shows the states machine of a JIRA issue.

Figure 1: an issue walks through these transitions and states to finish
(source: http://confluence.atlassian.com/display/JIRA/What+is+Workflow)

Control Iterations with Scope

To a project manager (PM), delivering a project on time is one of the three top concerns other than budget and user-expectation. In traditional waterfall model, each development stage is defined with a time span attribute in the project schedule. But in modern Agile model, the whole development is broken down into iterations, each of which comprises of a set of work efforts on user stories (as defined in XP). To achieve the “on time” target in this paradigm, PM needs to constantly monitor the user stories backlog to ensure all of them are inline with the project scope, because scope creep is one the primary reason for project delay.

The whole idea of Agile preferred over waterfall is that it “embraces changes”, as it works in iterations and in incremental evolution, in stead of in holistic. But I hope this doesn’t give developers and business users alike a misleading sense that creating requirements can be less serious, with an attitude “if they are not right, we can change in later iterations,” which technically seems right and inline with the idea of “iteration”, but given a project context having time and schedule defined, is wrong. Any divergence from the scope causes extra work effort and time, impacting “on time” delivery of the project.

Moreover, user stories should evolve towards the right direction. That “Requirements constantly change” means the user stories in the backlog are evolving too. And creating new user stories should be a serious work that makes sure they evolve to the right direction, meaning even a user story is in the scope, it still could be evolving to a direction rather than getting closer to its final state. We see a lot of back-and-forth with requirements, and they do cause waste of time and resource, and pull back the project.

So, a PM should constantly check new user stories to ensure they are in scope, and evolving to the right direction.

Still, is these enough for PM to control time in an Agile paradigm? Not really. If he doesn’t define and control the number of iterations for the project, how can he ensure the project’s time span? I will investigate this in next article.