InTanj - A new software development methodology project video thumbnail
Replay with sound
Play with
$183 pledged of $150,000 goal
By J. Scott Garibay
$183 pledged of $150,000 goal

Thank you to each and every backer of InTanj

The goal, to create a new software development methodology abandoning 20th century principles and practices, built from the ground up for makers of intangible goods, was important and needed to be achieved. However, the goal was not intuitive. I failed to describe the need and vision succinctly and deliver it broadly to the audience it needed to reach.

Thank you again to each and every backer of InTanj, for seeing the value in something complex and intricate and for your bravery to support something new and fresh.

Also, special thanks to Kickstarter. My lack of success here on this project does not change the fact that Kickstarter is the best place to build wonderful new things for people who desire the unique and innovative. Again, thank you from the bottom of my heart to to each InTanj backer.

Down to the last three days for Kickstarter

Hoping to see a bump in funding from the 48 hour starred project set.

Requirements Innovation - Sketch Alpha

Over my years as a Software Quality Engineer my respect for the role of Product Manager has grown steadily. This role, critical on any complex product, has the duty of determining what changes will be made in the product. Specifically, the Product Manager determines what new pieces of functionality will be delivered in the next release and what defect fixes (if any) will be weaved into that release (or if defect fixes will be processed in a separate release). It is a  challenging task - determining the right new functionalities that should be delivered among the many that are 1) being asked for by the client, 2) that changes in the market and industry demand and\or 3) that the Product Manager believes will allow the product to offer something unexpected and powerful to the product's users.
Shockingly, often it is not really the Product Manager that decides what new functionality will be built. Many times I have witnessed this very common pattern (below) occur.
Product Manager declares three new pieces of functionality to be delivered and shares the list with Development for feedback.
Development says one new piece of functionality is fine and can be built, but the remaining two pieces of functionality 1) simply cannot be built or 2) will take a very long time to develop or 3) will require additional developers or new developers (with different skill sets) to complete.
Product Manager takes Development's feedback, changing the plan to deliver the one piece of functionality that Development is OK with and fills the rest of the release with defect fixes (an easy and simple response to Development's feedback).
The pattern detailed above is common and is a terrible way to determine what new functionality is delivered, because Development is deciding what is being delivered rather than Product Management. The effect to the product when this done is worse than if the Product Manager coded the new pieces of functionality, rather than Development coding them.
I have often wondered why executives are not alarmed when Development decides what will be delivered, but the idea of Product Managers writing code would immediately be flagged (as well it should be).
With InTanj, Product Managers would be equipped to respond differently.
Product Managers will be encouraged to work with Development to push further together and determine how Development can achieve what they have stated they cannot. (If the Development team feels a piece of functionality cannot be delivered, it is important to recognize that this means success at building that piece of functionality will immediately produce a barrier to market for competitors trying to deliver the same functionality to their clients.) Product Managers also will be equipped to draw the Executive team in to show them the opportunity that Development's "no" has revealed.

If the executive team upholds Development's "no", Product Managers will have a platform to require from Development the plan Development has to increase the teams' existing skill set so that future needed new pieces of functionality can be delivered.

The Product Managers desire to minimize conflict with the Development team is understandable, but allowing the Development team to drive what new functionality is delivered (extremely common practice today) needs to end on any and all teams it is occurring on. Teams need a sound and agreed upon understanding that Product Management sets the direction for the product and that any group other than Product Management that is changing that direction is adding risk to the product and is stifling its progress (as surely as poorly written code will do).  

Distributed Communication - Sketch Alpha

Distributed communication is key element of InTanj. Focusing on distributed communication means several things, one of them Open Core Metrics.

Many members of software building teams spend a portion of their day updating and getting updates on where other groups within the team are.Their questions questions look like this.

  • How many of the 10 new pieces of functionality have been coded by development?
  • How many of the 10 new pieces of functionality have been tested by QA?
  • How many of the 10 new pieces of functionality have been documented by Technical Writing?
  • Was funding approved by the Executive team?

On teams using old methodologies team members get answers to these questions by asking other team members by email or a phone call or chat or text or, Heaven forbid, a meeting.

Open Core Metrics, an element of InTanj Distributed Communication, does away with this slow, interrupting, frustrating Q&A loop. Software building teams should use tools (COTS, custom or open-source) and tool configurations that allows team members to complete their work and the tool recognizes the work unit is complete and automatically allows that completion to be reflected in one simple automatically updated metric that is available 24\7 to every member of the software building team with a few clicks.

An InTanj team member would reach a point of embarrassment to ask any of the questions above of another team member. With the open nature of the Internet (and intra-nets) these types of questions should never again require team members to speak to one another, taking each others time, over a question that is within a few clicks of answering.

The goal is certainly not to reduce the time team members spend speaking to each other. The goal absolutely is to decrease the time they are speaking about metrics that should be as simple to understand and as visible as reading a clock on the wall, thus freeing them to speak on issues that require discernment, collaboration and\or debate.

Still no viable alternative to Agile

Software Developer Isaac Schlueter's article "Agile Scrum Sucks (but so do the alternatives)" goes to the heart of why I am building InTanj.

The article was written in 2007 and still there is a not a viable alternative to Agile for software building teams.

One of the primary focuses for InTanj will be to ensure that the software development methodology serves all members of a software building team; developers, testers, designers, technical writers, hardware administrators, support, release organizers and leads.