Even in the small organisation like us things move at a slower pace so the idea of having a blog disappeared like many other great ideas our team comes up with every week, because implementing an idea is hard. Recently Narinder, Vikas and Sandeep showed renewed interest in setting up a blog site for Xebia India. So quickly a word press theme was developed and a technical infrastructure is created to host the blog site.

We invited suggestions for an appropriate blog name. We liked the name Xebee because it has Xe from Xebia in it. We found bee metaphor suited to the idea of knowledge accumulation, all the Xebia India people will contribute to, on the blog site.

So we have Xebia India blog Xebee finally live but it is not the final version because it will go through the cycles of refinement endlessly. Initial response is overwhelming. People are blogging like crazy.

This week Shrikant is conducting a blog writing workshop to engage all Xebia India people in blog writing who have not done so far.

Please visit us on:
http://xebee.xebia.in

In early 90’s, I was subcontracting for EDS Unigraphics, now known as NX, a leading vendor of CAD and PLM software. In that time all the EDS Unigraphics customers submitted features requests to Product management by e-mails or forms. Voting in user meetings, which took place probably 2-3 times per year, the most desirable features were selected and built. Unigraphics was a thick client software that worked on high end workstations from the companies such as Silicon Graphics, HP, IBM and Sun. It was unthinkable to deliver the application and collect the feedback rapidly because these “high-end workstations” were incapable or too slow to communicate with the computers outside intranets.

The competitive advantage in software product business can come when you know what your customers want or sometime even who your customers could be. This advantage can come in two forms. One how rapidly you know what your customers want and how unique this knowledge is. A simple example – everybody knows that computer users want web based e-mail but in 1995, it was a unique knowledge. In most software product companies, a big part of budget allocation goes in engineering (as they call it in Silicon Valley) or software development. Similar situation is encountered in the e-commerce companies who spend considerable part of their budgets on big software development teams. Typically for every 1 Eur spent in customer discovery and learning, software product companies spend 4 Eur in product development. Please put a remark in my blog if you have seen a spending pattern in an European software product company largely in the favour of customer discovery and learning.

Recently a CTO of a Dutch software product company told me that you can improve a software product for years without selling a single copy. Having a big team of software developers in a software product company would automatically ensure that your investment in customer discovery in disproportionately low as compared to your investment in software development team. When you do not know what your customers want or who your customers are, then you will not be able to sell. You will keep wondering when your product is so feature rich and you have a great engineering team and why you do not sell.

A smart way to reduce the focus upon engineering in European software product development companies is to outsource software development. However, the outsourced software development team must be an integral part of your knowledge sharing ecosystem which is the great advantage (and probably the only one) of in-house software development teams.

In US they talk about maximizing customer learning for every dollar spent. Popular American blogger and lean startup guru, Eric Ries mentions a company that attempted to validate their vision with customers without even writing a single line of code.

With ubiquitous open source and availability of programming skills all over the world, European software vendors can realign their Euro spending towards customer discovery and learning. This will enable them to compete in the rapid changing world to face ever increasing domination of American software product companies. Remember that iPhone is Designed by Apple in California but Assembled in China.

At the expo Twitter was hot and so were the social networking or the social effects of web 2.0 to drive economy and business. Power of less was the new phrase in vogue which also reflected the mood of participants hearing the news of US jobs losses real time as this four day long event progressed.

Making web work to search local information could be a new mantra to help people who are seeking local information such as price of a watch in nearby stores. As mobile internet becomes more popular, these searches can influence consumers’ behavior when he is looking for a product in the high street. For example, consider Google search where it figures out a possible local context from a search term and displays the local results on the top. Nokia hinted at making location aware mobile devices integrated with smart camera phones that can take advantage of internet to pull the information about a landmark from Wikipedia that you are trying to shoot.

Probably every participant in the Expo was using Twitter or Facebook. Alex Payne of Twitter explained why they have chosen Scala to solve scalability problem in their backend queuing system. He said because of Scala they have an API test suite that helps them sleep.

User Interaction design grabbed good attention during a demo of Adobe Flex Catalyst in a keynote session that demonstrated how graphic design can be converted in to a Flex application with some cool transition effects using Catalyst. An interesting session was on user experience and software development Can’t We Just All Get Along? Human-centered Design Meets Agile Development by Maria Giudice who moderated a panel of four other people having software development and user experience design background. The panel covered the challenges in combining the short iterative nature of Agile projects with creative user experience design activity that creates conflict.

As the funding for new ventures dries up there is a remarkable increased in Agile awareness and adoption in the Web 2.0 community. Eric Ries, who is a popular author and speaker and publishes a blog titled Start up Lessons Learned, delivered a talk titled Lean Startup. In a jam packed hall, he suggested that a lean startup company should quickly iterate from ideas to code to data collection. Eric Ries ideas encapsulate various Agile practices in an iterative cycle and provide an overall big picture that many popular Agile methodologies seem to be lacking.

Some of the key take aways from this events are as follows:
1. Agile is at the point of becoming mainstream way of software development
2. Mobile Internet and Geo Location APIs will drive application development in coming years
3. User experience and new ways of Human Computer Interaction will drive application development as demonstrated by Wii and iPhone
4. Value of social network grows geometrically as number of users increase
5. Web 2.0 technologies are making their inroads behind Enterprise firewall
6. Public API makes integrating content easier which amplifies the network effect of a social platform

Adobe Systems, IBM, Salesforce.com, Nokia and Microsoft were the major vendors who participated in this event as exhibitors.

Keynote presentations including very inspiring lectures from Tim O’Reilly and John Maeda are available on blip.tv.

Source: Agile Advice

Agile project rooms should be organized in such a way that when you walk inside by looking at few charts you should be able to know how a project is going. Alistair Cockburn has called these charts information radiators. By the use of word radiator, Alistair means that your information display should be simple enough to be understood without requiring special skills in data interpretation. Information radiators should be updated several times a day.

A key point that we have to appreciate that various stakeholders need information about the project. The depth of required information and its frequency varies according to stakeholder’s role in a project. Project Managers need more and frequent information because they have to manage budget, customer relationship and team expectations among other factors.

In real world I see that Agile teams do not appreciate the importance of recognizing the correct information radiators and displaying them. A lack of Information radiators in a team room leads to continuous status checking by managers and stakeholders by walking in to the project room several times a day and asking team about the project status. Team members resent this micro management practice and fail to understand that despite of working hard and very focused, they have to answer several times a day how a project is going.

A plausible excuse, among the team members, for having no information radiators on the walls is that we have all the information in a wiki or in a tool X. While it seems reasonable from the team’s point of view, wiki and tool X do not ‘radiate’ information. Project Information should be visible with ‘naked eyes’. This is where charts on wall or white board can help. A good use of white boards and sticky notes, makes information easily visible. A drawback of such information radiators is that the displayed information is not backed-up and not visible to all the team members if a team is geographically distributed. A possible solution to these problem is making photos of information once per day using a digital camera for back up and maintaining information on Wiki to share with geographically distributed teams.

There is no doubt that Wikis and other tools make management of project information simpler which would have been cumbersome with whiteboards and sticky notes. Displaying all the information on walls can be cumbersome and not effective. Team should identify a subset of information radiators that convey the information stakeholders need. Normally for an Agile project team 2 or 3 information radiators would be sufficient. For example, two most commonly used information radiators by the teams at Xebia India are burn down chart and task board. Team can also display the sprint risks prominently in the project room.

I recommend selecting couple of information radiators during the project start up in collaboration with the stakeholders who need to know about the project progress frequently. A typical examples of the stakeholders include roles such as Product Owner, Project Manager and Head of Software Development. Put the selected information radiators on a wall of project room and update them regularly. After few sprints evaluate if your information radiators serve their purpose or you need to change them.

Before I write about 11 tips to make a Distributed Agile project successful, I would like to start with Tip #0.

Tip #0: You should have technically bright people in the team. This is a prerequisite to make a Distributed Agile Offshore project successful. My other tips will not make technically dull programmers deliver a successful project.

Tip #1: Involve offshore team early in the project

By early I mean start with offshore team members when you are setting up your development environment or doing brainstorm on project vision and technical design. You can start with a small offshore team of 2 persons who can travel to your location.

Tip #2: Minimum 6 weeks collocation during project startup

Make sure that the onsite and offshore teams sit together in the same room for 2 to 3 sprints before the offshore team goes back to the distributed location.

Tip #3: Work hard towards creating one team feeling

Remember that offshore team may be not familiar with your work culture, language and team members. Spend few social evenings together with onsite and offshore team members to create one team feeling. Share lunch table and jokes with all team members.

Tip #4: Integrate project mail distribution list

All communications relevant to the project team members should go to every member of onsite and offshore team. It can be good news, bad news or simple updates. After all offshore and onsite team is aiming for the same goal and vision.

Tip #5: Explain the business value and vision about the project

Offshore team members should understand the business value and the vision of the project for which they have travelled onsite. If you are long involved in the project, it may seem obvious to you but for offshore team members it is valuable information.

Tip #6: Feedback from other stakeholders

When you engage offshore team, the feedback from various project stakeholders who are not part of the development team should also be communicated to the offshore. The other stakeholders could be higher management, marketing people or end users who might not be visible to your offshore team members.

Tip #7: Honest and direct bi-directional feedback

No feedback to offshore team is worse than the bad feedback. You might not be comfortable discussing the difficult matters with an offshore team member because he/she is new to you. However, you should make a conscious effort so that the onsite and offshore team members are able to deliver constructive criticism without being shy to each other.

Tip #8: Provide the same development environment to onsite and offshore teams

A stable and powerful development environment improves developers’ productivity. Make sure that the offshore team has good hardware and working tools so that they can focus upon the project work.

Tip #9: Simulate distributed team for one week

When both teams are collocated simulate a distributed environment for one week. You can move offshore team to another building and let communication go only using phone and video conferencing. Review the experiences jointly when the simulation week is over.

Tip #10: Keep the one team feeling alive when your offshore team is back to their country

You have worked hard for 6 weeks to create one team feeling. When the offshore team goes back, the onsite and offsite teams will not meet frequently as before.
Plan a collocation at the interval of 3-4 months when 2 members of a team can travel to other location for 2-3 weeks. You can also keep a live video connection in the team working areas at onsite and offshore locations so the teams can see each other and remain connected.

Here are 11 tips that will ensure early death of a Distributed Agile project:

[Though this blog has been written in negative tone, the objective is to make people working with offshore teams aware that they can contribute to the success by avoiding some common mistakes. It does not reflect practices observed in a particular project. It is just a collection of various observations that contributed to making offshore projects less successful. Please feel free to add more.]

See the positive spin on this list here

1. Involve offshore team in the project after couple of sprints once onsite team has understood the project vision, road map and made key technical choices.

2. After the involvement of offshore team, keep making all important design decisions with your small onsite team. Frequently communicate about when the offshore team makes mistakes because of lack of communication from your side about important design decisions.

3. Keep offshore team very small i.e. 2 persons or less. Keep onsite team at least 3 times bigger than the offshore team so that the real action can take place only onsite.

4. Blame every problem in a project which could be due to wrong specifications, technical debt, broken builds and wrong technical choices, on offshore team. You will be surprised to see how easy it is to convince your stakeholders that these problems are caused by working with a Distributed Agile Offshore team.

5. Never give honest feedback in the project retrospectives. Keep telling Agile Offshore team that they are doing pretty well so that their drive to improve their productivity and quality remains low.

6. Avoid collocation with offshore team at any cost. Keep offshore team always at a distance from the product owner, onsite developers, testers and other stakeholders as much as possible. You can use high travel cost as a good argument against travel which your manager will accept at ease.

7. Despite of your efforts if your collocation takes place then make sure that no onsite team members pair programs with offshore team member. If possible arrange separate desks for offshore team members.

8. In a sprint ask offshore team to handle simple tasks that nobody onsite would like to do. Grab the challenging user stories during the sprint planning for onsite team.

9. Keep refactoring the code during the weekends and in the evenings with very little communication about it with the offshore team.

10. Re-write a significant part of code delivered by the offshore team with out any communication to the offshore team. Tell your manager that you are too busy because of some problems in the code of offshore team that require urgent attention before a release can be made.

11. Never let offshore team fix the coding problems created by them. Do it yourself and communicate frequently about it to your onsite stakeholders.

Another interesting possibility that this model will offer is the optimization of the utilization of knowledge workers while making a distinction among star performers and commodity workers. The model would take into account that star performers would get bored easily and it will treat them gently because they can earn more profits for the company in short bursts of interesting work. The model would make sure that the commodity workers work up to 100% of their time since they make little profit for the company. If the Business Week article is to be believed then such indistinguishable workers are going to be found in India or Uruguay.

While such development might seem scary, finally the knowledge workers will have the power to know their worth because the model will be able to crunch all the data about a knowledge worker and display a NASDAQ like number that will be the his/her worth. This is a reason for middle managers to be happy about because they can finally abolish illogical yearly appraisal systems. At last middle managers will be able to attach some logical explanations to the salary hike of a knowledge worker.

Remember that about 20 years ago Peter F. Drucker predicted the death of middle management in the new organization. With sophisticated models in place, the new organization will be able to automate middle management tasks such as appraisals, team formation, skill matching and wage hikes. If you are not likely to get retired in next twenty years in IBM then it will make more sense for you to become a star performer specialist than a commodity worker or a middle manager. Other IT companies might follow the similar trend where the middle management would become redundant.

On 28th August, I am sipping coffee in the foyer of hall where this mega event will take place. Around 400 to 500 people have packed themselves in a somewhat crowded but comfortable place. It is easy to make out from the looks that the Wizcraft girls are handling the registration process. This event is simultaneously taking place in Delhi, Bangalore, Trivandrum, Pune, Hyderabad and Kolkata. We will soon see a live telecast of keynote address from Bangalore.

The event starts with African drum performance in which the audience from all the cities joins by beating color plastic tubes on their palms at different intervals to create a rhythm.

After this exciting energy generating event, we get to see a long boring boardroom style presentation from Steve Mills that boasts about IBM software tools revenue of 1.8 b US$. From here onwards Hyatt and Wizcraft start making sense and my hopes of hearing about some exciting new stuff from the oldest surviving elephant of IT industry slowly fed.

IBM has more distributed software teams than any other company in the world as the heavily dotted slide showing world map confirms. IBM has 3400 employees in India, out of its 33000 strong workforce, working on developing Rational suite of tools that includes products like Rational Clearcase and Rational Method Composer etc..

IBM is the only IT giant which has successfully survived in each decade since 60’s by foreseeing the future and reshaping its strategy accordingly. Whether it’s transition to services business in early 90’s or setting up of Eclipse organization that has created an open source platform which has become the basic infrastructure in application development, IBM has reinvented itself. Given IBM’s ability to see the future and adapt, we can say that the Agile is on the path to become mainstream way of developing software.

As Steve Mills from IBM said that the new software development is going to be about Ship early, Ship often and listen to the customers. IBM, as a tools company, will help its customers with Governance, Architecture and forming a Collaborative Community. IBM still believes that Waterfall, Iterative and Agile will continue to coexist. You might take this seriously since it is coming from a company that still maintains mainframe systems from 60’s and 70’s.

IBM earns a great deal of tools revenue from big corporations that struggle with scaling Agile. Proliferation of open source tools and mix and match approach of early Agile developers might be a big headache for the large corporations since they fear losing control. In such places, the integrated tools approach of IBM can provide better governance at the cost of lesser creativity and innovation which is the driving force of Agile community. A large population of ‘commodity developers’ does not care if somebody has drawn a box in which they have to operate. More about ‘commodity developers’ in my future blogs.

The event has overtones of corporate marketing event which was sold as the biggest IBM developer conference only next to the IBM developer conference in Orlando. It was not inspiring to see that IBM decided to fly in heavily jet lagged and tired blue suited speakers from Australia and Europe who hardly went beyond reading their slides. I wonder why IBM could not find speakers among its 50000 strong workforce in India to fill first 5 hours of conference. We would have appreciated to get the conference program in advance or at least in the beginning and it would have spared us some confusion by the printed agenda by Wizcraft that wrongly showed breakout sessions starting at 3:00 PM and finishing at 3:30 PM.

While carrying my ‘free’ IBM Rational bag to my car after aborting my IBM day just after lunch, I am convinced that the web remains the best medium to learn more about what is happening at IBM. I am headed back to Xebia office in Gurgaon to see an evening session on software audit.

We discussed the need for having good people in Agile Teams to make Agile work. On this point, Mary confirmed the well established belief in HR circles – Hire for Attitude and Train for Skills. I feel while HR circles and many experienced people know this already; it is practiced rarely because of our desire for having people with right skills and experience to get going quickly. Attitude is hard to measure especially for the people with technical background or the business managers.

While taking a round tour of our new office and admiring how we have setup Agile workspaces that enable collaboration and trust building in the Agile Teams, Mary asked why there were no information radiators in the project rooms. Finally she found one in a team room. I explained that the most information radiators are on Wiki since we work distributed but we want to have information radiators displayed at a central location in the office on LCD screens. It is a work in progress.

Mary said that Xebia is well positioned at least in few projects to analyze the whole value chain of the customer and Xebia should make effective use of that possibility. This discussion initiated when we said as a service company we deal with new domains regularly where business aspects of a problem may not be clear to us. As an outsourcing company we might not have enough leverage in looking in to the business aspects of a project because of our lack of access to experts for business or political reasons. Mary’s view is a confirmation of our belief that a captive offshore team having direct contact with the customer can deliver the best value. This also forced me to think about my earlier blog on business value delivery with Agile. An agile team can comment on business value if they understand the domain and they have access to right business people or else just say that you are delivering good software using Agile.

An interesting discussion was how we measure our success in IT services business, to which Mary and Tom pointed out if your existing customers will recommend you to others then you are really successful. At the same time, Mary emphasized the importance of choosing right type of customers before starting a new engagement.

Team dysfunctions could be the worst nightmares for the managers of Agile team. While SCRUM emphasizes the need for self organizing team, we found that team dysfunctions do not get recognized and corrected by the team in the early stages. Mary’s suggested that the Line Management should take care of such issues since it is not realistic to expect that the team will solve such problems. My next XKE presentation on 9th July is about Trust which is foundational to build great teams.

Around 6 days of preparation went in to the Poppendieck’s visit. We formed a group of six people known as Poppendieck Study Group (PSG). Everyday between 6:00 PM to 7:00 PM, this group presented a topic from the Poppendieck’s book titled Lean Software Development: An Agile Toolkit. It was a good group learning exercise that prepared us well for their visit.

Mary and Tom received bottles of Indian wine as a souvenir from Xebia India, had a group photo with fellow Xebians and left next day for Singapore.

I felt that the original work done by Mary and Tom had a great impact upon the core values and business philosophy of Xebia. Xebia India team will be looking forward to share and test our Agile experience with them if the opportunity comes again.

Anurag

Business value: Difficult to measure

The business value of software is not a well defined term. Business case for software development is often poorly constructed and involves some elements of guess work that makes measurement of business value hard even when the software has been delivered and gone live. A good indicator of the early delivery of business value could be, how quickly customer can earn back the investments made in the software development. Though this is done rarely and almost never when a project is yet to start, Agilist wrongly preach customers and the software development teams that delivering good quality working software and delivering business value is the same thing.

Limited success of Waterfall

Agile movement has its foundations in solving the decades old problem of limited success of waterfall methodologies. In waterfall projects, software development teams encountered steady stream of requirement change and invited criticism for the late delivery of software. Software development teams were also blamed for poor engineering of software leading to surfacing of bugs and performance problems when the software was put in to production. Should we now over promise and set expectations about business value?

Software professionals are not business experts

It is hard to find good business experts among software development professionals except for few gifted people who can boast of having expertise both in software development and business domain. Professionals, especially those in software services industry, work on software development assignments in several business domains in a year. This job rotation leaves professional little time to invest in mastering the business of a customer and understand the business value of software in depth.

During pre Agile days, the software developers and architects interfaced with the business experts through business analysts. Notwithstanding the various efforts to simplify the communication between business and software developers, software community did not succeed in eliminating the person who sits between the business and the technology. In Agile methodologies, such as Scrum, the Product Owner, masks development team against the detailed discussion taking place during the discovery and the prioritization of the business requirements.

Agile methodologies claiming to deliver business value early put Agile software development teams in a difficult situation to deliver something, which they at their best have limited understanding of and are unqualified to measure. As a matter of fact, customers never expected software development teams to deliver business value and never blamed them for failure to do so. Of course, customers always and rightly expected development teams to deliver good quality working software on time. Agile methodologies have demonstrated their superiority over waterfall methodologies in delivering good quality software and therefore Agile methodologies can lead to higher customer satisfaction.

Business value of a waterfall product

The business value of software has been difficult to measure even for business experts let alone software development team whether using agile or waterfall methodology. The choice of a methodology will insignificantly impact the delivery of business value.

Few years back I came across a VAX Basic application at a retail chain which was in use for almost ten years. Daily sales figures from different stores were consolidated using the batch processing capabilities of the VAX Basic script. In terms of its usefulness, not only this VAX Basic application had paid back several times the amount invested in its development, it also withstood the challenges posed by business growth in past ten years. Though this application was written poorly and gradually became difficult to maintain due to the scarce VAX Basic skills, it was extremely valuable for business since a critical part of the business remained happily dependent upon it for several years. After a long wait of ten years, we can credit the programmer and the methodology used by him, for delivering the best business value.

Deliver good software on time and nothing more

Now the question comes why Agilists claim that Agile can deliver business value early despite of the fact that the customers never expected software development teams to do so and the software development teams are rarely capable of understanding the business value of software. The answers lie partly in the fact that the word Agile is being used increasingly in the sales pitch where there is a tendency to overpromise and partly in the poor definition of the word business value. Poor definition of business value can set expectations that might be open to free interpretation.

Business value of software can only be measured by business people who understand the business problem that is being solved using software. Many times the business value of software can not be measured in advance. Agilist claim that they can deliver business value early while in reality at its best the Agile methodologies can deliver working software early.

Conclusion

I would like to conclude by saying that the Agile Methodologies should not claim that any Agile software development process will deliver business value early, because it creates unrealistic expectations about the performance of software development teams. Agile methodologies should emphasize the timely delivery of quality software, shorter feedback cycles and room to accommodate change. Sales people can highlight the elimination of wasteful features by customer feedback and short delivery cycles, as strong points favoring Agile. These arguments are compelling enough for the customers to choose an Agile methodology for software development. In the early delivery of business value, timely delivery of quality software plays a role but timely delivery of quality software is hardly sufficient to deliver the business value early.