Frank Mondora

Agile: "I thank you!" as mindset

2008-10-26T11:18:00.007+01:00

We're used to thank someone when we are relaxed; when we are working to gain some objectives, we start forgetting to thank our colleagues and we're focused on the delivery and not on the informal relation. Formalities are taking over, and titles are governing instead of relations, passion and other emotive behavior typical of people hides.

I see this as one of the big problem on a committed agile team that is highly committed and is releasing often; delivery is every day near the door, and commitment is really high since the first day. A formal title dominates to the relationship, passion is translated into the word work and stress is continuous.

I like to approach this kind of problem by doing a daily debrief in every team I work with: we start the morning by planning the day and believing what is a concrete result for the day, and we close the day by packaging up all the work by committing it to the version control and thinking about what's coming next.

I usually debrief teams every day before teams' player is leaving the office at a fixed our 6.30PM. This lets individuals to relax a little bit, to focus on what is done and to focus on what can be done the next day. This kind of approach is a formal day closure where we brainstorm about the day. It's an informal event differently from the morning daily scrum where there is also the product owner, and it takes no more than 5 minutes each day but gives some benefits like:

work less than 9 hours a day;
stay focused during the day to achieve the daily milestone;
be sure every day everyone can remove every unpleasant thing matured during the day in an informal way.

For me and every person inside the team, this is a good opportunity where all of us can realize the power of individuals from the group perspective and start thinking about each one. I see some thanks fly around only during this kind of informal meeting and, when thanks is a reputation system better than all those you can find around internet.

A daily based thanks opportunity is the best way to achieve self-esteem and then increase the reputation of each one in the team; the more a team is growing the more it increases the reputation of all the people inside it. Reputation is something that builds from small action and models the different attitudes of a person making her confident what the others are thinking about her.

The things I'm presenting here is one of the techniques I'm adopting to make individual to act as a team and to stay focused. This kind of tuning is mandatory to search a group personality and moreover to enrich individual personality. During this type of meetings I'm acting as a facilitator and not as a stakeholder or as a troubleshooter; my role is to help in maturing self-confidence about the work and to stay committed daily.

Team players know I'm not so good to help them, they see me only as a curious person that would like to share the day and to breath the same air: someone outside that can make a team member being a team and can bring fresh air and harmony inside.

I will continue more on the topic of a daily reputation in the next posts.

You as a team: is it so vulnerable?

2008-10-10T09:10:00.009+02:00

Project management practices introduce the coordinator of a project who's main responsibility is to manage and facilitate the project flow removing any impediments. Agile introduces the concept of self-organizing teams, where all the people manage themselves.

Project managers iterate on a Planning sheet and even a Gantt chart updating information on it, while Scrum identifies a Sprint Backlog as a driver for the current sprint and the product backlog as driver for the project. While things are pushing with a rhythm, team is delivering and project manager is governing each situation everyone is happy and the project feels good; but, someone in the team can lose the control of what is being delivered. It doesn't matter who is responsible for the matter, but the situation starts making all the rest suffering until crisis. This kind of problems emphasizes and become bigger time over time: like what happens in a domino.This can be still managed at last by the Project Manager that will solve the problem removing any impediments. But, what happen when the domino starts from the Project Manager or involves the Project Manager too? This is a case of the unreliable management, where the perception that a problem is occurring is not emerging and emerges only when the entire project is failing. Traditional software management practices tries to solve this problem by creating an hierarchy inside teams, where on top resides the project manager, than the team leader, and then all the others.

The team leader is clustering around the project manager to maintain good health for the project. This is a good way to establish a balanced monitor in the team management staff. But, what happen where the cluster is itself not reliable? Well, the domino effect occurs again. Agile software development is addressing this lack by promoting the entire team as a project manager and bringing a way to share daily a snapshot of the project feeling. A Sprint backlog is the driver for an iteration (Scrum identifies a sprint as an iteration), a sprint backlog is written by all the team members and is estimated daily. Every day all the team's player must re-estimate the work in progress with the hours remaining for the specified task, and every day the team must respond to the customer (in scrum is the product owner), on what they have done the previous day, what they will do in the current day and which is the problem they're finding on their way. The daily meeting is useful for the team too, because they can observe every day the remaining work to do and they can start anticipating some problems.

What happen if someone in the team is exploding?

The problem is faced in two ways:

1) At least through conversation during the daily scrum, when the exploders is not able to commit a task because his problems;
2) Formally by watching the sprint backlog and seeing the team feeling is not so good. Estimated hours should decrease while the time is passing; if a team is not feeling good, the decrease speed can be less than the expectation.

A daily meeting involves, three actors: the scrum master (who makes thinks happening), the team and the product owner. Every day one of them, can feel how the project is going formally - through the spring backlog - and informally through the daily scrum conversation.

This is the way Scrum and more generally agile is avoiding the Single Point of Failure where a Project Manager and a Team Leader cannot perceive a project failure.

A good Project Manager will discover that she is already doing something similar with her team. Scrum is all about common sense and shares the experience in managing complex situation. The Sprint Backlog is the driver for the sprint and to gain benefits must be updated regularly daily.

The daily estimation can produce a graph (in Scrum called Burndown chart) that visually represent the hours remaining. This can be good to check with only a sight the entire feeling of the team.

A fistful of quality code: me and my colleague

2008-09-28T08:52:00.007+02:00

The title can be more appropriate for a Spaghetti Western movie but is appropriate in each situation pair programmer are surviving theirs daily's milestones enjoying work and maintaining a good environment outside them. "Pair programming" is identified by two words: Pair and Programming. Every developer knows exactly what is programming, but a pair requires some confidence with humans too. In this post I'm focusing on the Pair word of Pair Programmers, analyzing some successful factors like the Rhythm while working.

Like two cowboys a pair must work with a single objective every day, watching each other and helping each other; the external environment is like the desert with rolling Joshua trees and with condors flying, waiting, and watching for the next lunch hopefully with someone "freshly died".

Imaging all this with a Sergio Leone's music that is creating a more characteristic environment, where the rhythm is perceived watching the movie and listening the drum.
Two developers are in the same situation: they help together in finding the best solution for the daily milestone and they need to find out a perfect rhythm.
Like in a movie, some of them are the principal actor, and the other is helping in surviving the scene taking care about the stress and trying to keep her safe from external interrupts.
The main actor in a pair is the one who's typing on the keyboard and typically writing the line of code. In terms of development perspective the secondary actor has to discover bugs, to seek for documentation, to write documentation, to diagram, etc. While taking care of human feeling, the counterpart's job is to help the principal coder in doing things including stress management.
She has to know when it's time to take over and switch the scene acting as principal actor. The frequency of a takeover implies the actors to watch each other, taking care about the health of the pair and trying to keep it good every time.

This is reflected on the quality of the code produced: every scene is played by the less stressed developer. Thus, the other can relax a little bit helping the next small iteration.

In this post I've examined three intra-personal factors that help a pair in staying consistent and durable over time:

Rhythm: developers play the scene and the rhythm too. Rhythm translates is directly related to speed team. Without rhythm stress increases in one developer and low commitment increases on the other side. This is against the milestone.

Watch the watcher: developers should watch them as Person and not as developers; programming skill is confirmed line over line, and more humans' behavior (like stress) can easily hide. Watch the watcher if you want to be watched, is a protection guarantee for every developer that would like to work actively in a pair preserving her health prior to the colleague health.

Takeover when need: avoid to much stress exposure for your colleague? In software development stress is the first cause of low quality. Being the principal actor confuses the main developer and sometimes can drive to the wrong direction, then frustrating and then stress. When your counterpart is loosing her speed, grab the keyboard, and continue typing (of course at your speed). You'll notice that this rapidly debriefs your colleague making her reacquiring her rhythm and then asking the keyboard again.

In a next post, I'll discuss about the relation between rhythm and speed in software development.

2.0 series: what is the natural evolution of interaction design?

2008-09-20T09:07:00.006+02:00

Interaction design is a technique improving the web usability and user centered design to identify what is really need in a 2.0 online service and what can be forgot. In our tangible word this is already done by who's marketing goods and who's facing the customer directly. I'm thinking about Starbucks that sells coffee in a really good fashion or UPS that is facing customer with a professional front end. Starbuck's and UPS's employees are the direct face of the company to the customer, and they are a mix of professionalism and marketing. They know exactly what to wear, what to say, and how to make comfortable a situation with a customer.

This is coming into the Web Space, and has been discussed a lot at the Web 2.0 Expo in New York last week. The web 2.0 is improving with interaction design that focuses on doing only what a company is thought for and on forgiving extra services discoverable on the market. Interaction Design from Joshua Porter is the first step in this scenario, and now Christopher Fahey from Behavior Design is talking about Seductive Design where 2.0 services seduce the end user.
I think that is on top of the interactive design's principle from Porter, and it is introducing some marketing concepts in software development. In classical corporate marketing focus is to make some corporate services appealing and sexy. The same is happening with the ideas in seductive design where the focus is to create a seductive interaction with the user mixing images, videos, and behaviors. This with style and creating the desire and then pleasure that the service is creating. Services user experience is an emotion for users that are paying for a system. Everything is thought as potentially something new; the way to attract, to create suspense and to delivers a service in a professional way trusting who's at the counter side. Imagine a future's Apple product, is it in your imagination an unusable product, with bad colors and high price? That's because Apple has created a Product Service Factory that innovates in a real and sexy way.
All this is coming with Seductive design where marketing is becoming a cross culture like software development is crossing to all the roles.
Services will attract more users more they're sexy, and users stay with the provider for the quality of the service and for the trustiness that the company has created.

Do things with style? Is it still possible?

2008-09-10T05:30:00.012+02:00

Design has become popular in several context, and it is applied in applied arts, engineering, architecture, and other creative endeavors. Design is something cross to all the things around, and a good design is simply perceived without too much understanding going straight through the final objective.

Last years I did lot of things spacing from developing, architect, designing software to put customer ideas to market and I've learned lot of things about each activity I performed: for an excellent result every activity should have a good style and a good design. But, what a good style and a good result? To fast figure it out, if we think a picture of a car from a kid and from a designer like Giugiaro, they're, both, drawing a car with four wheels, and engine, some seats etc., but the main difference is that Giugiaro's car will seem more accurate and beautiful that the kid one. That's only because Giugiaro is a professional designer and the kid is just playing with a pencil and a sheet. Now, switching the metaphor back to everything we delivered in the past we can focus on the result and on the next improvement in term of style. Here is a list of key point when I'm doing things trying to figure out "a style":

Build only what is absolutely necessary

There is lot to do and if we do more than our potential, maybe we'll reach the goals, but lacking on style and quality. So, one of the first statement, when I approach something is to find out what cannot be done to stay focused on small portion and put all the energies there. This trend is notable in 2.0 where services focuses only on small things giving an idea of lightness and the refinement process improves iteration over iteration.

Quickly turn beginning users into intermediate

Think about a sexy girl! She creates interest without telling things; the viewer is not reading papers, documentation or watching podcast to be attracted by the girl. She is turning a beginner user to an intermediate fast creating the correct interest in doing things and maintaining the learning curve small. This is what in Agile Development, we call self documenting software: if it is sexy and appealing for developers can be learned fast without too much archetypes around: like a sexy girl.

Prevent errors whenever possible and handle the errors we cannot prevent gracefully

Good style is something appreciable outside the designer and style should be perceived rapidly. You can get wrong while designing, this is why on every small increment the heart of design should pulse to his target to check if it is good for it or not. It is not a way to pre-sell, it's a way to anticipate problems gracefully. Shouting every small iteration makes a good style growing.

Reduce and refine interactions and task flows until even the most complicated applications are clear and understandable

Refinement focuses on making things implicitly clear, in the way just watching them for few times, they're understandable. This is what I do, when I seek what cannot be done. This is not a technique to postpone work; it is a method to check if something is still available and need to emerge from the already available resources. Good style is made of few things because the huge variety of things is gone implicitly inside the design itself and is easily discoverable and understandable.

Adopt metaphors, better visual metaphors to explain the complexity and bring it to a human comprehensible level

Metaphors are the key to find out what is implicit in a context, and only with metaphors you can focus on what is really not clear. When thinking an archetypes a metaphor is a good statement to better understands, picture or diagram the archetype itself.

Ignore the demand of users and stick to a vision

Improvements are done through brainstorming and brainstorming should be stick to a vision, a common vision. It's important to stay focused on the purpose, and not to switch over ideas every user express.

These are only a bunch of rules; I'm learning from my experience. Surely some new rule can come in the next future.

Some 2.0 anti patterns in Development As A Service

2008-09-03T05:58:00.017+02:00

The main intent of the Software Development As A Service, is to outsource development to stay better focused on what is really producing value in the starting 2.0 pioneer's company.
A fresh and new idea is the real trouble of a Startup and most of the energy should be spent on that direction, while other problems are addressed trusting the services bought depending on the Service Level Agreement defined.

After a good experience in the 2.0 era in developing several online communities from the Service Provider point of view, I think it's time to share what I'm learning and the mistakes I'm doing in facing this kind of opportunities.

I'm calling those experience anti patterns because they are a good representation of what can be optimal in theory and is really ineffective in practice if the 1.0 culture is mixed with the 2.0 culture.

Embrace Software Development Company processes

Having the idea to implement all the software by delegating to a Development Provider, comprises the adoption of all IT culture of the engaged service provider.

This can be obvious a really proficient until the Startup Company is trying to figure its own development process asking the service provider to embrace and focus on its way of doing things.

This approach drives to two main drawbacks:

1. Startup company is now focusing ideas to development process that is not really creating revenue for its business;
2. Software development company is forced to change the way they do things, learning a new option in software development and focusing on the customer's process intention instead of customer business needs.

This moves the Startup's focus from the Business idea to development spending energy (and money) in thinking on gates instead of thinking on the time to market for even easier idea and Software development to produce process's artifacts (reports, well-formatted documents, etc.) instead of good software.

Focus cannot be easily restored because the current focus is to be compliant with the process. When choosing a Software Provider Company, a 2.0 startup should put in its decision table.
The way the provider works is a good point of evaluation and must be agreed with the Startup Company to avoid the process as the next collaboration's problem.

Identify a Service Level Agreement on each Service

Startup and Service providers should agree on both parties on how they're allocating or delivering services request.
A Startup Company should create milestones that bases the professional relation. Milestones are business objectives that potentially influences the ROI of the Startup Company, and Servicing company should base their SLA depending on the milestones objective.

A SLA identifies an interaction model where parties agrees to implement something that is really valuable; this creates a conversational and honest model where things go in the same direction and both.
The parties are focused on the goal. Without a SLA, a Startup Company is shifting to an investment protection system paradigm where energy are spent to avoid money loss. Without a SLA, a Service Provider focuses on service's accountability instead of service providing.
The more the Service Level is the more is the price for it. This simple rule can be extended in: the more on the service level of what is really indispensable the more a company can pay for it.

Easiness is not simpleness

A 2.0 application is a big mash up of Services around the network; in the 1.0 culture there is the idea of System Integrator that is responsible solely to do a kind of component integration.
Meanwhile in the 2.0 culture the idea of system integrator is hidden by the idea that services are available on standard protocol and then easy to integrate because it's just a javascript call or a bunch of ruby on rails lines.

The complexity of integration in 2.0 is the same of the 1.0, every integrated platform must be reliable, must work and have custom development associated. The big difference from 2.0 and 1.0 is that 2.0 integration is through services starting from the presentation tier, while in the 1.0 everything is hidden in the integration tier.

A 2.0 approach is to make the user interaction easier by leveraging on all the available technology: that's really complex and require great skill and good professionalism.

Re-DO to DO approach: talk and listen together

2.0 culture is pioneering, and fresh ideas are often not clear to be written as a strict requisite. It's easy to misunderstand what the customer is explaining and what the Service Provider is understanding.
Small iterations and a continuous conversational approach must be established to achieve the same goal. Customer and Service Provider have to thing that the counterparts are producing value day by day discovering things that are still unknown.

A 1.0 approach drives the customer to outline all the requirements predicting what will be, and in the most cases failing in some aspects. Failing means: redo the same thing. Consequences of the "redoing mindset" will be unable to launch the Startup's Services at each milestone. Redoing several times, breaks trustiness and team happiness.

A 2.0 approach is based on continuous improvement on things and from the failing paradigm moves to the Learning paradigm. Continuous improvement switch the mindset from stable services to perpetual beta services.

Conclusions

These are some of the things I've found from a first retrospective with all the involved players in my experience from the Provider Company. I'm sure this is only a starting point for the 2.0 anti pattern catalog and more will come from the experience.

A blog for a Startup 2.0 website?

2008-08-25T07:59:00.004+02:00

Having a website today is producing some value and not having it, is creating lot of penalties. Traditional enterprise web modeling has lost the concept of static websites for a more dynamic approach where the life of the company is perceived through the web too. Different navigation from the old fashioned menus is needed, user should move on the web site and interact with the website directly by categorizing and commenting all the contents on the website. Blogs are a good way to implement all those functionality in a modern way. Visitors should be able to browse content thought their interests and not through what company want to tell. That's why content's tagging is more important than categories and menu.

A blog entry can be seen as a content, with several information linked; hyperlinks are a good example on the power of linking things and menus are good samples on how contents can be organized.

But, this in direction and through the monopoly of the corporate. Thinking 2.0, contents are coming out from who work and even better can come out from the visitors too. External services like delicious or technoraty enable people to link pages and shares them across the net by tagging them. Thinking of contents as blog entries from the editor community, and tagging as an empirical way of organizing content lets a 2.0 start up company to find what is really important and how visitor are identifying it through the tagsonomy related. A user can browse the site, thought as a set of entries, in different ways starting from the old one through category moving to an editor tag browsing and facing it at the end to the visitor's tag apposed.

This is only because web site's fragments can be referenced with some tag. This can glues either an old fashioned web page, and a dynamic new page where fragment are linked by tags more significantly for the current visitor.

Blog engines like wordpress are fully customizable and have dozen of plugin to interact with entries, tags and outside services like delicious or technoraty.

The next move on the corporate website's chessboard will be to migrate the standard website to a custom blog having some of the blogging featured customized and having the community to work on it editing and tagging content's fragments.

Services vs. Components: Is it a death match?

2008-08-14T17:01:00.006+02:00

There's lot of misunderstanding between Components and Services: components are something that aggregates a product for a business behavior while Service is what is doing real business and it's remotely usable from who is really interested in the value added the service is producing.

Nowadays the term service is in every modern acronym (SOA, SAAS, SLA, etc.), and there is non clarification on what is a service and how it differentiate from old fashioned terms like Components.

The term Components come from the manufacture's industry where all those modules are used to build things. It doesn't matter if a car engine is manufactured by Ford or by Subaru, it is produced reusing some of the same components and it is not implemented from the scratch.
During the last years, the Information Technology approach has been to watch other industries and to try to implement all that has succeeded into software. Like in the manufacture, software components are a unit of software that provides business or technical functionality.
Typically they're self-contained and independently deployable. Thinking about a software component we're used to think to:

a specification (analysis and design) that defines the scope of the component;
an implementation with any invokable interfaces;
a module to be deployed (an EJB, a WAR, an EAR, a DLL, etc.).

A component offers its implementation through an interface, that's the unique way a component should be used.

Differently services are focused on satisfying business needs, on a consumer/producer paradigm where the service is producing something valuable for the business. A service can be thought as a set of components and differently from components. A service can be something else than a component. Instead of having an interface service allow the concept of API on different protocol and they can act synchronously or as event's agents.

Another big difference between Services and Components is the way they're reused. Going back to manufacture Components is stored on the shelf and is taken and deployed when necessarily.

Service, in an opposite direction, lives somewhere and is addressed to be used.
It's like going to the post office to send something instead of creating a post office in house.

An approach with components requires a new deployment, new hardware dimensioning and integration while a service approach is only focusing on integration.

What is making the difference?

The way the architectures are thought is making the difference, thinking SOA is benefiting the reuse of value added services and is accelerating the way software is implemented. Every architect is implementing a system, should think a way to make the application addressable and callable by other Service around the network promoting Service Reusability. In terms of business, Service reusability creates a new approach of doing business where specialized companies are providing something that produces real value as a service and is offering a large scale the service at a low price. Google, or salesforce.com or Amazon is again an example of the power of thinking SOA.

Is architecting a 2.0 extendable appliction the same old story?

2008-08-04T07:42:00.008+02:00

Architectures are following the way to be extensible, flexible, and easy to be maintained. A 2.0 scenario makes things growing on demand, starting with a small set of features and growing to a huge application with lots of other integrated application (mashup) and complex business logic. Everything shall evolve and redesigned time over time, feature over feature.

The best approach in delivering a modern application is to consider the application itself as a big mashup of the application. This implies, again, a multi-tier approach where there is something in the middle tier that executes something valuable and there's something in the presentation tier that orchestrates business behavior.
Thinking in the way we thought with Enterprise architecture based on EJB and other complex solution, the separation was into the presentation tier, the business tier, and the integration tier.

All the components should be divided into one of the above tears, depending on their roles, and responsibility inside the architecture. Why the separation of roles? Separation of roles can tune the architecture in several point with lots of combination. By implementing modern architecture on social communities, I've found important in differentiating the business tier from the presentation tier: as I do in enterprise architecture with high available technologies. Things and names changes, but the result from the architecture should be the same: having and extendable and flexible system.

The key concept in modern thinking is to separate services their API from their "social interaction" promoting a Widget as a visual coordinator of something is happening backward.

This brings out a reusable API, a first use of the API that is the Social Application and the versatility of the architecture. Having modern API exposed in several formats including JSON restful services, this enabled the idea on having the integration tier as the "presentation tier" or on the old fashioned presentation tier. The modern presentation tier is called Mash up and is really adaptable depending on the needs. If it is required that a machine should do something on the integrated platform (viz. flickr), it can be done at server-side as a restful service. If it is required to operate with some integrated platform visually, it can be called directly from the presentation tier. Yes, this is the first example of how flexible can be an architecture: I can choose to do integration on throttling on the service platform or to choose to go strike through the integrated platform directly from the client interface. This is gained only because, the integrated platform has been tough having the concept of API and that the Social Application is itself a big mash up of those interfaces. Making an API public or private is a tremendous business decision, and should be accurately agreed after heavy consideration. Having a public API makes other the reuse idea instead of the feature copy idea; this requires the company, should also have a clear policy on how integrators can use its API for their mash up. This will be a next big opportunity that 2.0 will create. Stay tuned.

Can People Oriented Companies replace traditional Companies?

2008-07-29T05:20:00.006+02:00

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?

2008-07-12T09:55:00.013+02:00

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?

2008-07-02T09:22:00.011+02:00

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

Twitter is not a new form of Journalism!

2008-06-27T07:27:00.010+02:00

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?

2008-06-15T07:34:00.011+02:00

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?

2008-06-07T07:44:00.000+02:00

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

2008-06-02T07:38:00.000+02:00

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!

Developer 2.0 - a software personality

2008-05-25T20:50:00.000+02:00

I'm just back from Almens (Swiss) after a day of talking about stuff on several things in mine interests with a good friend Tim Mackinnon. After some talks that gave me a better understanding on how architecture are changing, they're ready to be dumped on a blog entry.
Before start describing the 2.0 I need to go more in depth about the evolution of an Architect form 1.0 to 2.0
In 1.0 he is responsible for:
- the architecture of the system including component reuse (logical and physical reuse),
- finding patterns for problem solution, - driving the philosophy in separating concerns between core component.

Meanwhile, Developer 1.0 requires analysis and designs before writing a line of code, the 2.0 approach is starting from a business feature and instantly writing it. A 2.0 architecture emerges as the code's soul, like when a voice comes from the soul of kid. The soul must be educated, and the role of the architect should be as educator to an architectural approach by iterating over all the development content and all the developers while they're under pressure in releasing line of code. In this way, architects facilitate the emerge of an architecture thought as the Software Personality. With their new approach in linking developer 2.0 contents (code, documentation, feature, etc.) they're are creating those links that enforce the soul of software. Personality increases day by day, line by line, and architecture emerges with it and consolidates with it. Modern architects linking code snippets with tags of a specific context (architecture for example) are implicitly educating code with a personality. Code behavior is the feature implemented, and the old fashioned architecture diagram is an outcome of what is implicitly related inside the code by architects; both the logical and physical statement. The analysis of those links between things produces different graph of related things, and those graphs can be drilled down by following all the tags.

- architecture cloud -

The above diagram can be derived by analyzing tags and relationship between tags: architecture is a derivation by the tag graph inside the system. By having it expressed as a graph from the analysis of the system, it can be thought as an architecture cloud, where the most important component is bigger than the others and when dependencies between component are inherited from tagging. An architect 2.0 is responsible for creating the culture of tagging components to create the 1.0 hidden relationship between logical and physical components. This constitutes the soul of the application that must grow with the system day by day in a pragmatic way by adopting feature to code (as the voice) to the soul. I would like to go more in dept in a future post about the tool. An architect 2.0 should use for maintain upstanding a soul of a system.

Developer 2.0 - Tagging for developers

2008-05-20T05:18:00.000+02:00

Developers are building sophisticated tagging system, clouds and drill down mechanism to explore them that project their service in a 2.0 scenario.

Tagging is implemented because it gives lots of benefit in managing and finding contents. Developers should gain this benefits directly from the technology they implement while developing an application.

For example consider if you're writing an application module that consist of:

a web page
a javascript file
a controller object

Tagging them with a tag like module: bookmarklet a developer can consistently declare a unit of development and group logical information together.
Tagging evolves an architect by letting a user to perceive an application in several form. If two files are tagged with an architectural block like the previous block, an extra information can be derived: those two components have a relationship and this relationship should be preserved.

Evolution of a tag cloud

Tag clouds are an impressive way to show which is the major taxonomy on a given content. In my Developer 2.0 idea, tag cloud could be a starting point to get information about how software is implemented and the ranking of each tag is derived, as in the common way, from the tagged contents (sources, documents, etc.).
Filtering tags on a tag cloud gave having a specific namespace, should catch immediately which is the most complex behavior of the system in terms of number of artifacts in it.
In a tag cloud like this, tag names should be arranged by thinking the idea that a content is a neighbor to another content if they share the same tag. All those two content have different tags on and depending on their neighborhood they are showed near by on the tag cloud.

Imagine if you like to browse a tag cloud filtering for namespace: architecture:

Cloud is composed of:

architecture:payment

architecture:messaging

etc.

If a specified payment component notifies troughs the messaging platform a transaction completion, it is tagged by the developer both as "architecture: payment" and "architecture: messaging." Those two tags are now neighbors and in a tag cloud they will be showed, or better linked with their specific size.

This is a new, modern way to have a diagram of how an architecture evolves and the tag cloud can be computed over time and this is a great opportunity a tagging system in the developer 2.0 environment introduces.

I'll continue in the next posts, about how tagging can help me - as a developer - in doing better.

Developer 2.0 - from Code to Content

2008-05-11T08:34:00.000+02:00

Nowadays, development and tools are focusing on better IDE that brings best to developers are not giving a new sense of what development could be.
Developing as a business, having an industrial approach, requires to build software considering quality with the best language of the world and documenting all for all the steps requiring while delivering software that satisfies a particular business.

Speaking with modern programmers, I can feel them like to write code in a more expressive and natural language so they don't need to write external documentation and this helps. Other developers to better understand the code while reading it.
Developers don't like writing documentation for two reasons:

1. documentation is hardly maintainable when code evolves and, maybe, there is not time to maintain it;
2. documentation is not a compiled artifact and developers don't see it for production purposes

I see developers that want to discuss about their code on blogs where they show the techniques around their algorithms, or I see developers that are sending code snippets to other developers by email, asking them to refactor that class in that code portion.

Code is the central point in doing development, and for programmers it's a content they continuously produce over time, share and exchange with others.

Nowadays on the web 2.0 era, development is talking about how to address 2.0 issues for some business case and is not addressing development as a community work where code is a content produced by the community.

Thinking about code as a content, developers when producing it should

publish comments on it;
blog and reblog it;
tag it with some more development oriented tags;
bookmark it.

Like every community Developer 2.0 community should have an online space where to live and where to publish its content (code). Code should be edited on line and for each code snippet (method, class, blocks) a developer should add comments (like she does), should blog it, should tag it, or should bookmark it.

Code editing and browsing
Working, sometime as a developer, I usually develop with an open page to a wiki page where I write stuff about architecture, about why I chose to implement those lines of codes in such way etc, and I work with the Text Editor to edit my lines of codes. Every time, I would like to a wiki page to the developed code, I enclose the wiki's code link inside the code for future better understands. When finished I commit on the version control and I move on the next feature.
Thinking about an evolution if the code is recognized as a content, it will be managed like the text I write on the wiki and wiki will be managed as comment in the code. A development platform for 2.0 should let a developer to work on a workspace where code is edited online in a 2.0 fashion: like a blogger does while blogging. Browsing would be the same, you browse the code space and while browsing you can see all is around code.

Code commenting
Traditional code commenting is done using commenting statement offered by languages, and comments are written in a sparse way depending on the purpose. They are written near the code, on wiki pages, on documents (word etc.) and are written in version control commit messages while checking in, tagging and branching.
In a 2.0 fashion commenting is like when a user read a blog and comment it adding a comment to the post. Thinking the code as the content lets developers to add comment to the code. In this way other developers to browse the code content and to read the history comments on it. Comments are now content and follow the same life cycle of the code because they're linked to the code.

Content Tagging
Tagging lets a developer to add some extra information about his code. A tag helps a developer in declaring a purpose of something inside his code. Already, developers use tags in their code development having several purposes:

to remark to do list
mark code generation (xdoclet docet)
to appoint something to remember
to maintain a group of file of different revision as a version (version control tag)

In the principle of thinking code as content, a developer can tag everything with differently kind of tags.
Thinking about a tag name space, development should implement a thing of tag purposes (architecture: component, assumption: statement, etc.) where tags are "tagged" with a name space and a user or a content aggregator should aggregate for that specific tag. In this way, a user can filter for a specific tag to have a specific context idea of the application. For example, filtering for the "architecture" name space lets to retrieve all the contents about it and have an architectural idea.

Content blogging
Blogging helps developers in sharing ideas that sit around some implemented codes, like a way of explaining the reason of why a portion of code is implemented in such way. Blogs are per user, and are linked to the content that has originated the thoughts.

Bookmarking
When a developer finds something good, he bookmark it on a social bookmarking site like del.icio.us and shares it with others.
On the principle of code as a context, each code snippet can be thought as addressable content and those content should be bookmarked directly on a bookmarking platform.

Endnotes
Code in this era is becoming a content, and everything circle it. Code, comments, tags, bookmarks are exchanged in the developer environment so that other can see what is going on.
The syndication lets users to subscribe to a set of topic and to be notified when something in the development process occurs of the interested topic.
Developers should work in a community as a community where there is friendship between them. Development community should aggregate in a community application all the developers that produce their archetypes there.

I would like to evolve this idea of Developer 2.0 in future topics, where I can go in depth in concept like friendship, blogs and tags or tools around developer 2.0. Stay tuned on this blog to check how these ideas are evolving and how I'll do to make them possible.

Learning on the Wave of what is going on: the Twitter Way

2008-05-08T06:44:00.000+02:00

Well socialware is shifting from a buzzword to really good implementation that help in develop and know faster what is going on right now.
I would like to write this post, to show how I'm using twitter and why I think twitter is a good social interaction tool.
Twitter enables users to configure a Gmail account which receive twitter messages from their friendship. This could be considered as another gateway of the flooding information, where people is still a passive victim of what is going on.
The twitter bot can be instructed and if you there are custom messages that instruct the twitter bot:

with on you are asking of being flooded about messages;
with off your are asking to shut up.

But, how can I gain benefits from the public twitter time line?

Twitter bot allows to track something on the time line and to grab it in your gmail jabber account. In this way, if you want to start learning what's going on in a specific topic just issue

track specific topic

And the twitter bot is instructed about it and you start receiving a flood of information that contains the specific topic and when a user around the world is citing a specific topic, you will receive notification about it without being friend.
This is a really powerful mechanism I use to learn what is going on, and to have it notified on a client application like iChat or other instant messaging client. I read fast the topic notified, and I chose those topics with goods links.

If you want to learn about fashion, or thinking about a gift just instruct your bot:
track fashion
track gift

And coming back just issue untrack keyword to stop receiving notification from the network.

To configure your bot you need:
- a Google talk account following the Google site
- a twitter account configured to deliver to your Google account in the device section of your account settings

Now you can setup a client and start enjoying what's on your wave!

Developer 2.0 - part 1

2008-05-05T12:30:00.000+02:00

Web 2.0 is not only a buzzword that makes people better, it's a movement of things that shift from an era to another. 2.0 is making us passing from a mindset to another. The previous mindset is based on the concept of big corporates, big organizations, big teams, big projects, big strategies; the next mindset will focus more on people, on thinking about organization of people and to trust them.

Software development is playing the game of 2.0, and agile methodologies are only a small anticipations of what is in the next scenario. People, with their human values plus technology knowledge are now becoming the central actor of 2.0 era.
People, in their flavor as friends or colleagues are emphasized from the movement and their network is amplified to get them rid of the hierarchy, the title, or position, and to leverage on values and benefits they give to a social environment.

Developer 2.0 is making upgrading the developer’s concept moving from a developer as a resource in a production chain to a developer as a Person that creates value to the process. This is an opportunity that corporates already know and have implemented in the past through partnership agreement between corporates where the objectives of the partnership were values. Now it is time to make Developers thinking that they can think a development environment as a community of partners where they work for the same objective on the same horizon, and everything is shared. Individual knowledge becomes a group knowledge, and individuality is preserved by the mechanism, as though it was when corporate was partnering in respect to their identities.

Why empirical management works?

2008-04-21T10:13:00.000+02:00

I'm just back from my training course in Florence with the intuition on why empirical Management works. Yes, it's true. I figured out a simple explanation on the reason of it. Before giving my impression I would like to present an exercise I proposed to my attendee to help them in having confidence on estimation. They come from the same area, and they really know well what is there including best ways to drive in when there's traffic congestion. I've started creating a Product Backlog having four routes to cities around Italy and requesting them to plan where they can bring me in 30 minutes. I've prioritized all the routes in the way. The first is really understandable, and the last is an Unknown City for them. Having it on the backlog I've started asking them which of those features can be implemented in the next 30 minutes. Consciously they've chosen the first feature. Before analyzing the Sprint Backlog of the selected featured with them I tried to do an Experiment about the Empirical Approach. To do this I've given a complexity rate of five points priority to the first feature and asked them to rate all the requested feature without thinking to much. Exercise took 3 minutes. - Second complexity was: 15 points of complexity; - Third complexity was: 25 points of complexity; - Fourth complexity was: 45 points of complexity. Having the feeling they can do five complexity each "sprint" I assumed a team velocity of five points of complexity per sprint. This mean that: - Second feature is approximatively estimated three sprints; - Third feature is approximatively estimated five sprints; - Fourth complexity is approximatively estimated nine sprints. Well the possible feature I asked them to estimate was the four cities I've touched coming back home and they gave me a reasonable idea of how many time or sprints it takes to get back. The surprise is that, even the team doesn't know some of the place (third and fourth), they did a reasonable plan making me think that from Florence to home it takes 4.30 hours. Well it has taken 4 hours and 15 minutes. The magic is they've said 45. Why they haven't said 100 or 1000 or 10000? This empirical approach work because, there's no machine, no algorithms that predict things. There is a key element that is a Sum Of Super Computer that is the group and their brain. They did the estimation thinking about their experience discussing each other and sharing knowledge. They superiority - in respect of computers and algorithms - is the ability to think by metaphors and to regulate optimistic and pessimistic position in an intelligent discussion. Becoming familiar with estimation like this need time, than experience. It was the first time they did an empirical estimation and they still think there a sort of trick behind. It's shocking how could be easy to give a projection on how things empirically will go. Every sprint they will commit their velocity, and every sprint their knowledge increase making complexity simpler and having things optimized on the experience.

On Priorities with Scrum: a Product Backlog with Penalties and Benefits

2008-04-15T14:52:00.000+02:00

One of the worst thing is when you're facing a customer with no idea which feature must be implemented before the others.
The question is, how can I help a customer in figuring out the 20% of feature is doing the 80% of business each iteration and sprint over spring she realizes the most important feature for the next iteration. At beginning, I've started asking to complete on a basis of 10 points. Each feature where 0 is the LOW priority and 10 is the MAX Priority. After raw estimation on how complex is the feature, I figured out an ordered Product Backlog with lots of MAX priority feature and the priorly implemented are the minor complex one and then move again. With this approach, I discovered there's no rationales on the Product Owner side to decide what is really need priorly. Well, after lots of thinking I've tried to formalize a mechanism that push the Product Owner to think about the Benefits on having the feature and the Penalties on not having it. With this approach, I've pushed the Product Owner mindset from a selectable option to a selection on consideration. When thinking, I found an Algorithm similar to the "Wiegers Relative Weighting Approach" where I computed which is the less complex feature with major benefits and minor penalties. Three variables influence the priority:

the Benefits of having the feature;
the Penalty of not having the feature;
the Estimation (I prefer Complexity - but is another thing) of the feature

The priority is computed on:

priority = [(relative benefit + relative penalty) / (sum of relative benefit + sum of relative penalty)] / ( relative estimation / sum of relative estimation)

The bigger priority is the most important feature in terms of easiness, penalty, and benefit. In this way, I discovered that Product Owners put in an ordered way their Feature List.

Endnotes

It is useful to work with this approach on attributing priorities. Product Owner works on the Product Backlog and integrate the new feature with this approach and reorder them. This is how a team should commit on a bunch of feature that is really valuable for the Customer.

Thought on how Scrum is addressing Stress.

2008-04-06T08:00:00.000+02:00

In the next 2 weeks, I'll have to present Scrum in a Scrum Session in Florence. I'm thinking to focus on kinds of management Scrum can do:

formal side where task are clearly identified at the beginning, clearly estimated and clearly track in a day by day basis having all the Scrum Archetypes delivered;
process side where all the parties involved in Scrum become active parts in a production chain, having the all the Scrum Events implemented;
informal side having a way to address how relationship works and influences works

Formal and process is addressed by the Scrum methodology having the right role working with the right criteria and following the right Objective. There is ton of documentation explaining how to build a Scrum process in an organization.

Working since several years with Scrum as a Scrum Master and watching team deep dynamics, I've found that burndown chart can reveal more than the status of the delivery.

In modern project managing techniques, project is only managed watching Gantt diagram having relation between phases connected. On the Gantt bar there's no confidence on how really the project is going; this because feedback is managed by a stakeholder, typically a project manager, and are not managed by the team.

Stress in the same way is not addressed letting team to self organize without a Criteria and having it emphasized last at the end.

By self-managing, a team is planning in terms of hours how the sprint will be conducted in terms of task to be accomplished, of issues and of assumption.
By outlining a Sprint Backlog where members some hidden information can be revealed. I think Stress is one of those.

Stress like other "energies" is something that, consciously, a team spends to accomplish a Sprint Goal.

The total amount of hours identified at the sprint planning meeting can be thought as the energy to be spent and energy focuses on pressure and pressure focuses on stress.

So a burndown chart can be seen as the project addressable stress, and an ideal curve from the beginning to the end of the sprint should be the ideal leveling of stress during days.

A Sprint Backlog task is coming from a prioritized Product Backlog; the first task refers to the most important feature to be implemented and the more stressing feature for the customer point of view.

By anticipating stress resolution, stress decreases while each task is done and each feature is completed. The next feature is less "important" than the previous with directs implications on stress.

A scrum master should point out that having a

product backlog prioritized
sprint backlog discussed in terms of hours (4 to 10 each task)
daily scrum
daily updated Sprint Backlog

is not addressed only the delivery of the project, but it is delivered the consistency of a team in term of psychological health.

I'm not a psychologist, but I'm searching a way to improve team day by day living to work better in a stress free environment.

Endnotes
The team is focusing on Phase Archetypes because they continuously increase focuses every time on what bring them out of burning. Common Objectives are lost against Phase Objectives. Without the right priority and without the right self-management strategy, team is move to do fancy stuff at the beginning and run faster at the end spending all the energies, creating pressure and then moving to a negative environment.

Oblique Scaling™

2008-04-01T08:03:00.000+02:00

I'm just back after a weekend on the snow, and I'm happy to know that Oblique Scaling is producing the correct result in mondora.com. Mondora's engineers thought Hardware could be thought as Software, like Virtualization does.

Having Sense as a common infrastructure, they've just released a component called Scent that meets Hardware availability and Software suffering.

During last past 2 weeks they stressed the Sense Workshop on a 4 core HP starting with 1 core switched on and the rest switched off. An endurance test of 12 hours has been run, to check how Sense self regulate having Hardware considered as an High Available Service with an identified Service Level Agreement.

When system increased in suffering by switching from good Service status to worst, Sense has anticipated lack of performance by working with the Hardware Virtualization Platform and asking to Scale Up.

In terms of Business, benefits gained are:

This approach that Predict system performances and do some actions to make the system surviving.
This approach let to Scale when unpredictable things occurs. This is the case of a Campaign that is producing more than the expectation and if the system is not adaptive, Campaign is loosing all the Customer, both the predicted and the unpredicted.

In terms of Manageability, benefits gained are:

Vertical Scaling is predicted by Application Constraints and matched with Hardware Service Status
Policy can be configured (ex. switch a CPU after a 15 minutes of suffering)
Scaling policies are described as Algorithms and implements different strategy. This let to configure a strategy where network latency is compared with Service metrics. By comparing Sense can avoid Horizontal Scaling versus Vertical Scaling

In terms of Development, Hardware is saw as a Service itself and can be allocated runtime when business constraints need it, like another Service on the Net.

By having this building block certified, Sense is becoming a real implementation of a Future SOA where Services:

are available over the network in a cluster environment
are self federating
are balancing on SLA policies
are balancing on Business Constraints by flocking
can balance on most productive in terms of ROI
are multi protocol invokable
can be perceived from the outside environment as inside components
are physical resources

This is a really implementation of what SOA can be.