Twitter is not a new form of Journalism!

Last edited by on June 27, 2008 5:27 am
Microblogging generally can be seen as a new way of exchanging information between user, but what happen where all the microbloggers share a topic during a public event and talk about it. News propagation is more viral that people can think, and I’ve had a demonstration, directly and live in Varese at Università dell’Insubria during the Enterprise 2.0 forum.

This is what happened to me last Wednesday in Varese at the Enterprise 2.0 forum. There were lot of people and an internet connection. Some of them I’ve already followed on twitter because they twits some good micro news I really appreciate. I know Luis Suarez and follow him on twitter since a month; Luis was one of the speaker at the conference. Since the first moment at the conference me and Mike started twitting in an “informal” way our status at the conference. Twitting it realizes that all our followers knewn what’s going on. Luis saw it and agreed with us it was nice to track the entire conference on twitter. We agreed on a tag (unique maybe) to tag the conference and we decided #e20forum. Well the word has spread and all the Luis follower, Mike follower, and mine follower have known we were ready and already negotiated how to track the conference. Some of them were in the room and some of them were on the speaker’s table.
Well, a new pool of journalist has been configured without paying without asking to do that job.
During every speech on this underlying channel, everyone has published all the information considered important and the cloud of news magically appear with many really insightful information.
Someone has twitted some real time pics, other their slides about the topic they covered. It’s amazing to see how the day time line was well documented in a collaborative fashion, without organization, and with the participation of the speaker and the public without knowing before. It’s amazing to think about old style journalist. Some of them sat near me that were putting words on block notes and now are reordering their ideas and how I can go to a Summize – a Twitter Mash up – and know what happened and know what is still happening around it.

This experience was the most important experience to me that significantly defines how the world is changing, how people shall be connected each other and which is the path of the communication. 

All the speeches were really good and what happened under the hood was really in a 2.0 fashion making a new culture tangible. I would like to thanks all the twitters and twitpicsers for the moment they gave to the Enterprise 2.0 forum, and I think this is a real Success Case of a new form of Journalism.

Last mine consideration is that twitter and summize are only tool, and the new form of journalist is the way we collaborate with all the people related to us. It is insightful to see how people in my network, perceived the conference emphasizing some topic I didn’t see, and how I realized better what was going on from a collaborative culture.

 

Have Agile and Enterprise 2.0 something in common?

Last edited by on June 15, 2008 5:34 am
Nowadays companies are thinking to promote a social graph inside the corporate instead of hierarchies. This is common to agile practice where all the developers together are the project manager.
Agile Manifesto and 2.0 approach have something that sounds really similar: people. People are the key in both Agile and in Enterprise 2.0.
Agile Manifesto outlines how project will be managed in a more conversational way, where values are the driver in software development. An enterprise 2.0 is focusing on people too, where a company’s seen as a multitude of people that are working together, having a relationship that helps the system growing.


Currently companies are focusing on process and tools over comprehensive documentation. Currently companies are following a plan that enables negotiation between Customer and Provider. 

Agile shall make companies focusing on individuals and interactions. Agile focuses on working software that is responding to changes. Agile establishes Customer as a Partner through collaboration.

The enterprise 2.0 shall make companies focusing on relations between individuals and interaction over essential documentation and a fully functional company. The Enterprise 2.0 is responding to change and establishes Customer as a partner and colleague as a Friend.
Enterprise 2.0 focuses on adopting similar values expressed by the Agile Manifesto to corporate where the delivery is the corporate itself and not only software. Corporate, like Agile management techniques, trusts on human ability to create and maintain hi-value relations.

Both of the two mentioned approaches create a more conversational environment where colleagues/developers/partners can share their opinion their problem each other. Informal relations are brought forward to formal relation, where the main opportunity is to evolve something together.

Agile Development: why small iteration in big projects?

Last edited by on June 7, 2008 5:44 am
I’m just back from a training about Agile and Scrum and one question made from an attendee was: 

You said it’s hard to success in a big project without implementing small iterations; I’m skeptic about it. How do you manage big time line as short-term iterations?

Think about the Pareto Principle also known as the 80-20 rule that states that 80% of the effect come from the 20% of the causes.
Currently Agile is addressing that development effort should be spent only on the business direction: you need to implement something that is really valuable for the customer. This states a feature driven’s approach instead of others where everything starts from a feature, and everything ends when the feature become something potentially shippable.

From the Pareto Principle:
the 20% of features implements the 80% of business

In a Project, big 100 the investment is 100 a the total of returns are 100.


From an economical point of view results are reached and the mission can be thought as accomplished. 

Watching it in a different perspective thinking that the 20% of efforts (energy/investment/etc) gives the 80% of benefits, we can think that the effort for getting the 20% is higher than the benefits.

By splitting 100% into five pieces


Different benefits could be gained:
- after 20% of time the 80% of ROI is collected;
- after 20% of time investment could be re-planned in a more flexible way
- after 40% of time the 160% is gained (more than the 100% of time in the previous approach)
- after 100% of time 400% is gained

Finally, product and business grow together iteration over iteration requiring that feature must be ordered having Return Of Investment in mind and having the most important feature for ROI implemented first.

Pareto principle involves a feature oriented iterations in thinking business and in approaching a development strategy.

Perpetual Beta services

Last edited by on June 2, 2008 5:38 am
Today, online services are in perpetual beta since years and it sounds a bit strange for an engineer that delivers software.
I mention Flickr for example that has been in beta for several years.

Going deeper on why perpetual beta and not stable release, I see the way software is implemented is changing. Developing over small iteration requires to split software into feature and components into services: smaller is the iteration (1-5 days) more is the dependency to a service crafting approach where services crosscuts around the architecture by improving the architecture. Small iteration produces few lines of code then small bugs, and test is shortened too. This makes the software to change frequently by increasing stable services and beta services over time. 

Development to production small iteration approach gains lots of benefits like:

  • rapid return of investment;
  • rapid change when competitors launch the same service;
  • user centric needs;
  • rapid solve possible bottleneck with short downtime;
  • rapid scaling on business continually iterating over new functionality.

This type of approach is making previous 3-4 iterations stable and well tested and the other still in beta because they’re really in beta.

Adopting short iterations, requires a new mindset in achieving Software Architecture: SOA is an example where what is implemented is Software broken into Services that implements features.
This means beta is for feature.
This means that business feature is still in beta, and consolidates over time when users thinks they’re stable.

 

 

Flickr is again an example.


It has been qualified as beta for several years and this is the approach of big ventures that are delivering feature iteration over iteration investing money iteration over iteration and driving behavior over user requirements. In facts, to organize what service will be the next released service, Flickr and the other players are creating communities of users that evaluated and propose new behavior discussing on it.
This is why modern web site are proud to declare “beta” for 2 or 3 years and to move to “gamma” after 4 years. 

It is more a business practice than a software practice.

I’ll continue this topic by drilling down my mind map to focus better on how SOA, Virtualization, Agile are related.
Stay in touch!