Thursday, November 27, 2014

What is Quality in Agile?

Members of software development teams define the quality of their team's software as conformance with user/business requirements. Mike Cohn [2] prefers Joseph Juran's definition of quality as "fitness for use," which is broader than conformance with requirements. 

Total Quality 


Jim Highsmith [1] defines quality in a much broader sense. In his view, total quality has two aspects:
  • Extrinsic Quality (Value to Client, Observable, Objective)
    • Functionality
    • User Experience
  • Intrinsic Quality (Subjective, not Visible Immediately)
    • Reliability
    • Adaptability
    • Reducing Technical Debt [4]

Quality - Personal View


John C Maxwell [3] defines Quality as: I haven't cheated you, I haven't cheated myself and I have done my very best. 

Adapting John Maxwell's definition of quality to an agile team for software development:
  • We have professional/moral obligation to the business to deliver good quality software (not cheating the business)
  • We have introduced fewer bugs and have not increased technical debt (not cheating ourselves)
  • We should be satisfied that we did our best as a team (doing the best)


Quality Involves More Than Testing


It is important to note the difference between quality assurance and testing. Testing usually involves ensuring that the software built conforms to requirements and is reasonably fit for use. Ensuring that the end product is of good quality involves a lot more than testing (including continuous testing) - good architecture, good design, good code, good team, and good process.

Quality - Holistic View


In Agile teams, the following principles illustrate that we need to take a broader and holistic view of quality:

  • Product is fit for use
  • Everyone tests, and testing is a way of life, and it is done continuously
  • Quality is the responsibility of the entire team (you don't need a separate Quality Police)
  • Quality has to be built in from the start - idea, architecture, design, coding, testing, to delivery
  • Quality should be built into the process - it is not something done at the end of the process
  • Platform/Product reliability and adaptability (to future changes) are not compromised to meet a deadline
  • Simplicity, emergent design, continuous striving for technical excellence - principles that help in building quality implicitly

Overall, the best proof of quality is when the team has enjoyed the journey and is proud of what they delivered.


References
  1. Agile Project Management by Jim Highsmith, 2010
  2. What is Quality, Mike Cohn's Blog
  3. John C Maxwell Minute Video
  4. Technical debt


Sunday, November 23, 2014

Why starting with WHY makes sense?

Why start with WHY?

Simon Sinek [1][2] talks about the importance of asking WHY since it helps one understand the purpose, cause, and belief behind an organization. He talks about "The Golden Circle" (Why > How > What), the correct order in which one should approach decision making or communication or marketing. He provides examples of companies and leaders who have the perfect balance: clarity of WHY, discipline of HOW and consistency of WHAT.



Most of the companies, organizations and individuals approach what they do in the order of What, How and Why. Whereas, starting with Why, then How and finally What provides a clear way to communicate to others and helps a company in winning its customers. Simon talks about Celery Test for decision making - starting WHY not only helps you know which is the right advice for you to follow, but also to know which decisions will put you of balance.



Agile Software Development 

I started thinking about how this applies to software development teams specifically to teams adopting agile development methodologies. I extended Simon's Why, How, What with When and Who, which are very appropriate in the agile world.



Most common order in which people would approach:


But I believe (based on Simon's idea), the correct order in which we need do is:



Why approaching each sprint, story and task with the above framework of mind is beneficial to the organization:
  • everyone in the team from Product Owner to tester to user understand the context, purpose and importance of Minimum Viable Product (MVP) that is will be delivered 
  • everyone on the team have a clear filter for decision making (everything should pass the Celery Test!)
  • empowerment of the team and distributed control are very easy
  • team will be motivated and will be committed to delivering it since everyone on the team understands
  • understanding why will help architects, designers, developers, testers and documentation writers do their job easily since they have a clear context and purpose
In my opinion, teams should not take on something until everyone understands the WHY!

References

Saturday, November 1, 2014

Review of Book: SCRUM: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

Every business is a software business 
- Lew Cirne


Though, Jeff Sutherland's new book, SCRUM - The Art of Doing Twice the Work in Half the Time is written for general audience (people outside software development industry), it is an excellent read for folks who are involved with software development.

Inspired by the Harvard Business Review paper, "The New New Product Development Game" (Hirokata Takeuchi, Ikujiro Nonaka, 1986); drawing ideas from the Toyota Production System (Taiichi Ohno, 1988); following the US Air Force training of doing four things - Observe, Orient, Decide and Act (OODA); and employing W. Edwards Deming's PDCA Cycle (Plan, Do, Check, Act), the SCRUM development process developed by Jeff Sutherland and Ken Schwaber, has revolutionized the software development process in numerous companies across the world. 

In this book, instead of just explaining the SCRUM methodology, the author takes the reader through ideas and best practices that are central to SCRUM: 
  • great teams (transcendent, autonomous, and cross-functional) and small teams (7 +/- 2)
  • time box it, demo it or kill it
  • it is crime to waste to build things that no one is going to use
  • doing it right the first time
  • measure output not hours
  • plan reality and plan what you need to
  • happiness is predictive and future-looking metric, it leads to success
  • what actually make people happy: autonomy, mastery and purpose
  • prioritize things
  • deliver Minimum Value Product (deliver 20% of features that hold 80% of value as a fast as possible)
Stories need to meet the INVEST criteria:
  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable
Jeff rightfully stresses the importance of Product Owner and identifies four essential characteristics of a product owner:
  1. Knowledgeable about the domain
  2. Empowered to make decisions
  3. Available to the team, explains what needs to be done and why
  4. Accountable for the value
Some interesting quotes from the book:
  • Time makes up your life, so wasting it is actually a slow form of suicide.
  • ... multitasking not only wastes your time but makes you stupid.
  • Doing half of something is, essentially doing nothing!
  • People aren't happy because they're successful, they're successful because they're happy
  • Complacency is enemy of success
  • Cherish the "Wise Fool" who asks uncomfortable questions or raises uncomfortable truths
In summary, SCRUM tells us to apply the following simple things to anything we do:
  • Prioritization
  • Single tasking
  • Cross-functionality
  • Review rituals
Overall, it is a very easy, interesting and inspiring read. I strongly recommend it to everyone, especially all software development professionals whether they are using agile methodologies or not. Great book!

Sunday, October 26, 2014

From Imagination to Fruition - Inventure Cycle


"A major stimulant to creative thinking is focused questions" 
- Brian Tracy

Every organization wants to be creative and innovative and every individual wants to be an entrepreneur at some point in their life. Creativity and innovation have become buzz words in the industry. Different people have different meanings for the words creativity and innovation and lot of people use them almost synonymously. Tina Seelig [1] has put the forward a framework (she calls Inventure Cycle) to explain how we can go from inspiration to implementation. 

  • Imagination is the ability to envision things that don't yet exist
  • Creativity then is applying your imagination to solve a problem
  • Innovation then is applying your creativity to come up with a unique solution
  • Entrepreneurship then is applying our innovation to bring those ideas to life, to bring them to fruition and to the rest of the world


The Inventure Cycle

  • Imagination 
    • Engaging - start somewhere, pay attention, see opportunities
    • Envisioning things that would be different
  • Creativity 
    • Motivation - find something that motivates us
    • Experimentation - start experimenting in the areas that motivates us to pick something that might work
  • Innovation 
    • Focus time and attention to learn everything about something that might work
    • Reframing - looking at the problem from all different angles
  • Entrepreneurship 
    • Persistence - essentially grit!
    • Inspiring Others to join the team and invest




According to Tina Seelig [2], one can't bring ideas to life alone - we need a team. Every organization needs people to play the different roles identified in the Investure Cycle - imaginers, creators, innovators, entrepreneurs, and people who are inspired to be part of the team.

Ed Catmull [3] talks about how to foster creative culture in large organizations: loosen the controls, accept risk, trust the team, let teams operate according to their own rules. clear the path for teams, etc.. It is very important to have a great team not a mediocre team: if you get the team right, chances are that they'll get the ideas right.

References

  1. From Inspiration to Implementation by Tina Seelig, Entrepreneurial Thought Leaders Podcasts, October 15, 2014
  2. Stanford University's Entrepreneurship Corner, http://ecorner.stanford.edu/author/tina_seelig
  3. Creativity, Inc by Ed Catmull, 2014

Wednesday, September 24, 2014

Quotable Quotes

Charles Darwin

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.

Schopenhauer

A human being can very well do what he wants, but cannot will what he wants.

Bob Hawke

The things which are most important don't always scream the loudest.

Steve Uzzell

Multitasking is merely the opportunity to screw up more than one thing at a time.

Alan Watts, Does It Matter

Money is a measure of wealth, and we invent money as we invent the Fahrenheit scale of temperature or the avoirdupois measure of weight… By contrast with money, true wealth is the sum of energy, technical intelligence, and raw materials.

Information Week

Goodbye IT, Hello Digital Business.

Mahatma Gandhi

Our thoughts become our words, our words become our actions, our actions become our character, our character becomes our destiny.

Kurt Vonnegut

We are what we pretend to be, so we must be careful about what we pretend to be.

Voltaire

Judge a man by his questions, not his answers.

Work saves a man from three great evils: boredom, vice, and need.


Pablo Picasso

On computers: But they are useless. They can only give you answers.

Milton Freedman

Most economic fallacies derive from the tendency to assume that there is a fixed pie, that one party can gain only at the expense of another.


William Glasser
   
  We Learn ...
     10% of what we read
     20% of what we hear
     30% of what we see
     50% of what we see and hear
     70% of what we discuss
     80% of what we experience
     950 of what we teach others


Albert Einstein 

    In my experience, the best creative work is never done when one is unhappy,

    Only two things are infinite: universe and human stupidity. And I'm not sure about the former.

Clive Thompson, Smarter Than You Think

   Our ancestors learned how to remember; we'll learn how to forget.

Gabriel Weinberg

Blogging forces you to write down your arguements and assumptions. This is the single biggest reason to do it, and I think it alone makes it worth it.

Sir Francis Bacon
   
   "Reading maketh a full man, conference a ready man, and writing an exact man."

Sturgeon's Law


   90 percent of everything (science fiction or user generated content) is in a word, crap. The 10 percent isn't crap and a smaller percentage is downright good.

Jeff Howe, Crowdsourcing

     The only thing we all have in common is that we are all quite different - in the networked age, that can be a very good thing.


    If great minds think alike (and in many circumstances they do) - then they really constitute only one mind. Two heads aren't better than one when it's really only one head (i.e., having similar thinking heads doesn't help).

Benjamin Franklin
    
   Either write something worth reading or do something worth writing.

Malcom Gladwell, Outliers


   Three qualities work has to have if it is to be satisfying:
       -  Autonomy
       -  Complexity
       -  Connection between effort and reward

Leonard Mlodinow, The Drunkard's Walk: How Randomness Rules Our Lives

    Although Fortune is fair in potentialities, she is not fair in outcomes.


Aaron Levenstein


    Statistical Models are like bikinis - what they reveal is suggestive, but what they conceal is vital.


Peter Drucker


  The productivity of work is not the responsibility of the worker, but of the manager.


Frank Wander, Transforming IT Culture


   The quality of solution is a direct reflection of the cohesiveness of the social system (read as team) that delivered it


Marc Goodman, TED Talk

You control the code, you control the world

Todd Humphreys, TED Talk

We are selling our privacy for convenience

Stanley McChrystal, TED Talk

Leaders aren't good because they are right, they are good because they are willing to learn and willing to trust.

David A Garvin, Harvard Business Review

Engineers hate being micromanaged on the technical side but love being closely managed on the career side.

People don't quit companies but they quit managers.

Adage

If everything is important, nothing is.

Patrick Lencioni, The Advantage

Too many objectives - none of them is going to get the attention it deserves and there will be distraction, diffusion, and dilution.

An organization has to institutionalize its culture without bureaucratizing it.

You can teach skill but not attitude.

C.A.R. Hoare


Inside every large program, there is a small program to get out!


T.S. Eliott



Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?

I would like to add,

Where is the information we have lost in data?

Clay Shirky in Cognitive Surplus

Generations do differ, but less because people differ than because opportunities do.

Humanly are fundamentally individual, but we are also fundamentally social. 

All groups have an emotional component - emotion, in fact keeps groups together.

Because humans have fundamentally social as well as personal motivations, social motivations can drive far more participation than can personal motivations alone.

People will behave if they sense that there is a long-term value in doing so, and short-term loss is not doing so.

Ironically, one of the easiest ways to distract a group is to get them to focus on outside enemies, real or imagined, rather than on their shared interests or tasks (or principles).

Carl Shapiro, Harl R. Varian,  Information Rules

Information is costly to produce but cheap to reproduce.

Sitaram Asur and Bernado Huberman, HP

... social media expresses a collective wisdom which, when properly tapped, can yield extremely powerful and accurate indicator of future outcomes.

Julian Simon, Economist

The main fuel to speed world's progress is our stock of knowledge, and the brake is our lack of imagination.

Erik Brynjolfsson & Andrew McAfee, The Second Machine Age

Analog dollars are becoming digital pennies.

Not everything that counts can be counted, and not everything that can be counted, counts.

Sometimes, one man'a creativity is anothe machine's brute-force analysis.

Tony Robbins, TED Talk

Divorce the story, marry the truth.

Trey Speegle, Mixed Media Artist, Creative Block: Get Unstuck, Discover New Ideas. Advice & Projects from 50 Successful Artists by Danielle Krysa

You have to set up the narrow parameters that you work in, and then within those, give yourself just enough room to be free and play.

Donald Rumsfeld 

There are known knowns; there are things we know that we know. There are known unknowns; that is to say there are that, we now know we don't know. But there are also unknown unknowns - there are things that we do not know we don't know.

Gary Keller

How we phrase the questions we ask ourselves determines the answers that eventually become our life. (In his book, The One Thing)

Alan Kay

The best way to predict future is to invent it.

Saturday, February 15, 2014

Important Triangles In Technology

I have come across the following triangles that are important in technology and project management. Numerous authors [1] have used triangles to connect three important points or concepts. One of the three reasons for picking only 3 things is that humans can focus on only 3 things simultaneously. It is important to note that there is a bit of a trade-off among the three corners of the triangle.


  • Project Management Triangle or Iron Triangle (PMBOK)
  • Agile Iron Triangle
  • Agile Triangle  (Jim Highsmith)
  • Performance Triangle

Project Management Triangle (Iron Triangle)


Also known as the Iron Triangle. This is the typical project management style, where what needs to be delivered is fixed (scope), and when it can be delivered is determined by the resources we have at our disposal (cost).





  • Scope (Requirements)
  • Cost (Resources)
  • Schedule (Project Duration)

Agile Iron Triangle


When individuals/organizations start using agile methodologies, they think this is the Agile Triangle: where schedule (iteration/sprint duration) is fixed and based on available resources (cost), we pick what can be delivered (scope).



  • Schedule (Iteration/Sprint Duration)
  • Cost (Resources)
  • Scope (Features/Stories)

Agile Triangle


I call this True Agile Triangle to distinguish it from Agile Iron Triangle. As Jim Highsmith explains in [2], agility is all about delivering high-quality customer/business value within given constraints (scope, cost, schedule).





  • Value (Releasable product delivering value to customer) 
  • Quality (Reliable and Adaptable)
  • Constraints (Scope, Cost, Schedule)


Performance Triangle


When designing and developing high-performance systems, we have to consider trade-offs among performance (speed), reliability (availability), and security (protection). This applies to low-latency High Frequency Trading systems [3], truly secure applications [4], real-time systems, and typical enterprise applications.




  • Performance (Speed)
  • Reliability (Accessibility/Availability)
  • Security (Protect, Prevent Damage)



References

1.  The Triangles of Management and Leadership by Paul B. Thornton, 2003
2. Agile Project Management by Jim Highsmith, 2010
3. A Practical Guide to Designing Racetracks, Presentation by Jacob Loveless at Big Data in Finance 2014
4. Considering the Performance Triangle by John Mueller, Blog


Friday, January 31, 2014

What Good Google's Best Managers Do?


What Google's Best Managers Do?

  1. Is a good coach
  2. Empowers the team and does not micromanage 
  3. Expresses interest in and concern for team members' success and well-being
  4. Is productive and results-oriented
  5. Is a good communicator - listens and shares information
  6. Helps with career development 
  7. Has a clear vision and strategy for the team
  8. Has key technical skills that help him or her advise the team
I found the above eight are very simple and easy to understand and I think they are applicable to any IT organization.

Also, I think two other observations from the above article are very true:

  • Engineers hate being micromanaged on the technical side but love being closely managed on the career side
  • People don't quit companies but they quit managers



Sunday, January 26, 2014

How To Tap Into Cognitive Surplus In A Company

Similar to Code for America (which itself is based on Teach for America), I am thinking companies could benefit a lot if they do something like Code for Company. One might think that all corporate developers work and do coding for the company - but in reality, corporate developers only code for the project they are assigned to. 

Lot of corporations have lot of cognitive surplus within their own organization similar to Cognitive Surplus we have in overall community[2, 3]. I think companies can benefit by tapping into corporate cognitive surplus.

What corporations can do to use the cognitive surplus they already have:
  • Let all developed employed by the company in all locations to register themselves as community developer
  • Post projects to be picked by the team of developers already employed by the company
  • Make sure that the IP stays with the company
  • Encourage community developers to contribute some of their time to company wide projects
  • Developers who contribute the corporate community should not be penalized but should be applauded
  • Ask managers who go to vendors to project assignments to try this community first
  • To start with it may benefit the company if they dedicate some developers for certain period of time to kick start the community 
This will be a good start for large corporations to start a new work model to engage the Agile Workforce[1] (where companies need to have multiple work models), for following reasons:
  • since individuals can have an identity beyond the immediate manager or team or project or department they work for
  • the team that assembles itself for a project will be self organizing and deliver the project 
  • it will be possible to get required skills/expertise much faster within the company
  • company developers can learn to work in community development without worrying about intellectual property since they are still contributing to the company
  • companies  can learn how to engage new workforce who don't have much loyalty to their employer but have highest professional standards
  • overtime companies can cooperate with few select partner companies to build a larger community
  • companies don't need to reinvent the wheel for this - copy from open source, crowd sourcing communities that already exist in the market

Wednesday, January 22, 2014

Review of Book: Transforming IT Culture by Frank Wander


By Frank Wander, 2013
My Rating 5/5

Very interesting book on how to transform culture in business IT organizations (business and IT are conjoined in most industries) for post-industrial era. In lot of organizations, industrial era processes and mindset still permeates at all levels of leadership. 

The books starts with an accurate picture of dismally unproductive IT organizations in many companies; talks about why industrial era based processes are part of an important foundation for an organization but are not enough for productive teams;  and how anti-social/toxic behaviors hurt productivity of teams.  

Frank then make case for why human factors (trust, empathy, compassion, transparency, openness, humor, sharing, transparency, unselfishness, caring and mutual respect) are important in information era; provides a long list of practical pro-social behaviors that exhibit these human factors; introduces concept of servant leader by comparing teams to orchestras and leader as conductor; importance of emotional and social intelligence in teams and more importantly in leaders and rules for energizing teams; and points out interconnected and socially cohesive teams are creative and innovation happens when teams try and learn from failures.

Finally, Frank delves into workforce planning, outsourcing, off-shoring, stresses the importance of collaborative relationship between business and IT and presents best practices for IT.

Some of the gems from the book:
  • View teams are collaborative social systems
  • Comparing team to an orchestra of creative performers brings forth the main ideas of the book very elegantly - very realistic and best analogy in my view
  • Full of practical advise and observations from IT point of view - makes you happy to see what you have felt all along and at the same time you will acknowledge that can only come from a seasoned practitioner
  • Comprehensive lists of anti-social behaviors and pro-social behaviors - one should definitely review the list of anti-social behaviors!
  • Pertinent quotes that are embedded throughout the text are a joy
  • Useful references and notes at the end of every chapter
A thoroughly researched book with a practical bent and ideas presented in this book are relevant at all levels of an organization (individual team members, team leaders, managers, all the way up to CIO). Many IT organizations do not like talking about human factors or building socially cohesive teams but wonder why teams are not productive, members are not happy and why projects fail or delivered late. We always hear about "people first" but we also need to make sure that "best people are connected and working together in most productive way!". 

Though the book doesn't talk specifically mention it, I personally feel that collaborative business and IT that operate in a socially cohesive manner is a must for success of agile methodologies or lean practices. (See my blog posts)

Overall, it is worth reading and I am certain that it will change one's perspective after reading the book! All good techies need some social skills!

Sunday, January 19, 2014

Business Technology Development Team Organization

In my previous posts, Division between Business and Technology - Is It Still Relevant? and Business and IT (Mis)Alignment, I talked about how the chasm between business and IT in many organizations is hurting the companies in many ways: late to market with new products, lack of innovation, not being to able engage the workforce (specifically millennials) effectively.

We can look at an organization from the top or from the bottom to see how best to organize the teams. There are some good examples on how to organize teams under CIO (see Frank Wander's book Transform IT Culture) and another way is to look at individual business divisions. Many organizations have been moving away from centralized IT organization towards business aligned IT organization at each business unit level.


With in each business unit, the division between business and IT is still maintained possibly because of past history or background of the individuals in charge of business and IT. A typical software development team would require the following individuals (people with following roles):



  • Product Strategist/Manager
  • Development Manager
  • Project Manager
  • Business Analyst
  • Architect
  • Programmer
  • Tester

Projects vary in complexity from complex business requirements to complex IT requirements. Some one from business/product area can lead and own the delivery of projects that are more complex from business/product point of view. Similarly some one from IT area can lead and own the delivery of projects that are complex from IT point of view. If the project is really big and complex (say from view points of business and IT) then joint ownership of project with leads from business and IT would benefit organizations. For projects that are in the middle (combination of business and technology), either some one from business side or IT side can lead the delivery of the project.

Advantages of having this kind of collective/joint ownership of projects include:

  • Collective/joint ownership brings best of both teams
  • Businesses derive their competitive advantage through leveraging technology
  • Applications/systems delivered will be designed for business, easy to operate, tailored to the needs of business
  • Makes it easy to adopt agile methodologies to bring products to market sooner

For organizations to adopt this model, individuals need to change by trusting each other first and also individuals need to step up to learn new skills and to play different roles. We don't need every individual to play multiple roles since there will be specialized work on either end of the spectrum (business/product oriented and completely IT architecture/development oriented). Note that other individuals on the delivery teams should be encouraged to play multiple roles and also acquire different skills from others.

I am certain this type of flexible/collective organization will lead to employee satisfaction, more productive work, and timely delivery of projects.

Friday, January 17, 2014

Review of Book: The Five Dysfunctions of a Team : A Leadership Fable by Patrick Lencioni

The Five Dysfunctions of a Team : A Leadership Fable 

by Patrick Lencioni, 2002

My Rating 4/5

    Though it was published 12 years ago, this is timeless classic. Simple one to read and contains very powerful ideas on how individuals can overcome dysfunctions common to any team. It may seem a bit idealistic in this highly competitive world but if teams can follow the simple principles outlined in the book, I am sure any team can achieve wonders!

    Five things every team should do:
    1. know every one's strengths and weakness and trust each other 
    2. not to avoid conflict and have healthy debate
    3. commit to team decision after considering all opinions
    4. feel collectively accountable for each other's performance/behavior
    5. note that ultimately success of the team that counts

    I have worked on teams that were very productive and also worked on teams that were not so productive. If I look back and think about the why some teams worked so well, the above positive behaviors were probably present.

    Why not try it once to see if it makes a difference in the results. What do we got to lose!

    Wednesday, January 15, 2014

    Big Data, Statistics and Future

    Recently I read the book Uncharted: Big Data and an Emerging Science of Human History by Erez Aiden and Jean-Baptiste Michel in which, they talk about using the Google Ngram to find fascinating cultural trends. Google Ngram Viewer is very addictive and it is amazing so many interesting facts can be found from the (big) raw data!


    Big Data Shadow Data Sets In Public Domain


    Data collected by companies like Google, Facebook, Twitter, Amazon, eBay, etc. is deemed proprietary by these companies (and law), though we collectively help them in collecting data about us. But if we can develop some process and governance around creating big data shadow data sets (using data masking or data obfuscation techniques) for research purpose (similar to what Erez and JB have done with Google Books), it will open up more fascinating views into our history, culture and possibly help in predicting our future. 


    I know there will lot of legal hurdles to it but am I naive in thinking that we collectively have ownership on this data (obviously shadow data not real data) - should governments mandate that these companies release shadow data sets into public domain or at least to the government agencies for academic research. This is similar to the G8 Open Data Charter which makes all government public by default! 

    I found the following interesting article from Mc Kinsey which talks about how companies could benefit from sharing (should we say opening) data: What executives should know about open data.

    In financial world, exchanges and market data vendors make money in distributing tick data (based on actual trades done by all of us) and historical closing prices. There are open financial data sites like http://www.quandl.com/ and Eurostat. Should regulator mandate that trade repositories be open? Healthcare industry (and academics and consumers) could definitely benefit if masked medical billing data is made available in open.


    Sunday, January 5, 2014

    Business and IT (Mis)Alignment

    In my previous post Division between Business and Technology - Is It Still Relevant?, I talked about division between business and IT (specifically Application Development) in medium to large size organizations. In this post we will see how a typical business technology organization is structured and why this division leads to lack of innovation, project failures and ultimately loss of revenue.

    Typical organization consists of following groups usually organized as different teams with separate reporting lines:

    - Clients/End Users
    - Business Sales/Marketing
    - Product Development
    - IT Development
    - Testing
    - Project Management (PMO)
    - Operations
    - Support

    Also individuals belonging to each of the above teams have very specific job titles signifying the their speciality (a way of telling that they are allowed only work in that area!). Some organizations have gone to the extent of discouraging generalists (or "people who wear multiple hats") and encourage individuals to become specialists.

    Common issues organizations run into because of this organizational divide:

    - Usually there is no single owner (even if there is one, owner doesn't have control!)
    - Requirements do not capture what users wanted
    - Development can't start until requirements/specification is complete
    - Development takes too long
    - Not fully tested
    - System is too difficult to support
    - Similar to an elephant and four blind men (each participant have their own view of the system actually delivered)
    - Constant bickering, lack of trust

    It should be noted that the above job titles are merely skills and depending on the needs of the organization, people can play above roles - sometimes playing multiple roles at the same time! It also encourages individuals to learn and acquire skills they don't have either formally or informally (by shadowing someone). 

    In my view, organizations will change for following reasons:

    - to innovate and bring products to market sooner, we need individuals to work as one team often playing multiple roles
    - since the new workforce will have individuals with multiple skills and for organizations to succeed in future, they have to change now!
    - employees will be happy when they feel collective ownership and also whey learn new things (on their own and also from others)