Can People Oriented Companies replace traditional Companies?

Agile is a shifting paradigm moving from a formal value to more informal and human values emerging the power of a company as a group of people that collaborate and delivers following some common sense rules.

I'm just back from another Scrum training session happy to understanding a new lesson learned. I'm reporting here what the training's participants deducted from Scrum and Agile generally.

One of the main concept in Scrum is the Team: Team is the one that is responsible to make plans, to organize the sprint and to deliver something potentially shippable at the end of the Sprint. A team directly work with the Customer - in scrum called Product Owner - that knows what is has to be implemented first because knowing its ROI. A customer can prioritize features, remove impediments, and make the team's life smooth. The combination of a self-organizing team and the customer is the main benefit; no more people should be stacked between them.
Nor project manager too. The unique facility is a facilitator - the scrum master - that is one who is responsible to making things happen.

A company is a group of people instead of some processes and archetypes that formally keep things consistently.

How do values are shifting from a formal and bureaucratic Corporate to an efficient Company?

In a standard company, typically people feel frustrated, living every day as a personal milestone with the focus of careers and then money. Careers involve a mindset strictly focused on some problems, increasing specialization and competition between colleagues. The competition brings up jealousy between person and jealousy outline irresponsibility: "if she's better than I and I'm jealous, I'm not responsible of it!" Inside a vortex like this where people work independently, customers suffer that everything should be planned with a contingency in mind, thus generating extra cost. If the contingency is not enough to survive a crash, a backup plan is provided as a wonderful tool to save the bread crumbs of the project.


In a different company, people work together sharing the "you as a team" statement. This creates a group responsibility where all the active members share the same objective and work in the same direction. People should be honest and had transparent conversation each other. For the corporate this let everyone knowing the other avoiding specialization and promoting a distributed knowledge where there are people who know better a topic (the old specialized) and other less. This maintains a sense of being the corporate with a clear mission. The opportunity to discuss freely without risk, move a relation with the customer from a contingency oriented approach to an early knowledge of what is going on: day by day. Backup plans are not need because knowing that the future is full of interesting problems, the first things to be implemented are the most important in term of return of investment.

I'd like to thank Giovanni (1-2), Gaetano and Serena for the comparison between the two models and formalization of this during my training in Florence. The things I'm mentioning is what happening in some company I'm introducing Scrum and Agile generally.

Hackable Architectures makes Sense: Is architecure for People Interaction possible?

Usability has evolved in practices like interaction design, social design an others. An architecture should evolve with the system letting mash up to be easily created, managed and removed. This is a way when thinking architecture an architect should take care that one principle of the architecture should be hackable. By hackable I mean do things in a "informal" way, where mash up or enterprise's mash up are activating architecture blocks.

Internet has become a great place where people exchange data and interact to evolving work in an efficient way. Interaction design, usability, and other disciplines are discovering a pattern to make applications people centered. This kind of approach is even more driving software conception having people in mind instead of technology and technology is the facilitator tool to address this kind of approach.

Software architecture and Interaction design fits together and melt as needs. Re-usability is required not only thinking on architectures even thinking on people that are using the system too.

Architecture and component interaction is typically forced by Use Cases and is not so flexible to adapt different evolving usages of the system. Architectures should be hackable to adapt user needs.

Hackability of a components includes several point of view:

• business view: what business feature can be reused by a component;
• calling view: which protocol is exposed by this component, and how can be called by mash up
• context living: how do a component fits in a context while collaborating and in other context when reused, who declares it and how?

Sense is promoting the concept that a Service is everything inside a physical and logical architecture: components, frameworks, machines, application server etc. are services.

Sense's services can be exposed over several protocols including http (xml-rpc), http (json), iiop, jms. From the protocol point of view, Sense lets services to be in some mash up; it doesn't matter whether the mash up is at client side or server side. Service's context before and after invocation is updated in Sense by the application of crosscutting concern that is intercepting a call to a service in a particular context and are enriching the incoming and out coming call with context specific information. This is gotten through the definition and the application of Emotions that are though as aspect that crosscut in an architecture.

Can a Perpetual Beta approach be managed with Scrum?

Scrum is a self-managing techniques that help software to be packaged iteration over iteration over a set of business critical feature. The iteration approach suites well to implement and release bunch of feature ready to be launched to the market. In mondora we focus on a Perpetual ß tool that helps us in finding and maintains the right path for the goal.

In mondora we're working with Scrum for several years, and we find it useful to log and organize on a sheet: the process, the actors and the things produced iteration over iteration. This helps me and all parties during the development how us in mondora are approaching industrial software development: in a really open way.

The archetypes we produce are refined iteration over iteration; for example, while discussing the Sprint at the Sprint Planning meeting we try to figure out how the next feature implementation will fit on an architecture and we will produce some architectural document.
A set of feature is committed for a sprint, and the industrial approach stages directly the alfa version during development time. Because we're working on features, we're focusing on statement that creates value and at the end of a Sprint we're ready to launch them as a Beta feature.

This happens iteration over iteration.

This only because Agile focuses on the idea that everything in a sprint is "something potentially shippable." We then stage the next sprint and fix all the bugs in the prior consolidating those beta services as stable services and releasing new beta services.

This happens Iteration over iteration.

Every time, every day we're looking at our Perpetual ß scrum sheet tool to know how, what e who is involved in the process and which will be the delivery. Of course, our tool is in ß too, and is growing day by day.

Tool is available to download here: mondora-perpetual-beta-scrum