Agile: "I thank you!" as mindset

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?

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

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?

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?

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

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?

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.