Mickaël’s Weblog

This week, the team get a training on Scrum. The goal was to introduce more agility in our development methodology. After this training, managers decided to use Scrum as Agile methodology, starting in 2 weeks for our neqw internal release. That sounds good.

The team is about 18 developers and QA engineers. Scrum recommende to have about 7 folks per group. This imply to split the team into smaller groups. The current oganization is really not agile; this not so suprizing as we kept the same organization for around 11 years and we are Agile practitioners only for 3 years. So the team in splitted into 3 blocks: QA and 2 development groups (business and platform). My concern is that we keep the same organization on re-grade the existing manager as ScrumMasters. I think this is faking Scrum for 3 reasons.

First, teams are supposed to be cross-functional, which is not the case today.

The ScrumMaster is supposed to be a facilitator/moderator and contribute to the features development as the other members of the group. The existing managers do not have such contribution. More over the ScrumMaster is not supposed to have any authority, which makes very difficult the association of manager and ScrumMaster roles for one person.

And last; self-organization of the team is a fundamental of Scrum. I do not see any of that in a re-organization fully handled by managers.

I hope we will go throw a different path: let the team re-organize itself by involving every members and do not fake Scrum.

 I see often managers stretching their team to acheive goals as early as possible without any middle term or long terme appraoch.

Achievement is important but you have to be less productive at some point –take a breath — to get better acheivement latter. Here are some example:

• training and team’s skills ehancement,
• change a tool if you are reaching the edge of it
• do not assign storyes/task on a specific area always to the same developer for productivity reasons
• reduce tests (automatic or not) and focus exclusively on coding

Here is the fisrt post of a series to talk about my vision on Enterprise Applications.

What is an Entreprise Application?

Oren get a very good definition of what it and what it should not be : an enterprisey application in his post Enterprisey vs Enterprise Software :

Enterprise Software - A common term used to refer to systems that usually run a core part of a business. Often those are mission critical systems, which interact with many other systems in the organization in many interesting ways. Enterprise software is considered hard because it often need to mix technological capabilities with the business logic, and be flexible to handle changing conditions as the business evolves.

Enterprisey - This is a derogatory term, used to refer to a system whose design or implementation is overly complex compared to its supposed function. Often the term refers to the usage of anti patterns such as Everything is configurable, Executable XML, etc. Those systems are consider bad because a simpler design or implementation would have achieve the same purpose, at far lower cost, with greater maintainability overall.

Such software are addressing different markets: CRM, ERP, Fincancial, HR, Payroll…etc.

What are the different Business Models?

The Enterprise Application Platform is in itself very interesting has it is facing real technology challenges (I will leave discussion on them for future posts). Some of these challenges are depending on the bsuiness model of the Enterprise Application (EA). Most of the famous EA are using the very common SaaP (Software as a Product) business model, couple with some Professional Services or strong partership program. A new model is raising : SaaS (Software as a Service), a good example is salesforce.com. In between you have a continum of hybrid business models (that are not better or worst). More over I’m sure I’m missing someother well know business models.

What kind of depedency?

Extensibility is key for EA, as these applications are at the core of the enterprise,. All companies are working in different area, have a different size, in different country with different law…etc. The customer have to introduce into the system there own process to be efficient, and they will taylor the system.

Tayloring raise the problem of upgrade. If you are in a SaaP model, you will have to deals with upgrades and/or migration. In a SaaS model, you will do continuous integration and deals more with evolution than upgrade.

The RDBMS independancy is of high interest for a SaaP model, and almost irrelevant (at least for the customers) in a SaaS model.

What is the right business model?

None…or all. They are all valid, just different. SaaS has a good trend now but ASP failed some years ago. We will see if this trends is confirmed in the coming years, and if it is adopt by Fortune500.

Anyway, the important point is that the architeture of the platform clearly depends on the business model.

I’m working (for 11 years now) in the development team which develop an Entreprise Software. I started as developper, i’m now architect and I’ve lead the team for 7 years.

In the 90s, there was absolutely no platform, neither framework to buid Entreprise sofware. This is no more the case. Microsoft deliver CRM, Sharepoint and incudes now in .Net framework capabilities required by Entreprise framework as workflows, MVC…etc. The SaaS plateform as salesforce.com also provide such capabilities.

Oren have written a very interesting post on his vision of entreprise platform. His points on extensibility and deployment are simply brilliant. So I decided to start a series of post on this topic to bring my humble contribution. I do not know yet how I will split the different post as there is lot of thing to write about this topic.

We are doing daily stand-up meetings in our team. This is one of the agile practices that has been setup (we are doing also test-first and time-boxing). These agile practices have been introduced progressively as the company decided to go on this path.

The initial goal was to improve internal communication inside the team on the project. I’m not satisfied with the result regarding our goal. Of course, every one is a little bit more aware of what’s going on in the project, but the organization of the team impact strongly the results. The team is in fact a composition of silos, and the daily stand-up is just an enumeration of information on really different areas. Finally there are very few cases where appears some shared information (I mean, information that is useful to more than only one guy).

In a certain extend, it does not provide the feeling that we are all on the same project. At least, folks have a rough view of who is doing what…which is not bad.

Today, Jeremy D. Miller have written a post that exprerss exactly my feeling:

A team building a feature is far better than a group of individuals doing tasks