Mobile development tools are changing rapidly.

I had started work on comparing cross-platform mobile tools about a month back. I had initially started with a list of 26 tools. Few got added on the way.

However, what is most interesting is that in this short period of time one of the tools (Open Plug) was discontinued. It was a Flash based tool. Since Adobe decided to discontinue Flash for mobile in favor of HTML5 – they really had no choice. Another tool (Pyxis Mobile) has been renamed as (Verivo Software).

Coming back to mobile tool comparison – I had categorized the tools into five categories (here is an overview). They are:

(1)    Mobile Web (JavaScript-CSS library), (here is the detail review)

(2)    Visual Tool (No access to Code),

(3)    Hybrid App (Leverages embedded browser control),

(4)    App Generator (Native application for multiple platforms) and

(5)    Game Builder.

In this post I give an outline of the Visual Tools where you use a visual editor to build the application. Some of these tools do not give you any access to underlying source code.

Here are 5 tools – the ordering is alphabetic.

1. Application Craft

• Home page: Link
• Genesis: It is a cloud-based, desktop and mobile app development environment for building enterprise apps and mobile and tablet content
• Version: Both cloud hosted and in-house
• Licensing: Both free and paid premium – see this
• Download: Not open sourced yet
• Documentation: Video
• Sample application: Link
• Implementation: Crunch Base – Mobile site & YouTube video
• Wikipedia: No
• Additional: Phone Gap + Application Craft
• Article on how to use: Video tutorial, Web services tutorial

2. Dragon RAD

• Home page: Link
• Genesis: Offshoot of Seregon Solutions Inc., a provider of mobile enterprise application platform software
• Version: 4.0
• Licensing: Paid with 30 day free evaluation – see this
• Download: Link
• Documentation: Video tutorial & Webinar
• Sample application: Link
• Implementation: Only one
• Wikipedia: Yes
• Article on how to use: From Zombo

3. July Systems

• Home page: Link
• Genesis: Cloud based solution – tight coupling between development tool and hosting
• Version: 3.5 released on March 2011
• Licensing: Details not available on the site
• Download: Not freely available
• Documentation: Video overview
• Sample application: Link
• Implementation: List of customers
• Wikipedia: Yes
• Article on how to use: No third party article

4. Net Biscuit

• Home page: Link
• Genesis: Cloud based solution – tight coupling between development tool and hosting
• Version: Sitebuilder V2.0 released on September, 2010
• Licensing: Free developer edition – Register
• Download: Not freely available
• Documentation: Overview and Detail Documentation
• Sample application: Hotel.info, eBay.com & mTV
• Implementation:  List of customers – Slide Show and Report
• Wikipedia: No
• Additional: Developer forum
• Article on how to use: DevX.com, Tridionworld.com and  Martin Schreiner

5. Verivo

• Home page: Link
• Genesis: Verivo! Was originally known as Pyxis Mobile.
• Version: Not Clear
• Licensing: Not Clear
• Download: Not Clear
• Documentation: Not Clear
• Sample application: Case studies
• Implementation: List of customers and App Store Links
• Wikipedia: No
• Article on how to use: Stack overflow & Pyxis Mobile from AT&T
• Comment: Because of rebranding all Pyxis mobile links lead to the home page

Have you seen this Wiki?

Here is an interesting wiki – WikiMobidex.org which lists mobile offering from different suppliers. Any supplier can register and add a page for their offering. More than 200 suppliers are listed.

Do let me know if there are any errors and omissions in the details I have provided.

[Update: There are 2 platforms which I have not covered but has been pointed out by readers - (1) iBuildApp & (2) Tiggzi]

Home page: Link

“…some degree of deception present in all three forms (face-to-face, instant messenger, email) of communication, it was increased in both instant messaging and e-mail, with e-mail messages the most likely to contain lies…”

The author goes on to draw the conclusion that “deindividualization” effect leads to lying. When people grow psychologically and physically further from the person they are in communication with, there is a higher likelihood of lying.

No, if you go by what is written in the book “59 Seconds: Think a Little – Change a Lot” by Richard Wiseman. In this book he quotes a study by Jeff Hancock and his colleagues at Cornell University and goes on to say that:

“…people in lied 14% of emails, 21% of texts, 27% of face-to-face and 37% of telephone…”

In this case the author concludes that when somebody has to put things in writing the chances of lying comes down.

[I have not given the details of the study – you can look it up.]

Which is correct?

Both explanations look very logical.

So, what is the truth?

How two academic studies can have such diverse result?

Which one should you believe?

Fooled by Randomness

If you have not read this book “Fooled by Randomness: The Hidden Role of Chance in the Markets and in Life” by Nassim Nicholas Taleb, I suggest that you read it. However, let me warn you that you might be put off by the style of writing.

But for now, you can have a look at these articles which outlines the main thesis of the book.

1. Book Extract – The nature of probability is easily misunderstood, and misinterpretations of statistics abound.
2. Review by Mark Wainwright – Try as we might, we continue to see patterns where none exist, misunderstand the role of randomness, seek explanations for chance phenomena, and believe that we know more about the future than we do. And that is the point of this book.

May be, here lies the explanation of how 2 studies can come to such diverse conclusion.

We live in a complex world

Our world is complex – especially when we deal with human being.

You have to accept the fact that the day of finding simple and elegant explanations for every trend that we observe are over. Any trend that we observe may be just a random event. The cause and effect correlation presented to us may look neat but is likely to be totally erroneous.

Be skeptical of all such studies.

One of the principles behind agile manifesto hints that it is possible:

“…Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely…”

However, the real world is different. We live in a world where we have an obsession with “Growth” … obsession with “Achieving more with less” … obsession with “Goal orientation” … obsession with “Stretch target”. To this you add the fast pace of change in everything around us – you will find that status quo is something which is very difficult to maintain.

Couple of days back I received a mail from Hema and here is an extract from that mail:

“…. I am a big believer in Agile and have been looking for companies that do real agile and have good work life balance. Do they exist or should women just move out of IT industry if they want work life balance if they care a lot about their kids? Are some roles better suited than others?…”

Many of you may echo this same sentiment … may ask the same questions. So, where do we look for an answer?

Assumptions contained in this statement

There are several assumptions inherent in that statement.

• Adoption of true agile will lead to work-life balance
• IT industry suffers more from work life imbalance than many other sectors
• For a specific organization, work-life balance or imbalance will be uniform across
• Work-life imbalance is role specific
• This problem is specific for women

Are all these assumptions true?

Main reasons of work-life imbalance

In my opinion, the single reason which leads to work-life imbalance is when somebody (it may even be you) makes a commitment which cannot be fulfilled without putting in extra effort from your side – and you are not ready to face the consequence of not meeting the commitment.

The reason of why you cannot meet the commitment can be several. The commitment was made…

1. …without an understanding of the complexity involved
2. …in a competitive situation where the options was to either accept the deal with the given conditions or walk out of it
3. …without considering the impact on other commitments already made
4. …assuming a team composition, which for some reason cannot be realized – either people have left or you cannot find suitable people
5. …from the top with the assumption that certain percentage improvement to status quo needs to be done
6. … was derived from some higher level goal and handed down as given

Will adopting agile solve this problem? I really doubt it.

What can you do to avoid such situation?

The problem is not restricted to IT alone – neither is it limited to certain roles. Even if you are a school teacher you might find that you have been handed out with responsibilities which go much beyond teaching.

Agile practice, by itself, is unlikely to help you achieve work-life balance. Given today’s business environment it may even make it worse.

Here are few suggestions which may work. Though, I should warn you that our world has become complex enough and competitive enough to ensure that you need to run fast to stay at the same place.

1. Learn to say “NO”. There is lot of stuff written on how to say no – just do Google it. Many people believe that Steve Jobs succeeded because he could say no – Steve Jobs: Get Rid of the Crappy Stuff.
2. Learn to “Slow Down”. Did you know there is something called “Slow Movement”? There is even a Wikipedia page on slow movement.
3. If you are still confused about what you want to do read this book – What Should I Do With My Life? Remember one gentleman called William Henry “Bill” Gates – he just walked out from the most successful company at that time which he had built from scratch.

Finally…

Here is an interesting report from McKinsey titled Changing companies’ minds about women or see this link. So, there is some hope for women. However, things are not changing very fast, so …

There are consequence to “saying no”, “slowing down” and “changing your career”.

Be clear that you understand those.

If you listen to Eric Schmidt, it is off course Facebook. Off course anybody from Google will consider Facebook in the list because Larry Page is turning Google upside down to compete with Facebook.

However, if you go by what Jeff Bezos say then it has to be Microsoft. According to him “…they’ve done a lot of innovative things, some of which get overshadowed by their big existing businesses…”

So, who will it be – IBM, Facebook or Microsoft?

Consider the following facts and possibilities

• Since 2009, IBM share has outperformed Microsoft (see this).
• In the same period Google and Microsoft stocks have performed about the same (see this).
• Facebook IPO, when it comes, is expected to round up anywhere between 50 billion to 100 billion US$ (see this).
• Facebook’s IPO would be 6X bigger than Google’s (see this).
• IBM has replaced expensive workers in North America with low-cost laborers abroad, which has helped keep margins and profits growing (see this).
• By the end of 2012, Google+ may become the second most popular social media site (see this).
• Google surpasses Facebook to become the most visited site of 2011 (see this).
• Microsoft has a habit of coming from way behind and winning the war (see this).
• IBM has bet big on analytics including cloud analytics & “Big Data”. The icing on the cake is when Watson won Jeopardy! (see this).
• Microsoft has created the MetroUI for Windows 8, which has the potential of becoming a game changer like Kinect (see this). Or, will it be a flop like Vista.
• The fate of Nokia and possibly Intel depends on the success of the next generation Windows OS (see this).
• An x86 tablet with Windows 8 running all the legacy applications … anyone (see this)?

Ultimately it boils down to these 3 questions…

1. How successful will Windows 8 be, especially for the Tablet?
2. Will Facebook come up with an IPO and if it does how successful will it be?
3. Is “Big Data” the next big thing in cloud or is it a solution in search of a problem?

If you have been following then you would probably have guessed that I feel that the first question is going to be a game changer.

If Windows 8 succeeds then it would be as disruptive as iPad or Android – it would have blurred the distinction between PC and Tablet.

On the other hand if it fails then posterity may consider this event as the starting point of the end of PC era.

It happens to me quite frequently.

For example, recently, I read an article on “10 Ways to Sell an Idea” by Dennis McCafferty which I found to be quiet contrary to another article I had read few years back. I wanted to locate the article and it took me a long time to do it. In fact, it took me more time to locate the article than to write the post comparing the contrasting view – How to Pursue You Innovative Idea – 2 Contradictory Perspectives.

Now that Google has started leveraging your and your friend’s activities for searching – it may be an interesting idea leverage that to find stuff that you have liked in the past.

After I had added by blog to my Google+ profile, I have found it easier to search any of my past post by directly searching in Google rather than going to my blog and looking for it. Since the search result is personalized, the post that I am looking for invariably shows up in the search.

For example, to look for my post 6 Game Changing Technology Events Of 2011 – And 2 Non-Events I had to just type “6 events and 2” and bang the link shows up as the third item.

Obviously, when you do a similar search, you will not find the link.

Here is an interesting study from IBM – Tip for Getting More Organized: Don’t

So, that opens an interesting possibility.

Why not just keep liking and sharing all the post that you might find interesting? You may be able to find it easily in some distant future.

To ensure that complexity does not turn into chaos it is inevitable that the pure agile way of working may have to be sacrificed – is it possible without violating agile manifesto? It is also inevitable that the agile practices will need to integrate into other practices of the enterprise.

To be able to scale agile we need to understand:

• What the dimensions to this complexity?
• How to split the problem and the team?
• How to introduce processes and tools?
• How to manage collaboration among distributed team members?
• How to plan and manage workflow?

Dimensions of scaling and the need to integrate with other enterprise processes

Scaling Agile: An Executive Guide – Scott Ambler

To scale agile to an enterprise level, eight dimensions of complexity needs to be handled.

1. Team size – from less than ten to hundreds
2. Geographical distribution – from collocated to globally distributed
3. Regulatory compliance – need for mandatory compliance
4. Domain complexity – straightforward to complex and emerging
5. Organizational distribution – from all in-house to multiple external parties
6. Technical complexity – from homogeneous to heterogeneous including legacy
7. Organizational complexity – from flexible to rigid
8. Enterprise discipline – from no external constrain to need to adhere to enterprise standards

Different options of splitting the teams

Scaling agile teams – by features or by component? – David Draper

There are four options to split a large team into smaller sub-teams

1. Component orientation: (Pro) Typically this is how developers align themselves. (Con) Need to split user-centric feature – focus shifts away from business value.
2. Discipline: (Pro) This is how enterprises are already organized. (Con) Risk longer lead times with a “throw over the wall” attitude.
3. Location: (Pro) Collocated teams tend to be more effective. (Con) Need to match feature set with specific team.
4. Feature: (Pro) Aligns well with goal of delivering value. (Con) Integration issues may arise.

In practice a mix-and-match approach may be best where the split is done primarily based of feature and location.

Harmonizing the tool and process dimension with agile practices

Scaling Agile for Project Teams – Alan Bustamante & Rahul Sawhney

There is a need to harmonize three dimensions of people, process and tool. Here are some of the recommendations on how to achieve it.

1. People issues are best tackled through structure, empathy, communication, and people-oriented policies.
2. Addressing process challenges for scaling requires organizations to understand their process focus and validate that it is aligned with the organization’s vision, mission, and values.
3. Focus on tools that support and facilitate the team and sub-team’s processes by eliminating or minimizing non-value added work.
4. Configuring tools around a flawed process will still yield a flawed process. Fix the people and process issues first.

Making distributed teams effective through communities of practice

Scaling Agile to work with Distributed Teams – Mike Cohn

Total team size increases complexity. Distribution increases complexity. It becomes impossible for all team members to know each other let alone trust each other. One way to build the bridge is to set up communities of practice.

• A group of likeminded or like skilled individuals which is self-organizing, organic and can span projects / location
• All communities need not be officially sanctioned – they can completely informal to highly institutionalized
• Creating proper environment for the communities is important

Managing the product backlog at multiple levels

Scaling Agile Processes: Five Levels of Planning – Hubert Smits

Agile planning activities for large-scale development efforts should rely on five levels:

1. Product Visioning
2. Product Roadmap
3. Release Planning
4. Iteration Planning
5. Daily Planning

Product Vision is more like a desire of what the product will deliver once it is finished and would not talk about specific features. On the other hand Product Roadmap would talk about high level product backlog from which backlog for lower levels will be derived. It will communicate when releases are needed, what would be sufficient functionality and what business value would be delivered.

Like the two previous levels Release Planning is also for all the teams. Releases are defined by fixed date, theme, and planned feature set to which all teams must commit to. Typically, the product release would be once a quarter and the iteration cycle would be 2 to 4 weeks.

Managing workflow between multiple teams using Kanban

Large-Scale Agile – James Shore

Use Kanban for workflow not within a team but between teams.

1. Treat each agile team as a work cell
2. Use Kanban to manage cross-team workflow
3. Create a Product Portfolio team which is collocated, cross-functional, intact team consisting of product managers, business experts, UX designers, architects etc.
4. Partition the teams in such a way as to minimize the dependencies
5. Monitor the system using lean techniques which is Visual control, Throughput and Value-stream mapping
6. Sacrifice reuse in favor of throughput
7. Keep communication flowing with Scrums of Scrums

Finally…

Since, to scale agile, we may have to deviate from the spirit of the original manifesto, the question is how much can we deviate and still call the resultant methodology agile? And, when does it become an iterative development methodology?

Incidentally, iterative development seems to be as successful as agile development. Have a look at this survey outcome.

Apart from the fact that Agile has been consistently been more successful compared to traditional approach, these survey result show two more interesting result – one of them is very surprising.

1) The gap between “Iterative + Agile” and “Traditional + Ad-hoc” has been increasing

It is not clear why there is a dip in the success rate of all types of project in 2010. But, leaving that aside, the gap has been consistently been increasing (2008=7%, 2010=13% and 2011=18%).

So, does it mean that people have really mastered the art of how to manage Agile and Iterative projects?

Or, does it been, people who are good at project management have abandoned Traditional approach and migrated to Agile or Iterative approach?

2) Iterative approach has consistently performed better than Agile

Though the difference is not very significant, all the 3 survey has indicated that iterative is slightly more successful compared to agile.

Does it imply that all the stuff in Agile Manifesto about “People over Process”, “Co-located Team”, “Face to Face communication”, “Cross functional team” etc. has very little to contribute to project success? When you scale Agile, you may need to violate some of them anyway.

Agile@Scale ≠ Agile@Manifesto

Word of Caution from Scott Ambler

He is quick to point out the known challenges with any survey.

• You will only get responses from people willing to be surveyed
• You risk getting responses from people with strong feelings about the topic
• Very often questions capture opinions, not facts
• The biases of the communities will be reflected in the results

This means (1) your survey sample may not represent the real world, and (2) your result may be based on opinion and not fact.

BUT, the question that we need to ask ourselves is…

…Has the time come for us to examine, which of the agile practices have a +ve correlation with project success and which are only rituals with no impact on the project success?

]]> http://setandbma.wordpress.com/2012/01/03/agile-projects-more-successful/feed/ 2 Udayan Agile Project Success http://setandbma.wordpress.com/2012/01/02/agile-contracting/ http://setandbma.wordpress.com/2012/01/02/agile-contracting/#comments Mon, 02 Jan 2012 11:33:44 +0000 Udayan Banerjee http://setandbma.wordpress.com/?p=1598 Read more]]> Irrespective of what the Agile Manifesto says (“Customer Collaboration over Contract Negotiation”) we do require signed contract for ANY medium to large software outsourcing engagements – and that includes agile projects.

Why? Because when there is a commercial arrangement between 2 parties for delivery of any service where a significant amount of financial transaction is involved, there needs to be a clear agreement on:

1. What is the service that is going to be delivered and what will be the charges for those services?
2. What happens when things go wrong?
3. Do’s and Don’ts of how the interaction will happen

So, any contract for agile project outsourcing also needs to answer these points. But, how will an agile contract be different from a traditional software outsourcing contract?

This Post is based on…

Major part of what follows comes from the whitepaper Agile Contract Premier by Tom Arbogast, Craig Larman, and Bas Vodde. I recommend that you read it.

I have also used some ideas from the following posts:

• Agile contracts – Alistair Cockburn
• Contracting Agile Projects – Jens Coldewey (Cutter Consortium)
• Agile Contracts – Allan Kelly (InfoQ)

Let us see what these practitioners have recommended.

Is it possible to have Fixed-Price, Fixed-Scope (FPFS) agile contract?

Yes, it is possible but it should be avoided.

• Requirement specification that is signed off is almost never what is actually needed
• In an effort to deliver something within the constraints of price and scope, suppliers will often degrade the quality of their work – reduced code quality, do less testing etc.
• Price include large risk contingency – this premium is usually hidden in the effort estimate

As a result, the customer may not get what they want and supplier may lose out because of changing requirement.

How can the supplier make such project work?

• Use people with experience of the domain and the technology to estimate the effort
• Clearly lay out the acceptance definition or the definition of “done”
• Ensure that new requirements only displace existing requirements if they are of equal effort
• Decide how additional requirement will be charged

FPFS contracts are common where there is low level of trust between both parties. This may be a starting point in the engagement and it the project is successful more flexible contracts can follow.

What are the options available for Variable-Price, Variable-Scope contracts?

Such contract normally starts with a Master Services Agreement (MSA) which is more like a rate card. The rate may be for people deployed, cost of each iteration, function point or story point delivered etc.

Since we are talking about variable-scope, there will not be any detailed definition of scope. However, there may be an overall cap to the total price of the contract.

Some form of an order may be released for executing the next iteration or next couple of iterations which will have a clearer definition of scope or backlog.

To cover the risk the contract may be terminated after completion of any iteration – agreed termination charges may have to be paid.

Can you have a completely transparent payment model?

Yes, if you follow Toyota. It is called the target cost contract. They follow this five step process:

1. In collaboration between customer and supplier, identify, analyze, and estimate all possible project requirements.
2. In collaboration, estimate the cost of change or scope increase during the project.
3. From these two elements, establish the target cost.
4. Calculate target profit, based on target cost (for example, 15% of target cost).
5. Share all details and results with customer.

The idea is to have a trusting relationship where pain and gain can be shared by having a mechanism to adjust the actual cost based on the changing scope.

How do you protect against things going bad?

This is clearly the domain of the contract lawyers. They are supposed to ensure that contracts are drafted in such a way that suitable clauses are in place favoring their clients.

It is essential that non-lawyers involved in negotiating the contract understand the lawyers point of view.

However, one of the key premises of agile methodology is that the project risk is reduced through iterations and early delivery. So, it is strongly recommended that lawyers working on such contracts study and understand how agile method reduces risk.

This can help in significantly simplifying the contract.

Successful projects happen not because of the contract but because of many other things including collaboration, transparency, and trust. There are many natural roadblocks in the path of a successful project delivery – the contract should take care not to add any more roadblocks.

After all under normal circumstances everyone’s number one priority is to deliver a successful project. (There are situations where some people may want the project to fail.)

Steve Jobs, the genius is no longer with Apple.

Would you like to take a bet that within next three years, Apple will not be able to come up with another game changing innovation like iPad, iPhone, iPod, Mac or Apple PC?

2. Google goes social

Paul Allen says Google+ growth is accelerating and passes 62 million users, adding 625,000 new users per day and will probably have 400 million users by end of 2012. Whether this will threaten Facebook or not is less important than how this is going to affect search result.

Google knows much more about us than we can imagine – sometime you may feel that it can even read your mind – it is scary.

3. Microsoft chooses Metro UI for Windows 8

This bold decision is either a make or break for Microsoft – well not necessarily for Microsoft but for their OS business. If people reject it then Microsoft can say goodbye to mobile and tablet OS. But if it gets accepted then surely there is a chance that they will go on to be a strong player in both phone and tablet OS market.

Mobile and tablet UI needs innovation and Metro UI may just be that.

4. HTML5 has won the mobile war

What is going to stop HTML5, especially in the mobile? All leading players have adopted it – Apple, Microsoft, Google and now even Adobe. Have you seen the HTML5 version of Angry Bird?

Yes, HTML5 has won – would it have happened if Steve Jobs had not refused to allow Flash in iPhone?

5. Watson- Breakthrough in AI influences Google

How big a deal is IBM Watson winning Jeopardy!? It is just another milestone like Deep Blue beating Kasparov in chess which did not have any game changing effect? What is more interesting is how this has affected Google. Just after Watson won, Google has started replying to your search query with an explicit answer and it is continuously improving.

Are we moving towards an era where there will be an all knowing machine which will answer all questions?

6. Motion sensing technology comes of age

Which is the “Fastest-Selling Consumer Electronics Device”? No it is not the iPhone or the iPad. It is, according to Guinness Book of World Record, Kinect for the Xbox 360 which sold an average of 133,333 units per day, for a total of 8 million units in its first 60 days on sale from 4 November 2010 to 3 January 2011. Microsoft seems to have made significant breakthrough in motion sensing technology.

Is this going to be one of the key building blocks of required for a household robot?

A. No Facebook IPO

This is really an event that did not happen. Why did it not happen? Is it due to the launch of Google+ which spoiled the party, or the informal valuation of Facebook already too high?

Or is this a sign that social networks has less influence on buying decision than what people would like to believe?

B. Nothing on Cloud Computing

I cannot think of even one event in cloud computing which is worth a mention. That by itself is worth a mention.

Is cloud computing losing its value proposition?

Other not so significant events

Significant product launches

• Android 4.0, Ice Cream Sandwich
• Windows Phone 7.5, Mango
• iPhone 4S
• Galaxy S2
• iPad 2
• Kindle Fire
• Google+

Merger, Acquisition and Strategic Partnership

• Microsoft purchased Skype – $8.5 Billion
• Google buys Motorola Mobility – $12.5 Billion
• Nokia and Microsoft join hands

Patent war

• Oracle suing Google over Android
• Apple-Samsung patent war

Related Articles

• Top 10 Technology Events Of 2011!
• Infographic: Top Tech Trends of 2011
• Top 15 Technology events in 2011
• Top Tech Moments of 2011
• Technology 2011 in Review: Highlights and Lowlights
• Technology Highlights Of The Year (2011)

Agile@Scale ≠ Agile@Manifesto

Why do I say that Agile@Manifesto cannot be scaled?

Apart from what is explicitly stated in the manifesto, there is an unstated belief that “any” software can be developed by a small group of highly talented & motivated individual as long as they are sitting within shouting distance, have continuous access to people who can decide what the software should do and they can work the way they deem fit. This belief is elaborated through 4 value statements and 12 principles behind it. These 16 statements can broadly be classified into 5 categories of “how to” or “preferred method of” …

1. …Interaction and Collaboration (4)
2. …Measure of Progress (4)
3. …Responding to Change (2)
4. …Forming Self-Organizing Team (3)
5. …General Gyan (I mean advice) (3)

However, when complexity increases beyond a certain point, it becomes infeasible for a small collocated team to handle it. The reason can be many. For example, you may not find enough people like Dennis Nedry (Jurassic Park) “…who can network 8 connection machines and debug 2 million lines of code…”

Or, you software size may become much more than 2 million lines of code.

Or, you are not able to, for whatever reason, to assemble the whole team in one location.

Or, you are unable to find “business people” who know everything about what is needed and can take an instant decision.

I am sure you can think of many more reason of why enterprises have to go beyond one co-located cross-functional team.

When you scale, you will have multiple teams and they may not be located in the same place. So, let us examine the statements in each category and see if they can be applied in the context of a large and distributed enterprise engaged in software development and what their limitations are.

Interaction and Collaboration

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Business people and developers must work together daily throughout the project.

When you have teams distributed across multiple locations is it possible to function effectively without a clearly defined process (which everybody understands) and without having a tooling & technology infrastructure (which facilitates interaction among individuals across teams)?

When you have the involvement of multiple organizations, is it possible to start work without a clearly defined contract?

When you are targeting applications which potentially have thousands of users, will it be possible for few “business people” to define what the software should be? What about those pieces of software which is only interacts with another piece of software – what role will “business people” play in specifying them?

Is it always feasible to get the right “business people” to interact with the developer on a daily basis?

In short:

1) Tools, processes and contracts are the backbone of any distributed large scale software development project. Without them interaction and collaboration will collapse.

2) To say that you need only business people and developers to complete a software project is very simplistic. You need specific expertise from different fields like usability, architecting, performance testing etc.  

Measure of Progress

• Working software over comprehensive documentation
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.

If “working” and “valuable” software means “potentially shippable” software, then can customer always take continuous delivery of such software?

In a complex project which has many components and tiers, is it always technically feasible to partition the application in such a way as to deliver “working” or “potentially shippable” software?

Can you take up large scale software development without comprehensive documentation of all the interfaces – interfaces between different software components – interfaces between the human and the system?

In short:

3) Slicing a complex software project into working, valuable software may not always be feasible. Attempting to split it into testable chunks is more practical.

4) Measuring progress only through working software is too limiting. There are so many other things that we need to keep track – Performance tuning, UI design, Prototyping, Code refactoring …

Responding to Change

• Responding to change over following a plan
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

In the real world where the delivery of the software is tied to many downstream activities – is it always feasible to change your plan?

Can you always makes changes to the software late in the development based on changed requirement and still guarantee the reliability of the software?

In short:

5) Any change that is required to be done on already developed software has potential side effect. Any decision to incorporate such change needs to carefully weigh the potential cost and benefit.

Forming Self-Organizing Team

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Is team of motivated individual always sufficient to get the job done – doesn’t skill, experience and knowledge play a role?

Is there any guarantee that a group of motivated individual will always self-organize into an efficient and cohesive team?

Is there any hard evidence to support the statement that “the best architectures, requirements, and designs emerge from self-organizing teams” – especially when we are talking about many teams?

Isn’t “maintaining a constant pace indefinitely” a utopia – haven’t we heard of things like loss of interest, fatigue, boredom, attrition etc.?

In short:

6) It is naive to assume that any team of motivated individual will always self-organize. The team may require mentoring, periodic review of effectiveness as so on.

General Advice

• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These are good advice and can be applied to anything.

Finally

So, if Agile@Scale ≠ Agile@Manifesto, what is it?

Since we don’t have any well accepted definition of agile to fall back on – we need to go by what the popular opinion is.

Everybody agrees that agile means “iterative development”, “progressive refinement of the requirement” and “emergence of the design”.

Most people want the teams to be “self-organizing” but some people are totally silent about it.

Many people feel that there is more to software development than just “working code” and we need to look at how the software development gels into the overall enterprise context. There are also suggestions that we should borrow idea from traditional software engineering techniques where appropriate.

In short:

As long as you…

1. …Develop software iteratively,
2. …Have multiple teams of small size and allow them to self-organize, and
3. …Do not try to document the complete requirement and design upfront

…you can assume that you are following Agile Methodology.