Analyze on Software Not on Paper

Let's visit a very common conversation that I have often been involved in or heard of: Q: What's the difference between Waterfall and Agile? A: Agile doesn't involve the upfront analysis that Waterfall plans and invests in. This is probably the first thing you hear in terms of differences between Agile and Waterfall. The follow-up question usually is, "How can you do software development without any analysis?" It starts the classic dialog that a lot of agilists repeatedly have. The Luck Factor How can we really deliver business value without 'proper' analysis? We may be able to deliver some, but it'd just be a matter of luck. That's exactly the inspiration to invest in upfront analysis; eliminate the factor of luck. The temptation to know it all and plan everything is just too much. Sometimes, before you even realize someone reminds you that your planning and analysis is starting to look like Waterfall. Not planning, I think, is wrong. Not analyzing is a blasphemy. You are wasting money and time if you are not planning and analyzing. But if its all on paper, powerpoint or visio and planning your software to the Nth possibility you are most likely about to run into a lot of potential waste. Release Zero The solution to this paradox is to have a release of whatever you are tyring to build as soon as possible. Get that extra-lean yet functional piece of software out to your small test-user base ASAP. A colleague of mine termed it 'Release Zero'. In addition to a lot of usability feedback, this would provide your analysts a working system that they can analyze. Scenarios, situations, dead ends, etc. that I as an analyst have come across in actual working software could never ever have been thought of if I were to design theses flows in detailed functional requirement documents and system design documents. The stretch of imagination needed to design a good system on paper becomes so thin and flaky that it starts to consume extraordinary amounts of energy and time to make them useful. So, do just enough, think only so much ahead in time. Before you proceed any further on that theoretical trajectory, get it built. Do your analysis on this release and iterate further. Example Imagine designing a content management and publishing system where a user should be able to:
  • Create article, etc.
  • Publish, revise, republish articles.
  • Rate and comment on articles.
  • Search on articles
  • Provide sneak peak into some work-in-progress articles to readers.
  • Workflow between writers and editors.

This can prove out to be a very complex system to design if we introduce the concept of user groups. i.e. a group of Writers, Admins, etc. in addition to the Readers. Now let's say there's another user group in it called Classified. And let's say that this is a group of users that writes very sensitive information that shouldn't be leaked to the rest of the publishing house and certainly not to the readers before the due date. Imagine how complex the analysis can get. Content should be available to a certain group for editing before the publishing date, but to others after it has been published. Search should not return classified material or should return only parts of it to some readers. Internal editorial comments should not be visible to the readers and/or vice-versa. As an analyst this product would be a big challenge. As I said earlier, my analysis will start becoming flaky beyond a certain functional depth. Decision on functional aspects will start taking long time because product owners, designers, and developers will have very little common understanding. Hypothetical and imaginary usage scenarios will start to consume time. In this situation I'd recommend to start development with a simple model in place. Two user groups - editors and readers, simple search, and basic data privacy and security in place. Once I have this system in place in 3-4 weeks, I can start analyzing on this system and have users test it. In this paradigm, there will be frequent releases and the analysis will be based on the last release. It may or may not be available to the end users yet for feedback. It won't be a surprise if a lot of the current requirements may not be requirements anymore 3 months down the line. Having a working system around to play with will likely make some requirements unattractive or not worth the investment. Image taken from: http://www.time.com/time/magazine/article/0,9171,1630556,00.html

Excellence in In-House Software Development

One of my client groups recently had a meeting in which they briefly discussed what it means to be excellent in software development. The client is an IT arm of a company whose staple is not software product or services.

It was interesting because this group's definition of 'excellence' did not include a few key points. I feel bad for these key points being overlooked. It's probably because my business is software development whereas software is a means to a different end for this group.

Here under are some attributes that would constitute 'excellence' in my opinion. In a software company or a software support arm of a non-IT business, I would strive to achieve an environment of:

  • Transparency - This could be anything from who's busy doing what to how the past efforts have been impacted the business. It never hurts to update your team on why certain decisions have been made. Transparency is the foundation of excellence.
  • Problem Solving - Often we find people say that they are problem solvers or that their's is a group of people that solves problems. I am not surprised anymore when on further investigation it turns out that most of them are patching problems up. Solving a problem is a bigger initiative. It, usually, requires bold steps and long-term vision without a greed for short term results.
  • Innovation - Continuing to solve problem the way you have been for the last 5 years, if at all, may not the best return. How have you, your team, your systems, and your processes become better and more efficient?
  • Entrepreneurship - Innovation and problem solving often remain in silos. Is there drive, energy, and enthusiasm in your innovators and problem solvers to take on the challenge to weed out inefficiencies from the system? Entrepreneurship usually is a response to an incentive of some kind; tangible or intangible. Create a few to foster it, if you haven't already inherited some.
  • Solution Focus - Enthusiastic technologists, specially in IT, are very eager to try new products, services, languages, and platforms and want to build their skills in them. Sometimes this is the reason why we find hundreds of applications written in 10 different languages with 4 different database systems. This also happens to be a reason why we also find features in these applications that took months to build but are rarely used by very few in the user community. That happened because it was a cool thing to build. Gist is that, after all, it is not about software. In the end, it's still about a solution to a business problem. It's a tough job to balance the big picture with the innovation.
  • Investment in Knowledge Sharing - One of the big reasons that high-end IT consulting is such a big industry is because consultants seem to know the latest and the greatest. On a few occasions I have been surprised how much one of the client associates already knew about a certain topic. It was even more surprising to know that in some of those cases the managers knew that a certain employee is very knowledgeable but did nothing about it. Instead, they waited for the consultants to show up and charge high dollars for it. Give your people room, time, and incentive to share what they know with the rest of the community.
  • Discipline in Action - Innovation, Solution Focus, etc. become the culture only if there's discipline around it. Do it every time and at every given opportunity. Very few people realize how demoralizing and demotivating it is to find out that there's really no rigor around in the culture.

What would you add or take away from the list?

Picture taken from: http://www.gapingvoid.com/excellence224.jpg

Demise of Offshore in an Agile World

The increasing adoption of Agile software development and management practices is starting to create an interesting dynamics. Agile adoption is not restricted to collocated teams anymore. Distributed projects have also been executed for long using these practices. But offshore projects are now being experimented with Agile. The primary difference between distributed and offshore is that the entire development, QA, and analysis, in offshore project is located away from the product owners/project managers. Another subtle distinction, which exists in the consulting world, is that offshore teams are typically all-consultant teams with little or no client members.
Agile, as practioners recommend and as teams experience, is a very disciplined approach to software development. It also demands a redefinition of the concept of a team. In the agile world a software development team is not just the developers, analysts, and QAs. A team also includes product owners, product managers, and program managers. This is a team of equals and is empowered. Every team member can and should make decisions that benefit the project and propells the team.
Given the team dynamics and interplay required for the success of Agile teams, offshore projects usually struggle a lot. They don't achieve the velocity that the team is capable of if they were collocated or distributed. Physical separation and time zone differences erode the benefits that collocated or distributed agile teams reap. The wastes created due to offshore hurts the agility.
I sometimes wonder what the future of Offshore is. How about offshore consulting? Will the politics and lack of trust that inherently plague client-consultant relationship restrict Agile exclusively to co-located or distributed projects? If Agile is the way to go forward, does that mean demise of offshore?