Funding Unsuccessful This project’s funding goal was not reached on .

Update #8

Thank you to each and every backer of InTanj

Comment

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.


Update #7

Down to the last three days for Kickstarter

Comment

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


Update #6

Requirements Innovation - Sketch Alpha

Comment
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).  


Update #5

Distributed Communication - Sketch Alpha

1 comment
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.


Update #4

Still no viable alternative to Agile

Comment

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.


12
Backers
$183
pledged of $150,000 goal
0
seconds to go
  • Pledge $1 or more
    You selected

    10 backers

    Helper - Full ebook detailing Intanj 1.0 SDM.

    Estimated delivery:
  • Pledge $50 or more
    You selected

    2 backers

    Assister - Full physical, signed book detailing Intanj 1.0 SDM (and a listing within the book as an InTanj backer). + All rewards above.

    Estimated delivery:
  • Pledge $100 or more
    You selected

    0 backers

    Supporter - Access to InTanj 1.0 SDM design content, an advance in-depth view of the the creation of the InTanj SDM as it occurs. + All rewards above.

    Estimated delivery:
  • Pledge $1,000 or more
    You selected

    0 backers

    Contributor - One pre-registration for InTanj Guide Certification. The first three months InTanj Guide Certification training will only be open to these pre-registrations. These pre-registration include 1) online or on-site training (the choice of the backer and travel to on-site training is supplied by the backer), and 2) the option to test up to three times to achieve InTanj Guide Certification. + All rewards above.

    Estimated delivery:
  • Pledge $5,000 or more
    You selected

    0 backers

    Benefactor - Participation in monthly conference call on InTanj design through to the planned launch in April 2012. Ability to directly request features to be included in InTanj as it is designed. + All rewards above.

    Estimated delivery:
  • Pledge $10,000 or more
    You selected

    0 backers Limited (10 left of 10)

    Founding Innovator - Always identified as one of ten Founding Innovators of InTanj on all InTanj material and releases. Founding Innovators are always informed and feedback is gathered from Founding Innovators before new editions of InTanj are released. + All rewards above.

    Estimated delivery:
Funding period

- (40 days)