Software Feature Dilution

Introduction

Business analysts, requirements managers, and project managers will find the greatest interest in this article.

Software Product Planning

It occurred to me last week during one of our weekly iteration planning sessions that one of the most esoteric methods around product planning is deciding which requirements to turn into software features.  The more rigorous approaches look at the cost of the feature, the potential impact to ROI ( assuming there is one ), and the demand.

What’s wrong with this approach is that it considers the features and resulting requirements in isolation from one another.  By not considering how each new feature affects the existing product as a whole teams can and do end up with products in which the original feature set, that made the software successful, become diluted.  Those of you who’ve worked with me know my favorite example is CA’s Remedy product, but I think one could find other examples: the Microsoft Office suite of products may be in this camp.

Feature Dilution:  A Formula

So how would one go about constructing a measurement for feature dilution?  First – some assumptions:

  • You know or can retrieve the cost associated with the original marketable software release.
  • You know or can calculate the benefit ( ROI ) for the original marketable software release.
  • You have an estimated cost and benefit associated with any potential new software features.

Ok, so knowing these let’s construct a model for software feature dilution.  We’ll adapt a formula from the world of finance.

V – Value of sofware after Feature dilution =

((O x OP) +(N x (∑ IP1, IP2….IPn))) / (O + N)

where…….

O = original number of features

OP = Current NPV of product ( could use ROI too )

N = number of new features to be added

IP1, IP2, IPn = NPV of each new feature.

If you run this formula through some examples in time what you’ll find is that as a product matures new features need to continually generate greater returns to justify value to the original product and ultimately diluting the existing feature set.

This is exactly what should happen if we want to avoid the fate of an overly complex and unmanageable software product.  Just like stock market share dilution the product management team needs to justify that further feature dilution will grow the value of the product in terms of existing functionality…..not just that it will add to revenue.

Summary

Simplicity in software design has always been something great software architects knew yielded great products.  With this formula I hope I have provided at least a start to measuring simplicity in software.

I’m Skeptical on Agile – Sell Me

Introduction

This article will address a common reaction to those presented with the possibility of adopting agile in their enterprise: skepticism.  CIOs, application development managers, directors, and senior architects will glean the greatest insight from this but development professionals and project managers will find interest too.

On Being Skeptical

As a software professional your skepticism is not necessarily misplaced. There are plenty of agile coaches in the market today professing to deliver faster, better, and cheaper on a regular basis.  Their message is honey in the ears of the right executive.  It becomes even sweeter when you consider the economic climate that many businesses are facing today.  There is opportunism here and it would be well advised to vet any agile coach.

How do I know an agile coach is worth the money?

I’ve devised a simple matrix ( below ) to help guide one in validating an agile coach.

Weight Coach 1 Coach 2 Coach 3 Coach 1 Score Coach 2 Score Coach 3 Score
Number of Projects Managed 3 2 17 3 6 51 9
Years of experience in SD/AD 2 5 24 7 10 48 14
Highest Budget Management Experience ( 1 = true, 0 = false ) 1 1 1 0 1 1 0
Number of References Validated 3 3 8 1 9 24 3
CSM Certification ( 1 = true , 0 = false ) 1 1 1 1 1 1 1
PMP Certification ( 1 = true , 0 = false ) 1 0 1 1 0 1 1
FINAL SCORE



27 126 28

So let’s talk through this matrix a bit.  First, I give pretty heavy weighting to experience here.  In truth we’re not just looking for an agile coach we’re looking for someone with the battle scars of being in the AD/SD world and knowing when and where agile works vs more predictive methods.

We also want to know that they’ve actually implemented agile methods in other places hence the need for validating references.  The key word here is “implemented”.  There are plenty of folks who can regurgitate the agile manifesto and paraphrase the thinking of leading agile theorists, but agile coaches should show a track record of making it happen.

Budgetary management experience, in my opinion, is essential.  If they haven’t managed the dollars/euros/yen around a capital project ( or operating costs ) then they may have a very misguided notion of why projects succeed or fail.   The CSM or PMP who was merely accountable for a timeline with only a misty concept of how it related to money is ill-equipped to profess a transformation of your SDLC process.  Why?  Agile techniques profess delivering software in iterative cycles ( every 2 weeks ).  If some level of requirements aren’t complete by the end of each iteration you have two options on a fixed bid capital effort:

  • Don’t do that functionality.
  • Postpone it until you do have the capital available.

This sounds fine in theory, but the truth is that every system has some minimal set of requirements that must be completed for the software to be functionally usable.  If the money runs about before the agile projects succeeds in delivering this minimal functionality then your project will be seen as a failure.

Certifications show learning of theory.  I weight them low, but still think its practical to have these ( Certified Scrum Master and Project Management Professional ) if an agile coach is selling himself as a professional in software development delivery.  They should understand and know agile as well as more traditional management concepts and techniques.

Lastly, you should realize that agile adoption is not just a function of the agile coach.  The organization needs to be willing and able to accept the changes agility will introduce.

But my current process works, so why should I switch to agile?

If you have a working process and there is no immediate need to push you to agile then you should take the time to map out a strategy for your development shop.  Agile can be beneficial and Ryan Martens at RallySoft does a decent job of articulating when agile methods can benefit a development project.  His rendition of the Uncertainty vs Complexity diagram proposed in Stand Back and Deliver gives an AD manager a basic tool for plotting his/her projects along these two broad metrics.

project-types

What are the benefits if agile is applied to the right type of projects?

Better Risk Mitigation – Agile methods emphasize iterative delivery of software.  A standard cadence and check point to the project sponsors allows for defects, requirements misunderstanding, and general issues surrounding the effort to be mitigated on a timely basis.  Couple this with a daily stand up meeting where team members determine how to resolve issues and coordinate work and risks to the development effort are generally better managed.

Testing starts earlier – Agile development emphasizes vertically slicing your application and developing functionality incrementally.  This is a technical challenge, but assuming the development team can tier the system architecture this way, then your testers can usually start functional testing much earlier in the development cycle.

Increased Sponsor Satisfaction – Project sponsors are involved routinely through agile.  The developers have a direct line to the customers.  This continuous feedback loop usually leads to better communication and understanding between the team and customer.

Stronger Team Accountability – It takes time, but as the team culture shifts from command and control to a collaborative effort where developers take responsibility, collectively, for their work; the team begins to see how their efforts help/hinder the project.   An adjunct to this is an increased sense of pride in their work and kinship with each other.

What do I need to watch out for when adopting agile?

Cultural Shift – This can’t be under weighted.  Agile places greater emphasis on the team managing itself and its day to day activities. Subtly, agile preaches two things:

1. Development team and customer working together.  Meaning other managers and IT leadership have a de-emphasized role.  Your risking attrition by some of your better players if you ignore this.  Proper coaching and preparation for this change and its effect on roles and responsibilities is essential.

2. Team stepping up and coordinating activities among it’s members.  This is normally done by a PM or Dev manager or even a senior technical leader.  Some methodologies, like Scrum, emphasize a new role ( scrum master ) to take on the facilitation aspects.  For developers unaccustomed or uncomfortable with organizing and planning this may be difficult.

“Documentation is not needed”  – You may hear this from some agile coaches and theorists.  The original agile manifesto emphasizes working code over documentation, but as a development professional you’ll need to decide if this really makes sense  for your project.   Some of us have regulatory and legal reasons for documentation.

Dogmatic Views – I wrote about some of this in Bad Attitudes of Agile, but some team members will see agile as a very strict set of practices and may twist the theories and methodologies to suit their own ends.  By its very description agile is meant to be a flexible approach to software and application development not a rigid set of rules that cannot be altered.  There are the pragmatic agilists and then there are the agile zealots.  Watch out for the latter.

Summary

Benefits can accrue from agile methods.  These benefits, for the right projects, should result in better quality, reduced cost and schedule variance associated with requirements misunderstanding and defect management, and a more complimentary relationship with your customers.  As mentioned earlier skepticism is not misplaced, but by looking for an opportune experimental project to introduce agile a development manager can assess its applicability for his/her shop.

Agile vs Waterfall vs Lean Startup : Who Cares About the Labels?

Labels

After reading Shane Hastie’s latest InfoQ article:  Lean Startup or Agile or Lean Startup and Agile?  it became clear how much we’re all getting caught up in labels and methodologies.  My thought:  let’s drop the flag waving, become pragmatic in our approach and recognize that context plays a crucial role here.   What works for Eric Ries and his start-up may not work for the company you work for and the project you’re currently executing.

The Real Value – Techniques & Tools

The value in methodologies like Agile, Scrum,  Lean Startup,  Waterfall and others is in the techniques and tools they bring to the table.  While they are each packaged with a neat title and some intelligent proponents; we don’t need to use these in a take it or leave it fashion.  Be pragmatic and assemble your own toolkit.  I’ll reference Scott Ambler and say “context matters“.  We all need to move towards a collection, library of project and product management patterns that can be adopted within certain contexts.

Innovate 

Lastly, what’s invigorating about these debates is that we’re growing as a field.  We’re rethinking our ideas, and not settling.  This can only be good for software development and those affected, infected by it.  Yes, I meant to say “infected”.  🙂

Agile or Waterfall — Aren’t We Just Struggling With Requirements Understanding?

Who is this article for?

All software development professionals will find interest in this article, but those managing, crafting or analyzing requirements may find the most interest.

Introduction

Why is so much ceremony needed around software development?  Regardless of the methodology there is a great deal of meeting, clarifying, verifying, demonstrating, and checking.   If you came from another planet and watched how we develop software you’d come to the conclusion that we don’t know how to communicate complex abstract ideas into concrete reality.  And we don’t. To be sure, we’ve tried:  detailed specifications, UML diagrams, use cases, user stories, and just plain discussion.  All of these are incremental changes to a better requirements landscape, but fleshing out our software needs still takes considerable time and effort.

Process and Methodology as Requirements Risk Mitigation

BDUF ( Big Design Up Front ) was the waterfall method to define requirements.   It was a way of saying….”Let’s get everything straight BEFORE we start the expensive process of coding and testing all this.”    It’s logical, but makes the broad assumption that people will know what they want and deviation from the initial plan will be minimal.   There are some projects where this is a very safe assumption, but not always.

Agile capitalized on this fault and said “You can’t know everything up front, so just get started and course correct along the way.”   Does this mean that agile projects always succeed? No.  It means that they allow adaptation to change.  Projects where innovation is important or where the product owner is unfamiliar with developing software naturally make good candidates with Agile.  But its pricey and if you don’t need all the involvement…..then going back to waterfall might be a good option.

With both methodologies you see an attempt to address the real problem:  understanding and materializing requirements so that we get exactly what we want.   The abstract nature of software means we’re collectively imagining what it could and should be.  But we haven’t found a silver bullet for this type of collective dreaming.

Communicating and interpreting our desires is not as easy as it seems.  Some of us are good at drawing pictures…..but most of us aren’t.  To mitigate the possibility that we’re not going in the right direction we’ve invented these elaborate software processes ( Waterfall & Agile …..and the pragmatic others ) to keep our collective minds on the same path to vision creation.

Are  There Better Ways?

Even with these processes we still end up in projects where we hear these things said:

“Oh…that’s not what I meant.  It should do this…”

“No, no,no….you didn’t understand what I was saying. “

“That wasn’t the requirement.  Read it again….I built what was asked for.”

“Yes. I know she said that….but what she really meant was…”

So, software requirements are still an error prone bottle neck in producing the product.  If we hope to make software development better;  then we must get better at this.  In paraphrasing Eliyahu Goldratt in The Goal: You can only run as fast as your slowest player.  That player for software is requirements gathering, analysis, understanding and verification.

Looking outside our field, other industries, who’ve been around longer and develop complex systems too, have similar challenges.  What do they do?

Design –  My wife is a talented contract graphic designer for a local St. Louis firm called Kuhlmann-Leavitt.  They’ve won many awards and have very satisfied customers.  All this despite the nebulous, subjective nature of graphic and three dimensional design.   How do they do it?  The design field is interesting.  They don’t estimate anything.  They simply ask that you hire them for your artistic work and set a budget.  They’ll do the best design work they can for that money.  No more, no less.   So right away the budget issue is taken out of the picture.  Lastly, they don’t ask for detailed requirements,  just some idea of what you’re looking for.  You’re not hiring Kuhlmann-Leavitt to build.  You’re hiring them to create.  My bolding hints at the nuance.  Considerable authority and autonomy is given to the designers.  This is just expected.  Software development relies much more heavily on ‘domain experts’.

Manufacturing – In the manufacturing world BDUF could be rewritten to be MDUF ( Massive Design Up Front ).  Not only is the product designed way up front and in detail, but the process and mechanisms to build the product, which aren’t always the same, are designed up front too.  Before the real product even undergoes one production run…many small demo runs are carried out.  The results are stunning.  Once the product starts rolling off the assembly line its produced to exacting tolerances.  It mostly fits the requirements of marketing and can be replicated thousands of times over.

Construction – We’re talking about unique, one of kind construction here.  Not production line assembly of a subdivision.  This one-off building is, to my mind, the most similar to software.  Some requirements come from regulations and building codes.  Others come from the purchaser of the structure.  There are multiple stakeholders.  Requirements are digested, and then artifacts are created.  A series of mock-ups are assembled and based on this a cost estimate is created.  Even with all the up-front planning there are always “gotchas” and changes that are thrown into the project.

In all three of these examples the end product is visual and intuitive which helps with requirements understanding.  A picture really is worth a thousand words.  Software, as workflow, data and creative design is more abstract.  We’re trying to craft ideas and concepts into something that is somewhat tangible.  Certainly the user interface can be mocked in a similar way and there is great value that comes from the discussions around this, but a sufficiently detailed workflow and data set always serve to vex our attempts to provide clarity to requirements.

What’s next?  What can we do?

Here’s part of our problem:

1. We discuss the first iteration of requirements with our product owners.  The person leading that discussion is gifted in facilitating this.

2. From this meeting, the requirements are crafted into user stories.

See it?  We just lost all the context, emotion, body language, nuance, and reactions by everyone else by drafting something into writing.  I don’t care how good a writer you are…you can’t replicate the requirements conversation.  So why do we try?

The next problem comes when you ask each person to interpret the written user stories.  Hopefully each team member was present for the conversation so they could somewhat remember what transpired.  But, even with attendance, the human memory is frail and human perceptions, bias and concentration vary. Each person may see and read the requirements slightly different.  In short there are too many lenses.

Rather than try to abstract requirement conversations into another form ( writing ) or create even more abstract artifacts ( UML, Use Cases ) we should seek to record them via video, photographs of whiteboard drawings, and publishing all this to some kind of requirements wiki or blog.  Doing this for each iteration review, iteration planning, or project meeting would surely capture a much more complete document of the project’s scope, changes, stakeholder motives and historical background.  Further, it would exist in perpetuity for future developers to watch……just like a movie or project documentary.

Summary

I do realize that the suggestion to move towards requirements documentaries may be fraught with organizational, legal, and other challenges.  I would never suggest that change on this scale is easy.   But I do believe there is productivity savings to be found here.  As I hinted in Decline of Written Requirements  I think we’re using 20th century tools and techniques to gather and analyze requirements in a 21st century world.  To lessen the need for process mitigation of requirements risk we may need to refocus and leverage our new tools: cell phone cameras,  high quality digital video, wikis, and blogs.

Can Agile Work in Big Organizations?

Who is this article for?

All software development professionals will find interest in this article, but managers, CIOs and software architects will find the greatest interest.

Can Big Organizations Rapidly Change?

Think about the last big company you worked for.  Did it move fast?  Change overnight?  Did anything get done ‘quickly’?  Weren’t there gobs of jokes about the ‘bureacracy’.  Big companies run slow.  When they need to move fast they put people outside the organization or buy smaller companies.  Change is just not a priority inside a company like this unless it is facing financial issues and agile presents a significant challenge to the orthodoxy and bureacracy of such a beast. But is that a reason to not attempt agile in a large corporation?  No.  But it is a reason to have a different strategy for a change adoption.


Hybridization of Agile:  Pragmagile

Yes….but you have to be pragmatic.  What I mean is that you’ll need to realize that this bureacracy and the people in it were bequeathed their titles for a reason.  They’re successful, to a certain extent, because they know how to get things done despite all the red tape and foot dragging.  As an agilist, these people are not your enemies despite their gantt charts and stakeholder evaluation matrices.  They’re your allies, your tools to be upwardly managed.

So considering this I’ve compiled a list of tactics that I think may be helpful for any agilist hoping to succeed in a large professionally heterogeneous company.   Here they are….let me know if you agree?

1. Follow the principles of The Pragmatic Manifesto.   Key among these… is embracing everyone…not just the software development team.  See everyone as having value and being able to participate and contribute to your software development process.  Be pragmagile.

2.  Walk it, don’t talk it.  Show your company agile works.   Don’t go around preaching it and extoling its virtues when you haven’t even delivered one project yet.  You might even want to avoid the word ‘agile’ altogether and just say this is how I like to work:  meet every two weeks, go over any changes, hedge the risk that we don’t understand, and adjust project course as needed.

3.  Help your project sponsor help you.   Your project sponsor in a large corporation is likely a veteran of the company.  Don’t discount this as ‘stuck in the old  ways’.  They know stuff you don’t and they can help you stay in good graces with all the red tape barrons.   Keep a solid, open and agreeable relationship with your project sponsor.

4.  Give a little, get a little.  Another way of saying this…….don’t be dogmatic.  If someone doesn’t like some aspect of your agile approach don’t automatically write them off.  They may have good reasons for their objection, and by showing your concern and willingness to adjust…..you’re demonstrating a core tenant of agility.    If stand-ups are hard for people with back issues, then try a 15 minute conf call.   If the customer just can’t meet every two weeks, then try every month or on a more lucid schedule.  But above all…….be flexible.

5.  Focus on the goal.  Delivery of your project/product is what you’re after.  Not agile adoption by your company.  Maybe you’ll get this as a side effect, but honestly…….you probably weren’t hired to evangelize the enterprise. Furthermore…you can’t do it on your own.  Put your accounting hat on and think hard-ball.  Git-her-done.

6.  Seek to understand the culture and the history behind it.   Maybe your company doesn’t move fast on this software project because your building something that its enormously complex and could kill someone if not done right.  There may be very good reasons for stifling rules and countless reviews/approvals.  Work with the grain of the wood…not against it.

7.  Stop assuming everyone wants to be agile.   Worse yet, stop assuming everyone knows what it is.  They may have heard about it and chalked it up to no  more than a new process.  But those of us who’ve lived it know that the real change is cultural.  It’s a tough shift and it won’t happen overnight.  Be patient with those around you.  They’re trying to learn and you’re there to help them along.  Be prepared for the guy who says “Agile sucks and here’s why…”.  He may have valid reasons for his opinion and discounting him will only deepen his view.

8.  Figure out the commitment level up front.  I wrote about this in another article:  Are You Committed?   But, essentially the team is supposed to commit to the iteration at hand.  But….what does that really mean?  Commitment is one word with many different interpretations.  Don’t assume you know how much the team is willing to commit and don’t assume that the companies HR policies and benefits jive with the agile philosophy.

Summary

That’s it.  I know I probably should have run it up to 10 ( don’t all good lists round up to 10? ), but I’m not going to throw down fluff just to reach a number.   It’s been my experience that if you make agile work in an organization people will just naturally ask you:  what’s your secret?  Why do your projects work out while other projects fail?  If you get to this point then I guess it’s ok to preach a little bit, but step off the soap-box when you feel your head getting bigger.   😉

The Pragmatic Manifesto

This is a manifesto for pragmatic software development.  We are uncovering sensible, common sense practices for creating better software.  We value:

1. TEAMWORK: Working as a team with our customers, our team members, and our leaders to accomplish the product, project and company goals.

2. FLEXIBILITY: Flexibly adjusting our practices and efforts to meet the needs of the product, project and team.

3.  HUMILITY: Accepting that we don’t know everything and we should always strive to learn more and adjust our efforts as needed.

4. DISCERNMENT: Not get caught up in the latest buzz, but think for ourselves, our team, our product and our customers.

5. RISK MANAGEMENT: Realize that “risk” and the management of it, is the greatest determinant of software development success.  This doesn’t necessarily mean we avoid risk.

6. TALENT: Recognize that teams are composed of people with varying strengths and weaknesses.  There are no supermen. Sometimes we shine…sometimes we’re learning.

7. VISION:  Seeing the future and present and crafting solutions that will address both.

If you believe in this manifesto…then do it.  No need to sign up, attend classes, write books or pontificate. Just, live the principles.

Christopher R. Goldsbury

Agile Finance – Story Point Cost

Who is this article is for?

This article is written for those with management and budgetary responsibilities for a software development project or team. Others, including developers, quality assurance personnel, and CEOs/CIOs may find interest.

Why would we need to estimate story point cost?

Story points are used to estimate work. Investment in that work is expected to derive some benefit. If that benefit is expected to be financial then understanding the cost of that work is essential to deriving any meaningful ROI. Even if no ROI is expected and the intended benefit is regulatory compliance ( as an example ) then company leadership usually wants to understand what how much of their limited financial resources is going towards any specific feature, iteration, or release.

How do we do it?

The technique presented here is a historical parametric approach. It relies on past data from previous projects. So, one has to have some of this data saved up before a reliable figure can be derived.

RC = Total dollar cost for a historical releases in a product

RSP = Total story points that contributed to that release.

RSPC = Release Story Point Cost

RSPC = RC/RSP

Once you have this for one release you should calculate it for all historical releases. The next calculation is an average:

Average RSPC per product = ∑ RSPC¹, RSPC²……..RSPCⁿ / N

If you want the story point cost across all products then average it again. Although, for most planning purposes it’s useful to plan by product line and this higher level of abstraction of cost might be too watered down.

What questions does this help answer?

  1. How much will it cost to add this feature?
  2. How much will it cost to deliver release 2.1.0 ?
  3. What is the cost of an average iteration?

How often should it be updated?

The astute among you will notice that we’re using historical data. Historical data is only accurate as long as change doesn’t take place. To counteract the shift and change in time size, capability, and mix one needs to do these calculations at regular intervals. How often? This is a judgement call. I do it monthly as I’m in rapidly growing team with many new products popping up. I constantly need to reassess my cost driver.

A more stable team and product might require only 6 month intervals. The relevant point here is; keep it accurate.

Summary

Story point cost ties a rather abstract and developer centered concept to the real world of business. This is necessary. If we intend to use story points in a meaningful fashion in our development environments than they must have some corollary to the spreadsheets, and ledgers that the world’s businesses run on.