Category: General Agile

In 2002, Jim Johnson of the Standish Group (made famous by their Chaos Report of software project “success”) presented findings of features and functions used in a typical system. The number of features that were never or rarely used totaled a whopping 64% while sometimes, often and always weighed in with 16%, 13% and 7% respectively. For those acquainted with the Pareto principle (80/20 rule), notice how the often and always used features – those things we should concentrate on building for our customers and those things things that bring us the most value – is exactly 80%.

In other words, a great deal of our effort is generally spent creating things that customers do not use or want.

A lot of times this is a forgotten principle as people get caught up in the world of implementing stories and forget that there may be a plethora of stories that don’t need to ever be implemented.

What value is there is doing work faster and better if we are doing four times the amount of work that we need to do?

This principle fits well with the concept of business and development working daily. Business needs to be intensely involved with the process, if for nothing more than identifying the 80% of the work that we really don’t have to do. Just think of the amount of money that could be saved every year by reducing project scope to only those features and functions that are actually used! Think of how quickly we could deliver functionality! Think of how many more “projects” we could complete!

While simplicity provides huge benefits with regards to the stories and work that we choose to implement, it also applies to the implementation of stories that we choose. As I have written about so many times, by using techniques like BDD and TDD we write only that software that is necessary to implement the acceptance criteria and are not tempted to “gold plate”.

TDD provides us with a certain simplicity at the code level while also providing us the ability to allow our code to evolve over time to satisfy changing requirements. Simplicity of code allows us to refactor code mercilessly which is essential to agility over the long term.

In the end, simplicity of what we do and how we do it results in producing the most valuable software in a high quality manner and this is essential to being agile.

– Larry Apke

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Metrics. Metrics. Metrics. We love numbers. We measure and put numbers to all kinds of things. We use these numbers to mark our projects as red, yellow and red (of course, the project is always green until there are a few weeks left when someone finally blinks and acknowledges reality and begins to use yellow or, god forbid, red).

Unfortunately, in our headlong rush to create metrics we tend to forget the why of what we are doing. Numbers and statuses become an end unto themselves.

There are a myriad of problems with this. First, what get measured gets done. In our rush to get numbers we need to be very careful because measuring the wrong things will lead to all kinds of behaviors that can be detrimental to long term sustainability. For example, one company I worked for misunderstood the team velocity metric and rewarded teams based on the number of points completed. What happened? Over time the point values for stories increased so that teams would look better but the amount of throughput did not increase. This misuse of story points completely invalidated their even relative gross sizes to a point where they could no longer be used to give accurate information back to the business of what teams were capable over the long term. In other words, the valuable ability to be predictable was lost to service a poorly misunderstood metric.

The next problem is that we tend to measure those things that are easy to measure not necessarily those things that are important. There is an old joke about a drunk man looking for his keys under the street lamp.

I found the following account on Wikipedia:

A policeman sees a drunk man searching for something under a streetlight and asks what the drunk has lost. He says he lost his keys and they both look under the streetlight together. After a few minutes the policeman asks if he is sure he lost them here, and the drunk replies, no, that he lost them in the park. The policeman asks why he is searching here, and the drunk replies, “This is where the light is.”

If we only measure only those things that are easy to measure (usually easy to quantify with numbers) as opposed to those things that really matter, then we are no better than that drunk man looking under the streetlight because the light is better. As he will never find his keys, we may never find the truth by measuring what is easy versus what is important.

I often quote from Deming when discussing measurements: “The most important things cannot be measured,” and, “The most important things are unknown or unknowable.”

There is a very simple example that I use often when explaining this concept.

I ask people, “Do you have children?” “Do you love them?” “How do you go about measuring this love?” “Do you use minutes spent? Money spent? An combined weighted score that takes into account both money and time? Or do you do some regular poll of your children to see how much loved they feel on a Likert scale?”

Obviously, the love a parent has for his or her children is of paramount importance, but this is something very hard to measure.

I once spoke to a group of project managers and explained that we measure way too much. We measure things that are either easy to measure or do not really result in better behavior. You would have thought that I advocated clubbing baby seals! They decided that I was against all measurement. The answer is not that I am against all measures, but that I know that measures are limited in value due to the reasons outlines above (and many other human biases), so we need to measure less and be very careful what we measure.

In software development the primary measure of progress has to be working software that meets the needs of the end users. Of course we can measure other things, but there is no more important measure and all other measures need to be subservient to our ability to produce working software.

– Larry Apke

Remember to check out my ! 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Principle #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

While there are many people who believe that the key reason to adopt agile frameworks and methods is for increased productivity, I tend to find this to be more a healthy byproduct of a team working together over time (and thus could be found in other methodologies).

The real benefits of agile lies in greater transparency, predictability and faster time to market.

The third agile principle speaks directly to these, especially quicker time to market.

When organizations I have coached are having issues with agile adoption, I have come to expect that they will have difficulty upholding this principle because it requires the most organizational change. It is no coincidence that there is a greater desire for “dev-ops” as agile transformation is attempted by more, especially large, organizations. In one of my regular presentations I argue that there are two things necessary for agile success over the long term: One of these is Continuous Delivery (or at least continuous integration; the other necessity is acceptance test driven development or ATDD, with my preference being BDD).

It is difficult to deliver working software often, but it is critical. In fact, even if a team is not good at delivering working software often, there is a tremendous amount of value to be obtained trying to deliver software often if only to find out the reasons why your team cannot.

In consulting with organizations I am often asked to merely optimize agile teams, but the real work of transforming to a complete agile system is not considered. These “Wagilefall” organizations are nothing more that Waterfall process with “agile” development (In a lot of cases even this “agile” development itself is not very agile).

I often ask organizations a simple question, “How long does it take you to deliver even a single line of code change into production?”

This is one simple question to gauge your agility. If the answer is more than a day or so then there is a lot of work that needs to be done for continuous integration or continuous delivery. I find it amusing to think that a “big bang” approach with months of code changes can be successfully delivered if it is so difficult to deliver only those few changes that are a result of a single iteration.

– Larry Apke

Feel free to add me on Google+ 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

The world changes fast. The software development world changes faster.

Locking into a long term plan and remaining steadfast to that plan might bring comfort when the world around us is awash in change, but it doesn’t give the flexibility necessary to remain competitive.

If we can react to market changes faster than our competition, we can “harness change for our competitive advantage.” And we should not believe that market share or size can save us because Facebook barely existed only five years ago and I guarantee that the next Facebook is being made in a dorm room right now. Don’t believe it?

Typical waterfall projects are very plan driven and change is discouraged. They rely on things like a change review board to approve any changes to scope. In most places I have been the people executing projects would rather undergo a root canal than to present changes to the review board! On the other hand, Agile requires a more value-driven approach. Agile strives to make sure that value is relevant and can adjust with changes like environmental and competitive pressure, emerging opportunities, unseen potentiality and so on.

Nevertheless, never confuse welcoming changing requirements with chaos.

Using agile or scrum is not an excuse to be unorganized or lack vision. Chasing one BSO (Bright Shiny Object) after another is the surest way to create a disorganized mess of software which leads to a competitive disadvantage and a demoralized workforce.

I once worked with a company that allowed its product owner to change nearly all (about 90%) of a team’s stories the Friday before sprint planning. This led to the team not having the time to groom their stories effectively and resulted in very long sprint planning sessions with estimates of work that were wildly inaccurate. In the end, the quality of the software suffered, the team’s productivity was reduced, the team was rarely able to implement what the business desired and there was a growing animosity between development and business. It was a downward cycle that the company still suffers from today.

If chaos like the above can be avoided then Agile’s second principle proves to be extremely powerful in helping us continually concentrate on emerging value and giving our customers the competitive advantage that they all seek.

– Larry Apke

 

 

 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS