Compressing Software Lifecycles by Eliminating Lines of War

As we've experienced for years, software development lifecycles get chunked up into phases, particular groups of people get associated to each phase, entry and exit criteria end up associated to each hand-off in between ... and we now have a framework we've created in the name of quality. Ironically, the framework (ordinarily accompanied by required templates and tools) really only protects us from each other and ourselves, but doesn't evidentially protect the customer or even serve the customer.

After all, what did the customer actually ask for but a deliverable, on a timeframe, on some specified amount of money.

What I see time and time again "delivery teams" or "projects" composed of departments for the purposes of career paths and salary trees, human resource considerations, and division of labor. Sometimes said resources are "matrixed" out to cross-functional teams, but there is a conflict for the resource in question as to "who is truly my boss?" I'm sure there are more reasons for this out there and these are deductively logic structures based upon the need to organize people within a company. Unfortunately, some people tend to confuse the resource management structure within a company with the team structure actually needed to deliver something to a customer that they wanted, when they wanted, at some specified or important cost. They are not the same. Due to this confusion, these lines between resource management groups often become lines of war. When hand-offs are expected to happen between departments, expect turmoil. We're a team until some department did not deliver, and then "the so and so group did not deliver to us and we will now be late."

Here are three things I've personally done to help eliminate silos within groups responsible for delivering:

One: Eliminate the black box testing phase

I support Agile frameworks which I'll explore in another post. Summarily, rather than having people do whatever work it is that they do .. and then eventually hand off to a seemingly ostracized test group "over there", eliminate the group.


  • Take the test group that sits in another part of the building, split them up, and sit them right in the middle of the development group according to pairs or iteration teams
  • Make the ordinarily black box or functional/regression tester become part of the creation process rather than validating that a creation process occurred
  • Expect the tester to write automated tests based upon prioritized functional threads that can attach to the continuous integration build routine called on a nightly basis

In other words, figure out how to test during the development process rather than afterwards. As new builds come off the line each night (or hourly or whatever it is you do), have the testers reset their environments and go at it again. Clearly many traditional test groups are not comfortable moving at this pace as they prefer dedicated time on one load before moving to the next. Let the cadence be set by continuous integration builds and reset all other behaviors to synchronize with it.

Two: Eliminate the business analysis/requirements phase

Nothing new here for some. Consider that many times business analysts or requirement individuals are "sent in" to "go get" the requirements. This is often considered the precursor activity to anything else downstream.

Some of the multiple challenges with this logic include:

  • The requirement/business analyst must interpret the need, document the need, and translate the need to people who actually do the code construction (i.e. developers) and testing somewhere else in the journey
  • Most other team members wait until someone tells them the requirements journey is "over" and they may now proceed
  • Requirements are often documented in a way that makes sense only to the person eliciting and documenting the requirement

Get rid of this experience altogether and instead consider the following three (four) changes:

  • Have a developer with social skills interface with the customer and elicit the requirements in the form of user stories, descriptors and acceptance criteria
  • Include a technical tester to help document the conversation, summarize the results, and ensure that the descriptors make sense and the acceptance criteria are in fact automatable and testable
  • If possible, consider including your trainer/documentation/e-help person in this environment as an observer so that they begin to understand how the system will be organized, used, what is most important versus less important, testability, etc.
  • Deliver working tested software representative of N user stories every two weeks

Only include people who will actually do work. Eliminate translators in the middle. This action reduces cycle time, defect insertion, and the number of people necessary to understand and deliver the system. If a team is expected to deliver working tested software in two week chunks, it will influence how much time is spent creating documentation versus actual software.

Three: Eliminate titles

Titles often box people into specific behaviors. "I am a requirements or business analyst". "I am a test analyst". "I am...".

Here's what the customer cares about ... working, useful, value-add software versus my title. Unfortunately, in many company systems, titles equate to salaries and rank. A miserable side effect is "that's not my job" -isms stimulated by the territorial boundaries.

For the purposes of human resources and getting paid, titles must allegedly exist - though I continue to explore ways to make job titles less meaningful. For the purposes of creating a true team that trusts each other and is willing to do whatever necessary, regardless the role or task, to deliver working software every two weeks ... eliminate titles. Rather, have roles.

A team composed of a developer role, sys admin role, test role, and dba role are equally responsible to deliver N working user stories at the end of a two week sprint.

Along the way, the encouraged behavior is that:

  • anyone can code if and when necessary
  • anyone can test if and when necessary
  • anyone can dba and sys admin when necessary

The only limit on such a team is attitude and aptitude. Yes, there are declared roles whereby one person may be expected to fulfill one or two roles; however, if time permit or need merits, the team helps the team help the customer. If we experience one person watching while someone else is struggling, we have a broken team. N people on a team. X roles required to deliver Y user stories in two weeks.

  • Title-less teams require people to evaluate their own skills and upgrade or evolve them, or move on
  • Title-less individuals require teams to evaluate what they are capable of delivering in two weeks by considering everyone's ability, not just their own
  • Title-less teams force people to focus on work not done versus who's not doing work

There are many other changes available to stimulate a shift in how software is delivered in our organizations. The aforementioned three elements:

  • Eliminate the black box testing phase
  • Eliminate the business analysis/requirements phase
  • Eliminate titles

1 comment:

  1. Interestingly enough, I do agree with the tone and directions the post tries to promote. However, I disagree with the need to eliminate all these completely. There are reasons for all the points you propose to eliminate. While agile has own methods for curing these reasons, there is still value in the old ways.

    For example:
    1. Black box testing
    In some situations black box testing can take several days or even weeks. E.g. if you have to manufacture and deploy the hardware and network.
    Try to remove the reason for such a long testing - yes.
    Incorporate multiweek testing into an iteration - no

    2. Requirements phase
    Unless you are doing the internal development or have really good relationship with the customer, you have to sign a contract based on some fixed assumptions. There is no other way of coming to the price tag, than to analyze what has to be done.
    Try to move at least a part of the reqs analysis into a real iteration or prototype iteration - yes
    Include into the contract the option to easily change the reqs - yes
    Eliminate the whole req analysis - no, unless you want to go out of business

    3. Titles
    We do need specialists. A database expert might tune the database better and sooner, then any team of testers and programmers. Also specialist titles to bring more self-respect to the people
    Promote the cross-functional teams and willing to help testers even if you are a DBA - yes
    Eliminate titles - no

    Please, note that the above is not a complete list, but just a couple of examples I was able to invent in five minutes. Nevertheless, my point is in that the direction proposed by you, Matthew, is correct, but as for me you urge everybody to go too far in this direction.