What to do? we are like this only

Product development - Needs versus Wants

2010-12-16T08:45:00.004-06:00

One of the primary role of a product manager is to prioritize the numerous features into a release of a product. Some of these features may be a "need to have" feature while the rest will be a "want to have" feature.

How do you differentiate a need from a want?
"Need" is something that your end users are assuming your product has and won't necessarily be wowed by its presence. This feature is usually something like a regulatory requirement or security feature or may be the basic feature set of your product. Lets take an web email portal as an example, any new client would expect to be able to send and receive emails. There is an expectation that only an authorized user can view their emails. You cannot have a viable web based email without out a log in and log out feature. However something like tagging emails or being able to search all your inbox blazing fast is not a need.

"Want" is something that will set you apart from competition, this could be anything from a killer feature set like the touch screen interface when the iphone first came out or performance feature that out paces everything in the market . Like what google was when it first released its software.

It is a product managers job to balance the need and want feature set and come up with a compelling product that both satisfies all the target demographics needs as well has enough wow features to make users want to use your software over the competitors software.

One way to come up with the right mix is to split all your features into "Needs" and "Wants" category and then pick the highest priority wants and needs. Making a clear distinction between the two types of features, lets you maintain a right balance.

If you are trying to build a utility software, then your final list should probably be heavy on the "needs", while if you are in the business of building Strategic software, then you are better off going with the bare minimum need features and pick and choose your highest wants.

They don't have the right to read a book out loud

2009-02-11T10:04:00.006-06:00

"They don't have the right to read a book out loud" said Paul Aiken, executive director of the Authors Guild

http://online.wsj.com/article/SB123419309890963869.html

Really !!! REALLYY!!!

Businesses need to keep up with technological advances. Some people are incapable dealing with change, so they hold on to old tested ideas.
Instead of trying to find ways to leverage a new innovative technology, they try to fight it. These people will eventually lose, because there is a demand and the some publisher/author will break ranks and satiate that demand.

The question is will the book industry go the music industry way. Do a bunch of publishers have to fail before the industry realizes that the only way forward is to embrace change.

http://www.flickr.com/photos/vintfalken/ / CC BY-ND 2.0

Is QA incented to release software in the traditional development model

2009-01-22T07:05:00.012-06:00

Two years ago I was part of a team that built a large insurance system and released it to group of beta customers. The response from the customer was positive. The development aspect of the project got done and I left the client. Last week I happened to meet with someone associated with the project, and he told me that the software had never made it to GA (General Availability). Apparently the QA folk were not 'done' with their work and were unwilling to certify the software.

Even though this may seem odd, it makes perfect sense if you understand the SDLC cycle. The QA folk have no say in the development of the software, when the development team gets done, it throws the software over the wall into QA land. If a bug is discovered once the software is in production, management comes down on the QA team like a ton of bricks for not catching the bug, if everything goes well in production the development team gets congratulated for the superior product.
It is a typical case of heads you win, tails I lose.

This makes me wonder, what is a QA manager's incentive to release software to production.

Contrast this with a typical Agile team, where QA would be part of your development team, this helps you to bake quality into the software as it is being built, rather come back and find defects once the whole software has been developed.
As QA is part of the development process, it gives them more time to test the new features as they are being built and regression test the software in every iteration also the cost of fixing defects go down as the developers are more familiar with the code during the iteration than coming back and picking it up at the end of the development cycle.

The cost of fixing bugs in production should be brought down.
The process where from the time the bug is identified and to the time the software is patched (hotfixed) and put in production should be minimum. If we do this QA will be more confident to release the software because even if something went wrong the team can fix it at a low cost and in minimum time.

Developing on Windows: Reinstalling disabled services

2008-09-04T05:41:00.005-06:00

As part of our project we have automated installing a service as part of our deployment script. However services go into a zombie state of 'disabled' if you have given the service a wrong password and tried to start it up.
Once a service gets disabled you cannot start, stop or uninstall it from the services console (services. msc). Rebooting the machine gets rid of the disabled service, and we can reinstall the service, however rebooting isn't an option for production machines.

We finally realized that we could reinstall the service over a disabled service as long as the "service console" (Service.msc) was closed.

It is annoying how having the GUI for service manager open, somehow stops me from reinstalling a service.

The Agile Maturity Model

2008-08-02T08:10:00.021-06:00

Note: This blog is a companion to the talk given by Ravi Gujral and Shaun Jayaraj at Agile Philly http://www.agilephilly.com/Agile%20Maturity%20Model.ashx

The best way to start describing the Agile Maturity Model (AMM) is by talking about what it is not.

The AMM is not

A mechanism to measure the performance of a team
A pre-defined set of practices, whose adoption guarantees successful delivery of projects in time and within a budget

The AMM, in contrast, tries to quantify degree of responsiveness of a team to an organization's business needs. The philosophy being that increasing the discipline and proficiency of executing some best practices will increase the degree of responsiveness. The AMM primarily focuses on application development activities; the dimensions of the AMM are

Testing
Source code management
Collective code ownership
Collaboration
Responsiveness to business
Assurance and governance
Story formation
Design simplicity
Build process

For each of the above dimensions, the AMM lists behavioral patterns exhibited by teams. Teams can use the AMM as a reference to identify and compare the behavior that they currently exhibit and plan to alter and tailor them.

For example the behaviors identified in the testing dimension are

Acceptance testing in lieu of all other tests
No unit testing framework, ad hoc testing (Manual testing of individual components /controls)
Unit testing, manual functional testing; application has a testable architecture
Unit testing integrated into build process, testing automated as much as reasonable given application
Developers write unit tests before writing functional code
Test are identified and produced as part of a story creation
Automated functional testing (e.g.. GUI testing); stories remain in development until all bugs are fixed or deferred

Consider a team that develops websites. Their testing strategy is to only have manual testers test the application just before deploying it to production. All the tests performed by the tester are acceptance tests. This would put this team on the level of "Acceptance testing in lieu of all other tests"

Using the AMM this team can then introspect and choose to introduce unit testing as a best practice.

The AMM Dimensions

Let us now look at the various dimensions of the AMM and the behavioral patterns that are identified within each dimension. The behavior listed at the start of each dimension is an undesirable behavior and teams should try and move away from them as soon as possible. However to what extent a team would like to mature in a given dimension is the team's choice.

The practices can be classified as

Regressive
Neutral or Chaotic
Collaborative
Operating (Consistent exhibition of competance)
Adaptive (Expertise to adapt to change)
Innovating (Creative evolution of practice, and spread these practices throughout the organization)

Testing

Acceptance testing in lieu of all other tests
No unit testing framework, ad hoc testing (Manual testing of individual components/ controls)
Unit testing, manual functional testing; application has a testable architecture
Unit testing integrated into build process, testing automated as much as reasonable given application
Developers write unit tests before writing functional code
Test are identified and produced as part of a story creation
Automated functional testing (e.g.. GUI testing); stories remain in development until all bugs are fixed or deferred

Source Code Management

Traditional schemes based on fire-locking and time-sharing
SCM supports version of code
IDE(s) integrate with SCM; developers include meaningful comments in commits
SCM support merging; optimistic check-ins
SCM support atomic commits
All development collateral is in SCM
SCM is transparent to delivery team, behind build process

Collective code ownership

Knowledge held by specific team members; people work in isolation
No pairing, people work alone, some informal process for keeping people informed
Pairing; no code locking
Pairing scheme ensures rotation
Team signs up for functionality rather than assignment to individuals
Within an sprint, functionality delivery is signed up for just in time
Old (bugs) and new functionality is queued, development team pops the stack in real time

Collaboration

Regular progress updates from management to the delivery team (as opposed to the other way around); irregular team meetings
Project collaboration tools (wiki, mailing list, IM) in place and used throughout project team; project status published and visible to all
Daily stand-ups and sprint meetings; problem solving is bottom-up as opposed to top-down; team sets sprint objectives and agrees on estimates.
Integrated, continuous build process, with build status notification to the team and collective responsibility for state of the build
Business is part of the team, stakeholders accept working software at reviews in lieu of other tracking or progress metrics
Frequent (near-real time) prioritization of old and new functionality
Build automatically deploys to QA environment available to any interested party

Responsiveness to business

Frozen specification, unresponsive to business value
Team tries to accommodate new requirements by ad hoc change requests ("pile it on")
Iterative process with sprints of length short enough to respond to business change
Showcases per sprint; business prioritizes functionality per sprint
Continuous involvement of the business on the team: business certifies story complete out of dev; involved in (rather than approval of) story definition and acceptance tests
Business writes high-level stories for all requests; organizational story queue exists; prioritization decisions made from full story backlog
Development process is integral to business initiatives; development teams work as a part of the business unit rather than as a service to the business unit

Assurance and Governance

Status reports document progress; schedule acts as plan
Concept of release planning is introduced
Sprint planning is introduced
Plan becomes communication and tracking tool rather than an exception report
Every sprint review examines value delivered and assesses next sprint by need, priorities (and delivery)
Organizational adoption: Introduction of Portfolio Planning and global optimization of resources (use of metric and standard measures)
Business review of value and return helps teams on regular basis based upon status

Story Formation (Requirements)

Development tasks extracted from voluminous, frozen requirements artifacts
Production of lightweight artifacts (e.g. panel flows) to drive high-level requirements development
Mapping granular requirements (e.g., use cases) in high level user requirements
Marshaling use cases into discreet statements of functionality that can be delivered in time boxed development sprints
Stories are an expression of end-to-end functionality to be developed, including testable acceptance criteria and a statements of value
Spontaneous story development provided by business for in-flight projects; stories not derived from extant sources but are immediate expressions of customer demand/need
Global repository of functional requirements for stories developed by business for any business requirements, including a formal measure of business value delivered

Simplicity

Big up-front design that attempts to accommodate all potential future needs
Application of fundamental design patterns
Structural refactoring to decouple application architecture
Doing only what needs to be done
Aggressive and constant refactoring to improve code quality/simplicity extant code
Spiking solution with each release to introduce new ideas and challenge architectural decision
Technical design decisions taken with each story

Build

Ad-hoc build requests; scripting and component marshalling performed manually
Consistent, repeatable build process with durable artifacts executed manually with each release
Build is automated, executed on a timed basis
Unit tests are integrated with the automated build; team is constantly notified of the status of the build; build triggered by SCM updates
Test and metrics (e.g., code quality, complexity, check style, etc.) are integrated as gatekeeper events; build data archived and reported in build portal/dashboard
All product components advertise dependencies; master repository established
Product integration tests included; build process executes automatic deployment to QA testing environment

Conclusion
We will be talking about the above AMM model during the Agile Philly and discussing the interconnections between the various dimensions.

Ackowledgements
Ross Pettit , Gerg Reiser, ThoughtWorks Inc.

Related Blogs and Articles

An "Agile Maturity Model?" by Ross Pettit http://www.agilejournal.com/component/option,com_magazine/func,show_article/id,44/
Agile made us better but we signed up for great By Ross Pettit http://agilemanager.blogspot.com/2008/06/agile-made-us-better-but-we-signed-up.html

User stories in the Enterprise Integration space

2008-05-13T08:34:00.016-06:00

In the 'user story' approach to requirements, it is considered a good practice to write your story's objective in the form "As a user I would like to perform some action so that I can get some business value/benefit. For example "As an insurance claims processor I would like to flag duplicate claims as 'duplicate' so that I don't process and pay for the claim more than once."

If you are developing software in your typical enterprise, soon or later you will come to a point where your application has to integrate with some external system. Writing user stories in such a scenario can be quite challenging.

Ideally the business should be able to assign some dollar amount to the business value called out in the 'so that" phrase. It is critical to call out the benefits of having the systems communicate with each other and share data.

Let us consider this example:
"As a user of system Foo I would like to create a new account and the new account creation message should be broadcast over a message queue."
The above story objective describes the implementation details and it does not call out the business value in this story. This is a poor objective for a user story.

An improvement will be to identify which systems will be consuming this message. Here is what the modified story would look like.
"As a new user of system Foo I would like to create a new account and the new account creation message should be broadcast over a message queue so that the SAP application can be informed of the new account."

This was slightly better than the earlier version, however it still isn't easy to associate a dollar amount to the 'so that' portion of the story title. To get to the business value in this story we need to look at what the SAP system does with the new account message.

Here is a final version of the story
"As new user of system Foo I would like to create a new account and inform the SAP system of the new account so that the SAP system can create a corresponding account for the user and bill the user for the services provided."

When you define integration stories in this manner, firstly it clarifies the business value obtained by implementing the story and it also makes it easier to test the application end to end. The other desirable side effect of this is to allow the business analyst to talk purely in terms of the expectations of the business and let the developers (who are more qualified than Business analysts when it comes to implementation) find optimal ways to make this integration work.

It could be argued that the architecture demands System Foo not be aware of the nature of the consuming application, and by calling SAP out by name we might tempt the developers to violate this requirement. Such details are important and need to be part of the acceptance criteria of the story.

Photo licensed under creative commons, photograph credited to Roger Smith

Stages of IT maturity

2007-05-09T21:59:00.000-06:00

In my last post I mentioned that every development decision should be tested against the question "Is this helping my customer?".

Last week I came across a project team that did just that. They had asked the customer what she/he wanted and built the system exactly to those specifications.

I was called in to do an IT assessment of the progress of this project and I soon realised that this project was an abysmal failure. But how could that be, here was a project that was built exactly to specification and was delivered more or less on time.

The problem was that the project team built a system, based on what the business users wanted without considering if there is any business value in it. The business users were line managers and clerks and they had a very limited view of what the business was about, and how their day to day actions affected the top line/ bottom line performance of the company. So this resulted in a very narrow view of the requirements, and sure enough when the system went live it did not deliver as much value as top management expected it would.

So how does one get past a problem like this ? Here is where stories play a very crucial role, and the importance of the "As a role I would like to do some action so that I achieve some business value" format.

Some people feel that we are being pedantic if we insist on every story adhering to this format. But if the team had stuck to this format, they would have realised early in the game that the requirements being given to them were probably not adding any business value. This visibility would have allowed upper management to terminate the project early and reevaluate their strategy.

The other aspect to this problem is the maturity of an organization to consume a custom built software. For custom built software it is critical for the users to be able to clearly articulate the need of the business. They should be able to tie every requirement to the bottom line or top line performance of the company. This implicitly means that the business users have exhausted all means to improve performance by business process modifications. Only in such a situation should the business consider using technology to get them that extra bit of competitive advantage.

In my opinion the IT maturity of an organization is closely linked with the business maturity. I can think of four stages of IT maturity an organization can be in.

Chaotic tactical business processes (use of spread sheets and multiple point solution)
Business processes which provide accurate and up to date information to the upper management to make decisions. But the processes themselves don't adhere to a overarching strategy
Business processes tied to a strategy that is clearly articulated by the upper management
Business processes which are flexible and can easily shift and align themselves to the subtle strategy changes being employed by the upper management

To get to the Nirvana state of business, it is important for information systems to support them

Stage 1: To start with you have a bunch of spread sheets and custom point solutions spread out through the organization

Stage 2: Fewer spread sheets and some central solution which can provide some business intelligence

Stage 3: Collection of commercial off the shelf (COTS) best of breed solutions integrated with glue code

Stage 4: Collection of COTS as well as custom solutions in areas which give the organization a competitive advantage integrated with glue code

Pros and cons of each stage
Stage 1
Pros: Relatively easy to stand up spread sheets for your day to day work.

Cons: Virtually impossible to get any sort of business intelligence at an over all enterprise level

Stage 2
Pros: Easy to obtain business intelligence

Cons: If the team supporting the central application is small, they become the bottleneck.
The whole enterprise will over time become overly dependent on a small group of people who control the application.
The single application is critical to the functioning of the organization, this reduces the number of upgrades and changes that you can make to the application. Over time the application become out dated and crufty.

Stage 3
Pros: Allows flexibility
Can get the best of breed for each individual functional area

Cons : Can't get competitive advantage from such a solution (if you can glue together off the shelf products, then so can your competitor)
Will have greater IT spend because the skill level required to maintain this kind of an architecture is quite high

Stage 4
Pros: Competitive advantage

Cons: Increased IT spend

Responsible Developers: Does IBatis help my customer?

2007-04-29T12:48:00.000-06:00

Agile (especially the XP flavor) empowers developers a great deal. Being an ex developer turned IM, I am starting to see that this is a double edged sword. It is dangerous to empower incompetent developers.
Incompetence can come in various flavors, You have your garden variety junior developer, who just wants to get his 40 hours in. Or the grand and wise 'architect' who wants to build a unified framework, which will encompass all knowledge. Finally you get the super dev, who wants to do everything his way, because his way is the coolest.
In an agile team, one of the most important characteristic expected from a developer is responsibility.
Responsibility towards his customer, every decision (which build tool to use, which persistence framework to use, which database to use, MVC or just write to the DB directly) taken by the development team, should have been tested against the question "How does this help my customer"?