• Reading (12 books)
• Blogging (40 posts)
• Coding (4 projects)

What did I learn about setting objectives? What do I need to improve? These questions will be answered in a few moments… and if you care you might even hear how I fared.

The results (drum roll)

Overall I’m happy with what I accomplished. I read more books than what I planned (16 books that I remember plus tons of blogs), and I blogged as planned (*exactly* as planned if I include this post and another I posted only on the Pyxis blog). However I wanted to code a lot more than I did. I’m still pleased with the small projects that I worked on but I envisioned something bigger. I mostly did prototypes, katas and experimentation with Rails. No big projects, nothing on github (yet).

I did learn a lot about setting objectives for the future:

Lesson #1 : Never write about goals other people set for you

My wife convinced me to put something about losing a bit of weight. Fail. It wasn’t my goal, it should never have made the list

Lesson # 2 : Keep your objectives focused

For me, three goals was one too much. Very early on I could see that it was easier for me to write blogs or read books than it was to code – books were feeding me for blogs, blogs were giving me questions to read about. Coding felt lonely. Next time I’m going to go with two goals max to start with – and coding is going to be one of them.

Lesson # 3 : Do it gradually

Setting goals is definitely something that allowed me to improve. When I did it in the past, I usually started with a big goal in mind. I suggest you try it with small objectives at first and grow more ambitious as you go. Get started, have habits in place. Then think big.

Lesson #4 : Think about your next goals in advance

Especially if you plan on blogging about it on time. Shame on me.

I have a few ideas but I’m not fixed yet, so I’ll set a few very short term goals for now.

• They demonstrate their increment of the product to the product owner
• Product owner seats passively
• Product owner accepts or rejects the increment
• No modification is done to the product backlog
• After a while the product owner is unhappy with the current state of the product and the progress being made

There is nothing like a sprint demo in Scrum. But there is a sprint review.

Scrum is empirical, meaning that there are inspect and adapt points along the way. The sprint review is the inspect and adapt point where the product increment, the most current product backlog and the current conditions are for inspection. The adaptation is the modified product backlog.

During the Sprint Review, the Scrum Team and the stakeholders collaborate about what was just done during the sprint and what are the things that could be done during the next sprints. The presentation of the product increment is not the goal. It is used to understand what should be the next sprint goal. The sprint review provides input to the next sprint planning meetings. One of the possible consequences of this evaluation is the decision to not proceed further with the development of the product. Another possible consequence is the decision to release the existing product.

Consider your next sprint review. If you get out of the meeting without a modification to your product backlog and an insight to your next sprint goal, it’s probably because you’re not inspecting and adapting. You might be suffering from the “sprint demo” syndrome.

Imagine my surprise when a candidate for an agile organizational coach role within our organization shared with me his perspective on this topic.

“Can you share with me your reasoning?”, I asked him intrigued.

The candidate went on to explain that people need direction and that people cannot self-organized without clear objectives and direction.

Indeed, I thought to myself. Who said people and teams shouldn’t be given clear objectives. On the contrary, in my opinion, clear goals are necessary for teams to organize otherwise you end up with a bunch of people who will try to find a reason, a purpose why they are all together – and their self-created goal may very well be different from what you had in mind in the first place.

Where I have a problem is that people associate self-organized teams with “abandoned teams” meaning you simply let the team figure it out – whatever “it” is.

In order to reach the level of autonomy they need to demonstrate extra-ordinary performance, teams need to reach the right level of maturity. Consequently, the manager’s leadership style is critical to achieve that objective. Within Pyxis, we often rely on the combination of the situational leadership and the group development stages to determine the proper level of involvement from the manager.

(Tuckman’s stages of group development, Situational leadership theory)

One of the way to achieve the right level of maturity is for agile managers to determine WHAT must be accomplished and let the team determine HOW it will be done – I already shared my opinion on this topic. Granted, things are more complex that I make them sound in this post but self-organization is indeed possible when the right environment is created for the team – including clear objectives – and it is then given the latitude to operate and determine how best to achieve the given goal.

If only managers would be willing to let go some of their (need to) control and trust the teams, a higher level of performance can be attained.

As you may have guessed, the candidate wasn’t called back for a second interview…

You might be interested in these related posts:

1. Agile Transition – What about the teams outside the transition?
2. The 5 Dimensions of Leadership in an Agile Context
3. Join us on LinkedIn

Scrum n’imposant rien sur le plan technique, une dérive couramment constatée est un manque de rigueur par rapport aux pratiques d’ingénieries utilisées par les équipes de développement.  Par exemple, l’omission de tests automatisés lors de l’évolution de projets informatiques rend généralement de plus en plus difficile l’atteinte de l’objectif de livraison de qualité “production” au fil des itérations. Martin Fowler a nommé ce phénomène le Scrum Flasque.

Le cours “Professional Scrum Developer” offert à Pyxis vise à contrer ce problème en replaçant l’emphase sur les bonnes pratiques de développement essentielles à l’atteinte des objectifs de Scrum.

Le développement piloté par les tests (TDD)

Nous avons pu mettre en pratique le TDD dans toutes les facettes de l’application, aussi bien pour le développement en tests unitaires qu’en tests clients (bout en bout).  Ceci nous a permis de nous rendre compte qu’il est possible de couvrir la quasi totalité du code par des tests automatisés.  En conséquence, le code obtenu est robuste, explicite et diminue le stress du développeur qui sait que ses changements seront plus faciles à implémenter dans le futur.

Choix technologiques

Certains choix technologiques peuvent rendre difficile, voir impossible l’application des bonnes pratiques et donc l’objectif de Scrum Robuste: la livraison itérative de logiciel de qualité.  Il est par conséquent essentiel de choisir un ensemble d’outils (langages, cadres d’applications, environnements de développement) qui supporte convenablement ces pratiques.  Un exemple parmi tant d’autres, le cas d’utilisation étudié durant la formation utilisait une librairie de rendu visuel légère et testable.  Ceci nous a permis de facilement tester les vues de manières unitaires, ce qui est malheureusement rarement possible…

Elimination des mauvaises odeurs de code

Les mauvaises odeurs de code (aka Code Smells), comme par exemple les duplications ou les classes géantes, sont des causes fréquentes de difficulté à maintenir une base de code et d’une réduction de la vélocité des équipes.  Le cours nous a permis dans le cadre de la pratique du TDD, de veiller à enrayer en continu, par le “refactoring”, ces mauvaises odeurs.

En conclusion, il faut garder à l’esprit que Scrum ne suffit pas en soit à livrer du logiciel de qualité.  Scrum doit nécessairement être entouré de bonnes pratiques de développement, telles que celles enseignées durant la formation pour éviter de sombrer dans la flaccidité.

Allez-y, soyez robustes du Scrum!

Marc-André Thibodeau et Gaël Luisier

Written in collaboration with Carl Létourneau

What’s the problem?

Creating software without bugs is hard. Many developers are used to unit test their models. Controllers are also relatively simple to test in many frameworks. Tests often hurt when it comes to Views – many frameworks make it hard, or developers might think it is. Sometimes we just don’t take the time to explore what options are available, because we think the time investment might be too heavy.

After a week following a Professional Scrum Developer class, we changed our mind!

But why?

Views are the front of your application. The first thing the user sees and interacts with. Why should they be less important than the rest of the code? What if you had the same confidence modifying your views than you have refactoring your code? An important information displayed to the user is as important as a business rule on the backend. A shopping cart is useless if the total is not displayed. What if someone removes this information by mistake and this problem goes in production?

Testing Velocity templates is pretty easy once you know how.

But how?

Here is an example of a unit test that tests if a cart displays the grand total.

@Test
public void displaysCartGrandTotal() {
  Element cartView = renderCartView().using(
    aModel().with(
      aCart().containing(anItem().priced("20.00"),
                         anItem().priced("12.99"),
                         anItem().priced("43.97")))).asDom();
  String grandTotal = "76.96";
  assertThat("view", cartView, hasUniqueSelector("#cart-grand-total",
                                            withText(grandTotal)));
}

The method renderCartView() method renders a velocity template as a string. asDom() then converts it to a DOM Element. The element is finally tested against the css-selectors library wrapped into our own hasUniqueSelector() Matcher.

Wow, it’s that easy?

You bet it is! Although writing tests for your views might not be available for the technology you are currently using (though we encourage you to do some research). Next time you are faced with a technology choice, you might want to consider the testability of the framework as an important criteria.

This week, the first dry-run of the Professional Scrum Developer for Java course was given at Pyxis. For this occasion, 6 Pyxissians were on-site for 5 training days. Here is a sample of the many things we have learned.

One of the fundamental aspects that was covered was producing a proper “definition of done”(D.O.D).

For most of us, even with our extensive Scrum background, this was actually harder than we had originally expected. The training course consisted of 4 sprints spread over a 4 day period. At the end of each sprint, we had to demonstrate our accomplishments to the Product Owner.

At the end of the fourth sprint, we had to put our software into production.

Like most teams, we started out with a D.O.D that was too ambitious and wasn’t clear enough. For example :

• We had planned for 100% test coverage for all of our tests, yet it was impossible to demonstrate since we were unable to calculate code coverage for view tests. Even worse, there was simply no available tools to calculate our test coverage for these.
• We also had ambiguous elements, like following the code standard, without stating which one.

After achieving first sprint, we did what we thought were the proper modicifications to our done definition. As you can guess, we failed our second sprint. Our done definition was being seriously violated. We committed to too many tasks and did not take the time to truly understand all the work involved in achieving our done definition. We adjusted for the following sprints. Inspect and adapt as always.

However, when came the time to release the product, we realized that our done definition was seriously lacking. We had no confidence in being able to ship our product to the customer. The Product Owner was disappointed in learning this. We then had to modify our done definition to finally be able to deliver. Unfortunately, we had skipped some important steps in the previous sprints which accumulated up until the last day.

Here are few key points that were missing :

• Exploratory testing
• User Experience testing
• Proper production deployment procedure

This really helped us see how important it is to have a true definition of done and to follow it through sprint after aprint. After all, we had accumulated debts after only 4 days of sprinting. Imagine if we had been sprinting for weeks !

-Nicolas Henin and Nicholas Lemay

I am rediscovering ERB though for something else completely – Java code generation.

There is a lot of boilerplate code in most Java projects. A good IDE can help you alleviate some of it but most (if not all) applications will have additional boilerplate very specific to your application. Using ERB, you can easily create cut down on mindless typing.

For example, let’s suppose you are writing many Java listeners. Just create a script that will do it for you. I’ll make an exemple with a ContactListener class that is notified when a user is added, removed or blacklisted from your contact list.

require 'rubygems'
require 'erb'
 
# setup - could be initialized from script arguments
classname = "Contact"
listener_methods = ["added", "removed", "blackListed"]
 
# create file based on 'listener.java.erb'
content = File.read('listener.java.erb')
template = ERB.new(content)
File.open("#{classname}Listener.java", 'w') { |f| f.puts(template.result) }

If I run this using listener.java.erb:

public interface <%= classname %>Listener {
  <% listener_methods.each do |method|  %>
  void <%= method %>(<%= classname %>Event event);
  <% end %>
}

Then I generate this file:

public interface ContactListener {
  void added(ContactEvent event);
  void removed(ContactEvent event);
  void blackListed(ContactEvent event);
}

That was easy – and it’s not that useful I admit. I’m sure you can create your own listeners just as fast in your own IDE. Probably even faster.

However here comes the fun part – the same script can be used to create lots of other classes:

• The ContactAdapter class
• The ContactEvent class
• The ContactController
• The Contact model
• The ContactRepository (maybe even with a few methods to add/remove/retrieve a contact by id)
• The ContactView through which users will be able to trigger ContactEvents (maybe with a simple UI – even buttons to trigger each events on the ContactHandler)
• Registration of the ContactHandler and the ContactView by your favorite IOC framework
• Registration of the ContactView so it is accessible from your application’s menu
• Test classes for all of the above (including failing test cases that you’re going to have to write)

And probably other bits here and there to glue everything together.

Your mileage may vary, but code generation might be a great way to make your path shorter.

Can your IDE do that?

I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time.

In agreement with his teams, Steven initiated an Agile transition a few months ago. I was part of the team who presented to Steven the benefits of a transition and the impact on the team members and their managers. I saw Steven again in a group training I was giving a few weeks after the beginning of the transition to managers and executives. That time again, Steven was very excited and motivated about what he was hearing, except that during the training I could see the light bulbs over his head and in the questions Steven was asking – how is this going to impact my role as a manager? Steven saw the obvious benefits and understood some of the changes he would need to make to his leadership style but I could tell, it hadn’t fully sinked in.

So here we were, less than 3 months in the transition and Steven wasn’t as chipper as he used to be…

• Me: “Hey, Steven. You look tired. How are you doing?”
• Steven: “I’m OK… I’m tired… [silence] The transition is killing me!”
• Me: “How so?” [I asked anticipating what he would tell me next]
• Steven: “The team is having a blast and I can see their performance has increased compared to the past but I don’t think I can cope with this new approach”
• Me: “You seemed so excited about the transition when we started. What changed?”
• Steven: “I now realize what you meant when you talked about changing my leadership style and my role. I’m still up to the challenge but my boss is totally clueless about all of this”
• Me: “What do you mean? Haven’t you brought him in the loop from the beginning?”
• Steven: “Yes. Yes, I have but that’s not the problem. The team’s performance increase is directly linked to the new approach they have been using and the fact that I leave them a lot of autonomy but my boss still asks me to behave like I used to – like he manages his team today. That’s where it hurts the most. I can pretty much deal with everything else but I feel like I’m stuck between a rock and a hard place”

Unfortunately, we (as consultants) do not do such a good job at highlighting this fact before we begin a transition. We work closely with the teams to help them adopt better methods and practices, to increase their overall performance by allowing them to be self-organized. We work on getting the teams to a highly performing level. Then we go get executive sponsorship to secure the initiative (and the budget) and make sure we get support to handle difficult issues but what about the people in the middle?

We develop training programs for Agile managers and we support them with organizational coaching but we don’t do such a good job at telling them upfront how much pressure they will be under once the transition begins. How much their role is likely to change and their leadership style needs to be adapted to the new reality.

For those who haven’t yet have felt the pressure, here are some examples of what to expect:

• You may be willing to trust your team and let them self-organize but is your boss in agreement with this new approach? Will he be as involved (micro-managing) in your activities as he used to be? And more importantly, will he be expecting you to be as involved with your team as you used to be?
• You may be willing to tolerate mistakes in order to increase your team’s learning and with a strategic perspective to increase long term performance but will you hear about your inabilities to control your team during your next performance review?
• You already produce status reports, dashboards, emails and others information to keep everyone (including your boss) informed of what is going on in your unit. Will you need to translate everything that the Agile team is producing to fit the traditional reporting mechanisms? Can you challenge what information is currently being produced to ensure it does bring value to people?
• You expect your team members to handle the details of their activities and you believe in actually seeing (touching, feeling) the end results while your management team expects you to assess progress using Gantt charts. Do you need to educate your entire organization to the new approach? Does the fact that you are adopting Agile make you the evangelist for the entire organization?

Obviously, I don’t mean to scare anyone – especially the managers – with regards to adopting Agile. The approach has a lot of merit and value for many organizations but in order to help with adoption, coaches and consultants need to pay attention to the people in the middle and help them find their new place, otherwise we are very likely to find serious resistance and potential failure of such initiatives – nobody likes to be stuck between a rock and a hard place…

You might be interested in these related posts:

1. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers
2. Agile Transition – What about the teams outside the transition?
3. Secret Revealed! Guaranteed Success for your Agile Transition

With the release of the Scrum template from Microsoft came a Removed state, making it necessary to propose a recycle bin feature to our users. The next version of Urban Turtle will therefore include a recycle bin icon at the top of the iterations and areas panel. Users will be able to drag and drop items onto it to set the state of selected items to a configured deleted state. It will also be possible to view deleted work items by clicking on the icon.

The team is also working on a select / unselect all option to flag or unflag all iterations and areas as favorites in one click.

We have several more interesting features in our backlog, some of them coming from customers who voiced their opinions and proposed suggestions on our community-powered support site. Thank you all for your support and keep those suggestions coming!

} Dom

Tweet This Post

A recent post from Mark Shuttleworth seems to show that some foundations also have interesting ideas when it comes to financing projects :

“The model of the Foundation is unusual: we identify interesting change agents, like Mark, who are articulating powerful ideas that seem like the offer a hint of the future, and we fund them to work on those for a year. We also offer them an investment multiplier: if they put their personal money into a project, we multiply that by 10x or more, up to a maximum amount. In short, find good people, back them when they put skin in the game.”

Now, I am wondering about something : could incubators be a model for managing companies ?

• What would happen if you created a company that was merely a kind of aggregate of smaller companies sharing a common vision but running mostly independantly ?
• Could the Politics of Switzerland be an inspiration  for creating such an ecosystem ?
• How much federal government do you need to have inside a company to have the perfect balance between “feeling like a single company” and “feeling empowered enough to do things without any bureaucracy” ? (do-ers hate bureaucracy, so if you want doers in your company, you’d better find a way to systematically fight it if you want to keep these people)
• Is is possible for people to feel part of their community without neglecting the rest of the ecosystem, the same way Texas inhabitants feel both texan and american ?  (Have you noticed that people have both the texan flag and the american one in their garden over there ?)

There will be an interesting conference on Lean Startup by Eric Ries at SXSW. Eric asks 5 questions everyone involved in building new products (or any market offerings) should ask frequently. Answering these questions is not as easy or obvious as it sounds. It’s even more important for mobile development as product lifecycles are very short and spending too much effort on a bad or average product might have high impacts (opportunity loss). I’ll reuse these questions in coming blogs and apply them specifically to the mobile market. To read these questions and vote for Eric panel, visits http://panelpicker.sxsw.com/ideas/view/8270

So for five days, I dove in the pleasant warmth of my fellow agilists and shared ideas, laughs and a few drinks.  Attending the wide variety of sessions was my preferred activity and a great opportunity to listen, participate and learn.

Enough chit chat, let’s get right into it…

My first session was “Leader’s Workshop: Making Change Happen and Making it Stick” with Mary Poppendieck.  I won’t go into details so here are a few points…

Mary states that to encourage change, one needs to provide:

1-      The proper kind of motivation

2-       A clear direction

3-      A supportive environment

So what motivates people?

Mary references books such as Switch, Drive and that great video by RSAnimate

A very interesting point is to manage employees as if they were volunteers.  With money being out of the equation, what needs to put in place and maintained to keep motivation at a high level?  What  keeps a volunteer motivated?

1. A  clear purpose
2. Structure and guidance
3. Successful project
4. Ownership
5. Autonomy
6. Bragging rights
7. Mastery
8. Constructive dissonance

What I take back from this session

You can throw all the cash you want at your problems and they still won’t go away.  If you want successful projects, hire smart people, offer them a clear direction, a few rules, and get out of their way.  Smart people will find a way to make it work.

Scrum est un outil de visibilité. On ne le dira jamais assez. Et sans doute faut-il trouver des formulations alternatives pour pouvoir être compris par des gens différents, avec des cultures et des expériences qui modifient la façon dont ils interprètent cette phrase. Et parfois, un dessin suffit, un graphique suffit.

Aujourd’hui j’ai passé une bonne heure avec un gestionnaire de projet traditionnel qui souhaitait savoir comment faire un suivi budgétaire “avec Scrum”, selon sa formulation. Nous nous concentrons donc sur cette idée de “suivi budgétaire”. Une chance pour moi, il est très ouvert et me dit simplement “comment fais-tu toi ?”. Magnifique non ?

Simple : la clef dans son cas c’est la définition de Done. En effet, nous plaçons un curseur dans la définition de Done. Ce curseur sépare ce que livre l’équipe à chaque itération et le reste des activités qu’il faudra faire pour avoir un Working Software, soit un logiciel en production utilisé par quelqu’un.

D’un seul coup, la définition de Done devient un outil concret pour lui. Voici ci-dessous une version simplifiée de ce à quoi nous sommes arrivés. Il lui apparaît très naturellement que les activités concrètes de mise en production sont liées au Done et que le voir exprimé ainsi lui fait réaliser tous les éléments que l’ensemble de l’équipe avait jusque là oublié.

Combinés aux Release burndown chart et au Value burnup chart, ce budget plan complète la vision 360° qu’il a du nouveau jeu dans lequel il joue.

Selon les prévisions que vous ferrez, vous pourrez utilisez ces graphiques pour amener une discussion autour de la vision partagée que vous avez des prochaines itérations. Par exemple aujourd’hui, les graphiques étaient sensiblement semblables à ceux-ci et la réflexion principale de mon interlocuteur a été de dire que le budget serait consommé avant que la courbe de valeur ait commencée à s’infléchir, ce qui lui a donné envie de trouver plus de budget.

Attention néanmoins à ce que l’on fait dire aux chiffres. Même dans ce cas d’un petit nombre d’itération, la courbe de valeur qui ne décroit pas pourrait nous mettre la puce à l’oreille et nous parler de la piètre qualité des estimations de valeur. Il se pourrait que l’on ait affaire à des priorités et non à des estimations relatives de valeur ajoutée. Mais ceci est une autre histoire

Pour fêter notre 10ème anniversaire, nous préparons des capsules pour parler d’Agile et … de nous. Le scénario a été écrit par Alexandre Champagne (créateur, entre autres, de contratdegars.com) et la réalisatrice est Catherine Therrien. Les acteurs : des pyxissiens que vous connaissez peut-être déjà. Les bureaux sont en effervescence, les acteurs se préparent et s’entrainent. Suivez photos et infos sur le tournage sur notre page facebook. Les capsules seront dévoilées fin septembre.

My colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.

As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.

Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.

I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.

As such, my first impression to the conversation that was going on were:

• Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
• If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
• On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time

It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.

You might be interested in these related posts:

1. I don’t feel so good – I’m a people manager in an Agile organization
2. Does your organization support prostitution?
3. Defining Agile Management – part 1

def read_file_content(filename)
  File.read(filename)
end

Simple enough, right?

Then for some reason I thought about how I would have to the same in Java:

public String readFileContent(String filename) {
  try {
    BufferedReader reader = new BufferedReader(new FileReader(filename));
    StringBuilder buffer = new StringBuilder();
    String line = null;
    while ((line = reader.readLine()) != null) {
      buffer.append(line);
    }
    return buffer.toString();
  } catch (IOException e) {
    return "";
  }
}

Need I really explain why I prefer Ruby these days? Even if you remove the try/catch clause and rethrow the exception, that’s still a lot of code compared to a single line of ruby. I am also aware that it is possible to write the same Java code in a single line using Apache’s commons-io (IOUtils.toString(InputStream) – but still, why are the base Java libraries so verbose for file manipulation?

I still like Java, but I’m impress by the compactness of Ruby. It just works as it should. Sometimes working in Java it seems I’m just smashing the keyboard instead of getting actual work done.

The following procedure explains how to configure the Talia chat-robot to help you fill your timesheet through a secure and private instant messaging environment. In this configuration you do not need to connect in any way to a public messaging system like MSN or Gtalk. Although this procedure explains how to configure Talia with the Openfire messaging server and the Spark XMPP chat client, Talia can be configured with any other XMPP client and server like Ejabberd and Pidgin and of course, MSN Messenger and GTalk.

Before attempting to install or configure Talia with Openfire and Spark, you must install your messaging environment and be sure all related instant messaging accounts are configured and that all “contacts” in your network can “see” each other and chat together. This is extremely important as most installation issues come from misconfigured instant messaging accounts. Here is how to configure Openfire and Spark for Talia.

Openfire server installation

1 ) First step is to download and install Openfire using their straightforward installation guide.

After your Openfire server is up and running, go into the Openfire Administration Console to complete the configuration. It should be accessible at http://127.0.0.1:9090 or simply use the “Launch Admin” button on the launcher screen.

2 ) Configure the instant messaging domain name.

It is important to understand that the instant messaging domain and the email domain are two different things. For example, the following procedure will configure the Talia robot into the pyxis-tech.ca messaging domain although the email domain is pyxis-tech.com. In fact the messaging domain is the network domain of the messaging server.

In the Openfire console, navigate menu to Server > Server Manager > Server Information and select the Edit Properties button at the lower part of the screen, enter your messaging domain name in field Server Name: and then select Save Properties

3 ) Create and configure users in openfire.

Navigate to Users/Groups > Users and create all users you need including an additional one for the robot itself, like this one

Note that the value in the field Username does not contain the messaging domain suffix. It is automatically appended internally by Openfire when required in order to give this kind of messaging id: talia @ pyxis-tech.ca

4 ) Stop & restart Openfire

Spark client configuration & test

On each user computer, install the Spark XMPP client.  After installing each client, go into Advanced setting in order to configure server host, port and SSL as follows:

6 ) Connect your Spark client to Openfire to be sure everything is ok and add the chat robot to your contact list, Talia in our case.

At this point, the Talia contact request is pending and the robot will not be able to chat with you without completing the next step.

After completing the installation of every client and making the contact request for Talia in every account, use a Spark client to log into the robot’s account and accept all pending contact requests.

8 ) Finally, while logged into the account of the robot with Spark, add every other user of your network to the robot contact list.

Configure Talia to use Openfire

If you have already installed Talia and the robot is up and running, go to step 9-B. If not, follow step 9-A.

9-A ) Follow the Talia installation and in the instant messaging configuration step, enter value related to the robot as follows, using previous information:

9-B ) Otherwise, if  Talia is already installed, you must edit the configuration file  Dialoog.Host.exe.config

The configuration file should be located in directory like “C:\Program Files\Dialoog Solutions\Talia 1.5.4.1″ and you have to change values of the xmpp section as follows:

10 ) Configure users to be served by the robot

After Talia has been installed and the Talia service window started,  go into the robot Administration Console ( http://127.0.0.1:8088/taliaconsole/index.htm default usr/password are admin/admin)

navigate menu to Users Configuration> Active Users and set to active users you want to be served by the robot then click Save.

11 ) Overwrite Instant Messaging Account if required.

At this point, it is very important you verify that the value of field Instant Messaging Account for every user in this list is exact.  You have to understand that this value is the one returned by your backend system (JIRA, Project Server etc..) and does not necessarily correspond to the messaging account of the user.

If this value is an email and does not correspond to the Instant Messaging Account of the user, you need to overwrite it by navigating to Users Configuration> Users Settings and entering the correct value in the field Instant Messaging Account then click Save.

The last step is to restart the Talia windows service.  After this, Talia should appear as an active contact when user log into Spark and the robot should start talking with users when they are online and they have time sheet missing.  Don’t forget that at any moment a user can initiate the conversation with Talia to fill their time.

]]> http://dialoogsolutions.com/blog/2010/08/18/use-talia-with-a-private-messaging-system-openfire/feed/ 0 http://pyxis-tech.com/blog/2010/08/18/lean-startup-applied-to-acs/ http://pyxis-tech.com/blog/2010/08/18/lean-startup-applied-to-acs/#comments Wed, 18 Aug 2010 14:45:38 +0000 joël grenon http://pyxis-tech.com/blog/?p=5855

Creating good and successful mobile applications is something you learn from the market, not by reading books on how to do wonderful technical tricks on the phone. But getting an application to market is a complex endeavor which requires a level of polish to avoid bad ratings and thus, killing your good product before its even used. So, even more for mobile apps, getting to the market fast and providing constant releases with small improvements to your customers is a key to success. Agility helps us on two axis: customer development and product development.

It dawned on me recently that organizations are lead and managed by accountants. Accountants come in many shapes and forms and not every accountant wears brown socks.

I suspect you will disagree with my statement arguing that your CEO isn’t a former accountant or that your CTO didn’t even take a single accounting class in his life and I would agree with you. Not all accountants carry a pocket size calculator.

I personally don’t have many complaints about accounting itself, after all there is value in knowing how much money enters your coffers and how much you had to spend to generate the associated revenue. That makes perfect sense to me. Where I have a problem is when common sense leaves the building to make place for accountant-based logic and the need to book everything against the right account and the use of money within certain time intervals.

Confused? Let me explain.

Let’s take project management [Ah, now you are starting to see a link between accountants and Agile projects]. In many of the organizations I had the pleasure to work with, compliance to project plans was more important than delivering real value to customers. Nobody asked if it made sense to add new features or change the sequence of activities in an attempt to deliver business value to customers faster. People are concerned with compliance to the plan. And where does this need for compliance come from you ask? Accountants.

Before the debit-credit masters come running after me with their red pen, I will confess I used to be one of them (sorry!). I understand the mindset, their perspective of the world and most of all, the need to put things in neatly defined categories – some can be amortized while others can’t – but I digress.

The project timelines are derived from the accounting cycles – the money is allocated for a certain budgeting period instead of true market needs. The phasing and allocation of the resources is driven by the departmental allocated budgets. The profile of the resources assigned to a project is driven by who has the money as opposed to who has the skill set.

Does any of this make sense in a context of business excellence? That’s one of the reasons why I like Scrum with its focus on delivering the highest business value sooner. Scrum isn’t perfect, I know but it forces people to make decision based on business value, not accounting rules.

Scrum is also great a giving visibility the what is really going on within a project as opposed to estimated project completion for cost computation. In heuristic tasks such as software development is it really critical to know that task ABC costed $357? Chances are, you are unlikely to do anything useful with that information. Why wouldn’t you rather determine the cost of an iteration (or a sprint) so you can compare it to the business value delivered. As I stated earlier, there is value in accounting but when everybody starts to behave like an accountant, it is a sure sign that common sense is gone and that the organization is ripe for an Agile makeover.

You might be interested in these related posts:

1. You are not doing SCRUM if you don't have a ScrumMaster
2. Who benefits from the traditional consulting approach?
3. Top People in the Agile Business Intelligence and Agile Data Warehousing World

Everybody now knows that a business blog is essential to be found on the world wild web, essential when you are an innovator who wants to share new ideas and a new way of doing things, essential for people to know what you are offering.

More than a year ago, a group of people sharing the same interest for Internet marketing decided it was time for Pyxis to have its own blog. But how the h… was it going to be possible to get people to blog? At Pyxis, many people are influencers and are used to speaking at conferences and addressing user groups, (that is why we have launched the podcast Vox Agile). But speaking and writing are two different stories.

The first thing we did to get started was to launch a contest that would last 4 weeks. People who would blog the most would win an iPod touch. Several people started to throw their ideas in writing. That is how it really started. It worked really well. Tremeur was the winner! (he now has his own blog). Then, Martin started his own and syndicated it to the Pyxis blog. He blogs constantly with great content. I’m sure that his blogs influence many others.

A main concern that first prevented people from contributing was the fear to be out of context. We emphasized in our communications that we did not want to impose a corporate guideline. We wanted the posts to reflect each person and to represent the culture of our company. The diversity of our employees is the wealth of our company. Talking about different subject is OK.  All people working at Pyxis are professionals. So far, we have never seen a post that was out of context or out of line. Surprisingly, another concern was making typo mistakes. To address this matter, a group of people offered their help to correct mistakes before publishing.

Also, we constantly provided statistics to encourage people. We wanted them to see that people are reading their posts. Posting comments (from co-workers to start with) helped a lot for bloggers to realise that what they have made an impact.

Today, Pyxis’ blog is an aggregation of 12 pyxissians’personal blogs.  We often read a post per day; on Agile project management, on scrum, on software development and many other topics.

To provide more details on each of our partners, I follow the series of blog posts with the firm Readify.

Founded in 1999, Readify has established itself as certified experts on the .NET Application Development Platform within Australia.  They have office in Melbourne and Sydney and provide expertise around system architecture, application lifecycle management and user experience design using the latest Microsoft platform technologies.

In 2009 Readify introduced its projects offering known as DevPods. DevPods are based on a team-orientated project delivery capability which combines a high performance development team using an agile methodology (specifically Scrum) and focuses on close customer involvement to successfully deliver projects.

Readify is one of Australia’s young and savvy IT business success stories. This year they received the Australia’s 2010 ‘Best Places to Work’ award.

Mitch Denny, Chief Technology Officer at Readify explains why they appreciate Urban Turtle:

“If you plan to use Scrum with TFS, we recommend Urban Turtle instead of Excel-based planning workbooks”

You can learn about their offerings relating to Application Lifecycle Management (ALM) here. Do not hesitate to consult their website.

Tweet This Post

At the Agile 2010 Conference this week, out of the two hundred or so sessions presented, a number of them talked about the role of the manager in an Agile team. A few people believe managers are no longer necessary once the team has self-organized while others say people managers are still required. Either group failed to provide compelling arguments for their position.

The notion of self-organized teams keeps gaining visibility and acceptance. Those who have adopted the approach can’t stop talking about the benefits. At the same time, people realize that managers are unlikely to disappear from the organizational landscape anytime soon. In this context, it is with a mixed-feeling that Agilists talk about the role of the people manager in an agile organization – mostly as something not so useful but that the team needs to keep around in order to maintain their autonomy – something similar to the appendix.

The most common explanation for the appendix’s existence in humans is that it’s a vestigial structure which has lost its original function – source wikipedia

Then a few things happened.

First, I got to attend Michael Spayd‘s session called “Blueprint for an Agile Enterprise: Plans, Tools & Tech to Build a Human Enterprise”.

Want your whole organization to be more like an Agile team? Starting teams is well understood; expanding Agile to the organization is definitely not. Using 8 years experience applying organization development to Agile, we’ll unfold a 7 layer organizational architecture for building a human enterprise. Each level has an overall perspective, specific tools and key practices. Part tutorial, part demo, we’ll create a change plan for one participant’s organization, exploring culture, leadership, change, team performance, and management’s role. You’ll leave with a plan template and many ideas – source Agile 2010 Program

Then, I went to Damon Poole’s session called “Getting Managers and Agile Teams Out of Each Other’s Hair”.

One of the most talked about and least well understood concepts in Agile is the “self-managing” team. This session will provide a new perspective on self-management by examining the external roots of the practice and by taking a bottom-up look at what it is, the benefits, and how it works. We’ll see how twelve widely adopted Agile practices contribute to self-management by reducing and/or redistributing traditional management activities. These practices provide a framework for delegation, communication and coordination; and encourage team ownership, commitment and accountability – source Agile 2010 Program

Finally, I also attended Jim Highsmith session called “What do Agile Executives and Leaders Do?”

In some circles agile executives and leaders are admonished to buy pizza and get out of the way. In others they are asked to be supportive of self-organizing teams. But leading agile organizations requires more. There are specific activities that help build agile organizations that can weather business turbulence. This session will explore those activities that an agile leader or executive must “do,” including: revising performance measurements; facilitating self-organizing teams; developing strategies for operational, portfolio, and strategic agility; and assessing how agile to be source Agile 2010 Program

After the sessions, I sat in the lobby of the conference and read some of the blog feeds I subscribe to and came across these…

• Esther Derby’s ONE-ON-ONES WITH SELF-ORGANIZING TEAMS
• VersionOne’s Self Organizing and the “M” word

Obviously, something’s up!

The role of a traditional people manager

In many organizations and depending on their level, people managers are expected to plan, direct, organize and control (Deming‘s Plan-Do-Check-Act) – more specifically, the role of the manager is to:

• Define the individual objectives
• Assign work to team members
• Determine priorities of the tasks
• Monitor progress of the activities
• Make decisions for the team
• Get visibility into the work of the team
• Mentor and train employees
• Protect the team’s financial and human resources
• Provide career development opportunities
• Build relationships with other departments and teams
• Motivate the team members
• Communicate information

What self-organization removes from the equation

Once the concept of self-organized team is implemented, there are a few things that were traditionally the responsibility of the people manager that now fall on the team. The activities are:

• Assigning work – team members now select their tasks instead of the manager
• Determine priorities – team members now determine the order in which they should to complete their work
• Monitor progress – team members track their own progress and make it visible and accessible to those who need to know
• Make decision for the team – within the team, team members get to make their decisions
• Get visibility into the work – team members track their own progress and make it visible and accessible to those who need to know
• Mentor and train employees – when possible, team members may decide to implement a mentoring program within the team
• Motivate – self-organized individuals are known to be more motivated than traditional teams, hence the reduced need for the people manager to retain this activity

So what is left for the people manager?

In order for the people managers to transform into Agile leaders and feel as part of the team, we already stated they need to modify their role. The agile manager will achieve higher level of performance and possibly increased personal job satisfaction by macro-managing – working with an increased perspective as opposed to getting into the details. As such, the activities the agile managers need to retain are to:

• Define high level objectives for their team and department instead of focusing on the tasks
• Determine priorities in the objectives of the team and department instead of the activities
• Monitor progress toward achieving the objectives
• Coach employees
• Continue to protect the team’s resources
• Support employees in their career development
• Build relationships with other departments and teams

I realize that this type of transition is easier said than done but with the willingness to recapture an important role as part of the team and with some external help, the traditional managers don’t have to became extinct professionals.

You might be interested in these related posts:

1. Are you an Agile Leader? – Nine questions for people managers
2. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers
3. How can someone Join a Community? Can people leave a Community?