Pyxis

In September 2009, I decided that for the next year, I would concentrate on three goals:

• 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.

Any questions?

There’s a misunderstanding I’ve noticed in quite a few Scrum projects. Teams use Scrum and at the end of their sprint they do what they call a “sprint demo”. It works out like this:

• 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

Since I discovered Haml for my HTML templates in Rails, I stopped using ERB. Haml is more intuitive and readable to me.

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

Now that the vacations are over and that the 2010 Agile conference has come and gone, Team Urban Turtle is back to work, cooking up another promising release 3.4.

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