The Agile Pocket Guide

Begin slowly, and then inspect, adapt, and improve over time.

beyond the call of duty

One of the worst ways to measure whether something can be classified as working software is by meeting documented specifications. This may sound contrary to popular belief, but often the specifications have fatal flaws in them and the product may not exactly do what is necessary for greatest value to the business. Revenue is another way by which many companies measure whether the software is working; however, as I've found in the past, market fluctuations affect revenue so often that it is hard to create a real baseline.

The bottom line is that the software should meet the identified business or mission capabilities needed and defined by the business (i.e., product features that the business prioritizes as highest value). (See Figure 22.1.) The identification of the technical and operational requirements needs to be identified next, along with a plan built to schedule the delivery of the product through iterations. The done aspect of this is that at the end of each sprint, the customer can see how the features built can be tied directly to the mission-critical features of the product or strategy.

Technical debt is anything that should have been done as part of a development process but wasn't. This includes test cases, bugs that were not resolved, unrefactored code, missing documentation, and even process debt (gaps). This debt is like any other debt—you keep paying on it. By incurring this debt, the team and systems are mortgaging your future in the following ways:
Technical debt slows down our velocity.
Technical debt causes more issues in the long run due to “work-arounds.”
Technical debt breaks processes and creates instability in releases.
Technical debt causes uncertainty.

The business translates this to mean: “It looks like we won't get as many features as we want.” That is okay. The education for everyone on the team and the business is the fact that it is exponentially more expensive to fix bugs after a product launch.

The biggest caveat is that Kanban must not be used by itself. A system like Kanban has to accompany other best practices to augment the agility that Kanban affords. Since Kanban is very agile and efficient in its responsiveness to the changes in customer needs, other processes must be in place to give framework to some organizational needs that Kanban cannot provide solutions for.

The main difference between Kanban and Scrum is that Scrum development moves to the rhythm of Timeboxed increments, usually two to four weeks, and are bookended by meetings and a sprint review. Kanban, on the other hand, does not have Timeboxed increments or any task estimates. Scrum tracks velocity, while Kanban tracks the flow of items moving through the work in process (WIP) and the total cycle time for an item to move through the development cycle to deployment. (See Figure 24.1.) In Scrum, a master owns the process; in Kanban, the team owns the process. The people who are proponents of Scrum are looking for a consistent cadence in the sprints, and those using Kanban look at the flow of minimal marketable features. In a sense, the flow of work in Kanban is that the team simply takes the next task and works on it through the process. If there is a particularly limiting factor in Kanban, it is simply the amount of WIP a team can handle at any given time (e.g., four tasks total at any time).

As I have seen time and time again, the ones who place their team, their fellow employees, and others before themselves are the ones who reap more rewarding personal and professional gain. They don't do it for personal gain, but rather, the personal gain is a perk that comes with serving others.
I believe that personal character isn't taught, but rather it is grown over time. The more time you spend on personal kaizen, or self-improvement to help others, the more fulfilling and rewarding your work and life will be. The following is what I consider to be the Top 10 Personal Skills for a Servant Leader. I suggest you read each one and let it resonate within you.

Having thoughtful deliberation about what your team and company are practicing is at the essence of Agile. Instead of just “doing” or “practicing,” thoughtfully deliberate about what you're practicing. Don't forget to take opportunities to learn and relearn. Here is a list of things to start doing to improve your team and company: