Subscribe: What to do? we are like this only
Added By: Feedage Forager Feedage Grade B rated
Language: English
agility  built  business  development  feature  new account  new  product  project  software  story  system  team  testing  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: What to do? we are like this only

Observations on software delivery

Observations on Agile practices

Updated: 2017-11-03T06:59:02.942-06:00


Agility in the Time of Turbulence


The age of turbulence is upon usThe telegraph took about 100 years to reach one billion users. SMS took about 20 years to achieve the same number. WhatsApp took just about 2 years to get to one billion users.In 1958, the average years a company stayed in the Standard and Poor’s 500 list was 61 years. In 1980, it was down to 25 years, and by 2004, it was 18 years. Now, a company enters or exits the list every 2 weeks. 75% will be replaced within 15 years1.The world’s economy is characterized by rapid and unpredictable change. In this fast changing world, it has become extremely difficult for product owners to foresee and predict what needs to be built. This uncertainty and change is both a curse and a boon. Any organization that can adapt quickly to leverage a new evolving ecosystem will gain from such volatile behavior, as opposed to an organization that is unable to react to the changes and keep up with the times. As Theodore Roosevelt said, “In any moment of decision, the best thing you can do is the right thing and the next best thing is the wrong thing. The worst thing you can do is nothing.”The need of the hour: To move from a Factory to a LaboratoryIn the past decade, IT projects have worked in a factory mode, where products were designed and built using an assembly-line-like structure where once the product was considered complete, it was released into production. Changes to such applications were then termed as regular maintenance and kept to a minimum.However, with increasing market flux, that had to change. The only way to really tell how your product meets market demands is to build the product, release it to the consumers, and react to the feedback that they provide. And Agile stepped in with practices such as continuous delivery, iterative development, automated testing, customer collaboration, etc., to give product owners that responsive edge.While working on a project for a startup out of Singapore, we were faced with an interesting problem. We wanted to build a mobile application for the Indonesian market, but we were unsure about the usage patterns of this application. We conducted the usual workshops to identify the features and we then put analytics in place to indicate the usefulness of a feature. We built a system that could push out new ideas and code into production at the click of a button. We put in mechanisms to do A-B testing and measure the effectiveness of our feature set.  Given our limited knowledge of the market, this was the fastest way to reach our stable feature set.With the age of turbulence upon us, every enterprise large or small will probably have to move from using their IT departments as Factories to churn out software to Laboratories where novel ideas and concepts are developed, tested and produced at a fast pace.This would require Agility to go beyond IT departments and businesses to be open to change and failure. This calls for Business Agility.From Project Agility to Business AgilityProject Agility : Scrum and XP engineering practicesEnterprise Agility: Project Agility + DevOps and continuous DeliveryBusiness Agility: Project Agility + Enterprise Agility + Working closely with IT to design and execute experiments. Change business direction based on new knowledge.To summarize, while Project agility and Enterprise agility are necessary conditions,  it is Business agility that will prove paramount to thrive and adapt in the turbulent future.[...]

Ten things to keep in mind when distributing your development team


Many small and medium enterprises the world over are looking to offshore to help reduce cost of software development and also have access to a larger talent pool. Though the strategy is in the right direction, the blueprint applied may be a little flawed. There are two myths prevailing in the decision to offshore.Myth 1:  A Developer's productivity offshore is equal to a Developer's productivity onshoreThis myth forgets that software development relies very heavily on effective communication of requirements between the business and the software developer. Once there is a distance (either in space or time) between these two parties, inefficiencies creep into the system, and automatically, these inefficiencies manifest themselves in the form of lower productivity when working offshore as opposed to onshore closer to the client. There needs to be a systematic set of processes / practices and team structures in place to mitigate this problem and ensure that both teams are equally productive.Myth 2: Coding can be offshored while Project Management, Analysis and Testing should remain onshore (Brains-onshore-bodies-offshore model)This myth does not take into consideration that software development is fundamentally a team sport with a lot of collaboration between the various skills. Every time a work item has to be passed across different silos, the time to turn around the work becomes longer.  Also, micromanaging a team of coders in a remote location, who have no context of the requirements or the environment is a nightmare. This sort of modelling almost always ends in disaster. Ideal and current state of distributed teams   Let's look at what any IT manager would like in an ideal project (onshore or offshore): Have a clear understanding, on a daily basis,  of where the team is currently as per the project planHave confidence that what has been completed has been completed with the necessary quality and will require no reworkIf there are any risks to the project plan, these risks are highlighted long enough in advance to allow the manager to put in mitigating actions However, when companies offshore, some of the issues most of them face are:Lack of transparency of what is being built and if it is being built correctly. The team is in a different location and most probably in a different timezone and sometimes cultural differences introduce all sorts of miscommunications. Missing deadlines. The dreaded,  "We are almost there, 90% complete" only to get the work product  which is not even 10% done. Some offshore teams hate to disappoint people so they tend to keep a facade of success, hoping that the project will course correct. Most of the time this doesn't happen, leading to the "Project is Green, Green, Green, RED" situation.When desired outcomes are not achieved, most people react by trying to break down goals into smaller tasks and then trying to micro-manage the completion of these tasks. This  is usually not sustainable and the overhead of doing this is so high that it negates the value of offshoring. In most cases, it leads to extreme frustration on both ends.Having lower spend, but getting poor or sometimes no results at all.  Starting distributed teamsIn my mind, the top 10 things to keep in mind when starting off on a distributed Agile journey are:1. Meet the team: It is important to meet the team in their team environment and judge if they have the right skill level, and experience mix, and the team dynamics are something you are comfortable with. 2. The onsite/offshore co-ordinator: When you are working with a remote team, trust is everything. To get things kicked off, it makes sense to have a person from the offshore team work onshore. This person could hold any role:  PM, BA, Dev, or QA. The primary role of this person is to work closely with the remote team and be a liaison between the onshore team and the offshore team and make sure communication lines are up and clear.3. Short iteration cycles: Try your best to not have iterations [...]

Product development - Needs versus Wants


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



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

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.

Is QA incented to release software in the traditional development model


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


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


Note: This blog is a companion to the talk given by Ravi Gujral and Shaun Jayaraj at Agile Philly best way to start describing the Agile Maturity Model (AMM) is by talking about what it is not.The AMM is notA mechanism to measure the performance of a teamA pre-defined set of practices, whose adoption guarantees successful delivery of projects in time and within a budgetThe 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 areTestingSource code managementCollective code ownershipCollaborationResponsiveness to businessAssurance and governanceStory formationDesign simplicityBuild processFor 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 areAcceptance testing in lieu of all other testsNo unit testing framework, ad hoc testing (Manual testing of individual components /controls)Unit testing, manual functional testing; application has a testable architectureUnit testing integrated into build process, testing automated as much as reasonable given applicationDevelopers write unit tests before writing functional codeTest are identified and produced as part of a story creationAutomated 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 asRegressiveNeutral or Chaotic CollaborativeOperating (Consistent exhibition of competance)Adaptive (Expertise to adapt to change)Innovating (Creative evolution of practice, and spread these practices throughout the organization)TestingAcceptance testing in lieu of all other testsNo unit testing framework, ad hoc testing (Manual testing of individual components/ controls)Unit testing, manual functional testing; application has a testable architectureUnit testing integrated into build process, testing automated as much as reasonable given applicationDevelopers write unit tests before writing functional codeTest are identified and produced as part of a story creationAutomated functional testing (e.g.. GUI testing); stories remain in development until all bugs are fixed or deferredSource Code ManagementTraditional schemes based on fire-locking and time-sharingSCM supports version of codeIDE(s) integrate with SCM; developers include meaningful comments in commitsSCM support merging; optimistic check-insSCM support atomic commitsAll development collateral is in SCMSCM is transparent to delivery team, behind build processCollective code ownershipKnowledge held by specific team members; people work in isolationNo pairing, people work alone, some informal process for keeping people informedPairing; no code lo[...]

User stories in the Enterprise Integration space


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


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 strategyBusiness processes tied to a strategy that is clearly articulated by the upper managementBusiness processes which are flexible and can easily shift and align themselves to the subtle strategy changes being employed by the upper managementTo get to the Nirvana state of business, it is important for information systems to support themStage 1: To start with you have a bunch of spread sheets and custom point solutions spread out through the organizationStage 2: Fewer spread sheets and some central solution which can provide some business intelligenceStage 3: Collection of commercial off the shelf (COTS) best of breed solutions integrated with glue codeStage 4: Collection of COTS as well as custom solutions in areas which give the organization a competitive advantage integrated with glue codePros and cons of each stageStage 1Pros: 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 levelStage 2Pros: Easy to obtain business intelligenceCons: If the team supporting the central application is small, they become the bottleneck. The whole enterprise will over time become overly dependent [...]

Responsible Developers: Does IBatis help my customer?


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"?