Archive for the ‘Development’ category

« Older Entries

Beyond Budgeting at LESS 2011

January 20th, 2012

One of the things that attracted my interest to LESS 2011 was the Beyond Budgeting track. Having read the book a couple of years ago, it is definitely a topic that catches my interest. And it was even better that the first keynote was presented by Bjarte Bogsnes, talking about how beyond budgeting is used at StatOil

As any presentation write-up, this is just my understanding about what was presented, so please don’t hold the presenter on to what I’m writing here :)

Why ?

The first question Bjarte addressed was why the need for something different. And I believe this sentence explains it all

January-December is artificial for business and just works for accounting. But this is not accounting

He followed by explaining that StatOil is always trying to get the best performance they can (who isn’t!), and coupling everything they do to an accounting mechanism (the budget) doesn’t make sense for them. He illustrated it with a comparison between the use of traffic lights and roundabouts. While the first is easier to use and provides more control, the latter actually provides better results because it relies more in the current situation than on statistical analysis.

We need to find more self regulating ways to manage a business, and beyond budgeting is one of them.

Bjarte used Douglas McGregor’s Theories X and Y to explain how we traditional management doesn’t usually trust people and relies on a stable environment to succeed, but in a dynamic environment in which most companies are inserted today, we need to start trusting our employees much more, and that is where beyond budgeting stands.

He had a nice example to show the lack of trust some companies impose, about a friend who is a SAS pilot, and even when he is trusted to fly planes full of people around, if he wants to change his shirt more often than it’s stated in the company’s policy, he needs a written authorization for it.

How does it work ?

According to Bjartes, the problem with budget is that it’s a single tool used for three separate purposes: Setting targets, creating forecats and allocating resources. Since these results are usually different from each other (targets are what we want, forecasts are what we expect to get), we won’t get an optimal result from using it.

In StatOil they have developed an alternative format of planning called Ambition to Action. These are a few principles that are used when cdefining it:

  • Good performance is being better than those we compare ourselves with
    • It could be external companies or even ourselves, which means we are learning.
  • Do the right thing
    • Every new joiner receives a StatOil book (a thin one!) with some of the principles that guide the company, so they can all use their business judgement and make decisions when needed.
  • Resources are made available and allocated on a case by case basis
    • Bjartes compared having an yearly budget to having a bank that opens for only a month throughout the year. How can anyone make timely decisions with that ?
  • Business is forward looking and action oriented
  • Performance measurement is holistic, and composed by 50% results and 50% behaviour

These principles are used to define what to do in the company, in a process that goes like this:

1. Strategic Objectives -> 2. KPI’s -> 3. Action & Forecast -> 4.Individual goals

So the company is going to set strategic objectives which are then converted in KPI’s. These are used to define the things that need to be done (Ambition to action), which reflect on how performance is measured for everyone in the company.

Some interesting thoughts he shared when explaining the process were:

  • The perfect KPI doesn’t exist, since not everything that counts can be counted.
  • StatOil creates around 1100 Ambition to action plans, and these are not a reporting tool, but more a guidance on how you as an employee should manage him/herself. Apart from that, everything is open, so everyone can see everyone’s else goals.
  • Performance measurement is usually based on teams and, as said before, divided between results and behaviour. Assuming that the environment very often changes, how someone behaved in that occasion is as important as the results he/she delivered.

The last point that was made during the presentation is how StatOil is moving from a calendar-driven model to a business-driven one. There are no more annual versions of Ambition to Action being created, and they can be changed at any time. The performance review is still happening annually, but Bjartes mentioned they are currently revisiting it now.

Overall it was a great introduction to Beyond Budgeting and how it is applied at StatOil. If you are interested, there is more information here and here.

Bjartes is speaking in the Thoughtworks Live Australia event. If you have a chance to go, don’t miss it.

No comments »

Posted in Agile, Development, Lean, Learning, Management, Presentations

Tags:

Managing Dependencies – The Simple Way

July 20th, 2011

One of the common problems software teams face is that they are not alone in the world, and usually depend on other teams to deliver functionality to the end customer.

When the two projects are happening at the same time, it gives both teams the advantage that they can communicate with  and adapt more often to each other’s needs. It does bring a question on how to synchronise two independent streams of work, since not doing it might bring a lot of headache in terms of stories being blocked because dependencies haven’t been met, which ends up being a lot of waste.

In my current project, we have been using a visual technique to managedependencies which has been proven successful in terms of identifying dependent stories with minimal overwork.

  • All stories that rely on external teams receive a red dot, which represents they can’t be played before the dependency is verified.
  • Once the external team finishes their part of the work, a blue dot is written on the card, specifying the dependency can be tested by our team
  • An integration test gets written against that feature, and if everything works as expected, the story received a green dot, showing that it is ready to be played

So far, the technique has reduced the feedback cycle between us and the external team on which we depend. Testing the stories just after they have been developed means that we can give early feedback about if they are working or not, and avoid starting to work in tasks that cannot be completed.

 

No comments »

Posted in Agile, Development, Lean, Management

Tags:

Page Model with Cucumber and Capybara

March 4th, 2011

I’ve spent some time today changing the Cucumber/Capybara tests in one of my pet projects to use a page model. Since I didn’t find much stuff on the interwebs about it, why not write it here ?

The idea behind having a page model is to keep steps related to a specific page on your app in the same place, so you can reduce the repetition of steps in different tests. Is definitely not a complicated practice, and setting Capybara for it is a simple step.

Setting the context, Im using Cucumber 0.10 with Capybara 0.4.1.2 and Rails 3.0.1. Have done the standard installation steps recommended by the cucumber-rails github page.

The only modification I’ve made with the created structure is adding a folder for the page objects, so the final structure is this:

As you can see, inside the pages folder there is a home page file, which is responsible for every action/assertion related to the home page.

Nothing new with the cucumber features, which keep having it’s standard style

Feature: Manage tasks
In order to manage my tasks,
a user
wants to create tasks in different categories

Scenario: Create a new task
Given I am in the Do Me home page
When I create an urgent and important task with description "my task"
Then I should see "my task" in the "Urgent and Important" section

However, in order to create our page object, we need to inject the test driver on it, which in Capybara’s case, is the session object.

Given /^I am in the home page$/ do
@home_page = HomePage.new(Capybara.current_session)
@home_page.visit
end

When /^I create an urgent and important task with description "([^"]*)"$/ do |task_description|
@home_page.fill_task_description(task_description)
@home_page.check_important
@home_page.check_urgent
@home_page.create_task
end

And from there is just the trouble of creating the page class (or do like me, who shamelessly copied the style from here).


class HomePage


URL = "/"

def initialize(session)
@session = session
end

def visit
@session.visit URL
end

def fill_task_description(description)
@session.fill_in("Description", :with => description)
end

def check_urgent
check("Urgent")
end

def check_important
check("Important")
end

def create_task
@session.click_button("Create Task")
end

And that’s pretty much it, now is just choosing your preferred driver and run the tests. As you can see, not much effort for a nice improvement.

3 comments »

Posted in Development, Rails, software, Tests

Tags:

Can I just throw it over the wall ?

February 15th, 2011

One of the good things I’ve took from one of the recent projects I’ve been in was the way the handover of stories from Dev to QA was done.

I mean, the handover topic is something that Im usually asked about, and I’ve never had a decent answer for it, since in my experience it has always been something like this…

Is this story ready to Qa ? Well, I think so,  it must be !

However, in the project mentioned above, at some point we had lot of bugs. Not really serious ones that would make us worry about the quality of the code we were writing, but a great number of small and annoying things that showed us we weren’t being really careful when developing a story.

Most of the stories that we “delivered” (yeah, right…) came back with a considerable number of small fixes to be done. Needless to say, we were losing a lot of time reworking things that should have been caught before finishing it, and not getting much code across the line because of it.

So we had some discussions about the problem and what we came up with was an amazing… checklist.

If we, as developers, were being sloppy when finishing the stories, why didn’t we have a list of what we had to do before considering it ready ?

As you can see above, there is nothing incredible about it,  just the fact that it made us remember what to do, something that is a lot of times easier said than done. Looking at this simple list I can make sure I always test the story against all the browsers we support, as well as verifying that the acceptance criteria were really met.

Talking about acceptance criteria, another goodness that came with it and facilitated the whole process was having mind maps describing what QA’s were going to be testing in every story.

Having this information available and easy to understand was miles ahead from the traditional “I’m going to find bugs in your story” mentality that dominates some teams. As usual, cross-role collaboration was a huge win for productivity.

mindmap

Knowing what was going to be tested enabled developers to take a look at the story with different eyes, verifying if all cases were accounted for before actually handing it over. As expected, we delivered more.

No comments »

Posted in Agile, Development, software

Tags:

What’s the Tech Lead Doing Anyway ?

August 11th, 2009

Some days ago when having a discussion at work about the responsibility of the tech lead in an agile team, I’ve realized that this is not a so simple subject as I thought it was. Therefore, good subject for a post : )

But before being dictatorial and just writing my opinion, I ran a small twitter poll asking about this subject. Fortunately, most of the answers matched what I think in some level, so hopefully I will be able to cover it all here.

Before starting, a last note. I was reminded that the term tech lead might not be so used and known as I think it is, so if you don’t use this term at all, sorry : ). You can replace tech lead for architect, technical manager, master jedi, whatever you feel like…

Giving an introduction, the tech lead (TL)  term is defined here as a person who has the technical overview over a specific project. Some people disagree about the need for a tech lead at all, but that’s the topic for another post, and here we will assume that the tech lead exists and is a single person. Ok, that was the easy part.

Now the more subtle (and polemic) part comes here, so I will give my opinion on it (with the help from @dtsato and @flessa).

What a tech lead should be doing:

Have a technical overview over the whole project – As a developer doing everyday work, it is easy to lose the long term perspective about where the project is going and make decisions that will be better in the short term, but harm the project in the long way. It’s the job of the TL to keep that in the mind of the development team.

Make sure the project has a common face – Standards are important IMO, and making sure the project still makes sense as a whole, avoiding knowledge silos it’s the job of the TL. He shouldn’t have to enforce standards or ways to develop code, but facilitate the discussion within the team.

Remove technical impediments – As the most experienced person in the project, its natural that sometimes the TL will be the person in the best position to remove technical blockages that the team might have.

Bring people to a good technical level – If the team has different levels of experience, the TL should work to help people achieve a good work quality by sharing his knowledge and incentive others to do the same.

Write code. Write a lot of code – The TL is not a superior being that gives directions from the top of a mountain. Don’t know about your opinion, but if I can’t rely on the TL to sit down and pair with me when I have a problem I can’t solve, it’s no good to me.

I think that is enough for now. Now, for what the tech lead should not be doing:

Be the person responsible for the code – Being the tech lead doesn’t mean being the owner of the code, or the team’s boss. It’s everyone’s job to create high quality software, and the TL should only expose problems to the team and lead them in the right direction (emphasis on lead, not mandate).

Making all the difficult decisions alone - During a project, the team will be exposed to different technical decisions that will have to be made. Allowing the TL to take them alone just expose the team to more risk, since they won’t understand/care about what was decided. What we want to achieve is that Paulo exemplified here.

Impose his opinion – This is probably the most important point. Remember collective code ownership ? It is still very important. No matter how brilliant a TL can be, if he can’t share his knowledge/decisions and specially the responsability with the rest of the team, things will go bad.

9 comments »

Posted in Agile, Development, Management, software

Tags:

Dev Complete? No!

May 12th, 2009

Recently we’ve had a discussion in a project I was working on about the concepts behind dev complete and qa complete stories, which are normally in a lot of agile wall’s swim lanes, and how they affect the project’s flow.

The point here is not to discuss how to measure your goals, since this was discussed in previous posts, but what I wanted to explain is how (what I’ve realized during that discussion) I don’t like the term dev complete, and why it can affect your team.

First of all, development complete implies the idea that we don’t need any more development in one specific story, and as anyone who has been in an agile project might have noticed, this is less true than we wanted it to be.

What frequently happens is that stories which are in the dev complete lane come back to development when they don’t meet the QA criteria, and suddenly development has to be done again for something that didn’t need any more development.

And what I find most annoying is that development complete has the word complete on it, which has an underlying meaning that someone (the devs, in this case) have completed their job, and that they could feel good about it at this point.

What goes away when this assumption enters someone’s mind is the fact that the objective (for all the team, including those devs), is after the qa complete stage, when the story is actually delivered. And this situation just gives another motive to the always disturbing separation between developers and qa’s.

So if you believe in how measures affect the results of a team as I do (more info on that here, here, here, here, here, here and here), change all your dev complete stories to qa ready, or something similar, and enjoy a little bit more peace of mind.

4 comments »

Posted in Agile, Development, Management

Tags:

What is Your Goal?

April 21st, 2009

One of the best things about Agile is the introduction of software development as a system. Software stopped being treated as a sequence of separated steps to be seen as people with different competences working together to achieve one goal: deliver software.

This is not new in any sense, and it was exemplified by Deming on one of his books:

I could do a much better job (fewer mistakes) if I knew what the program is to be used for. The specifications don’t tell me what I need to know.

Despite this advance, most software development teams fail in really understanding this concept, and still normally don’t see the power of using one unique measure to manage the project, not getting the idea that the effort of the system should be only measured once, in what is its goal.

You must be asking what is the problem of having different measures to verify the sanity of the project. And that is what Peter Drucker explains in his Post-Capitalist Society book:

In knowledge work… the task is not given, it has to be determined. ‘What are the expected results from this work?’ is the key question in making knowledge workers productive. And it is a question that demands risky decisions. There is usually no right answer; there are choices instead. And results have to be clearly specified, if productivity is to be achieved.

What it means is that tasks cannot be fully specified anymore, the workers have to make decisions every time about how to proceed in certain situations, and they can just do it correctly if they have a clear vision of what is to be obtained, and what is the final goal of the work they are doing.

This concept is also illustrated in the draft version of Mary and Tom Poppendieck’s latest book (still in the draft version), when they are explaining the case of Southwest Airlines, which has as main advantage against the competition, the fact that its planes stay less time in the ground, thus generating more revenue.

Southwest maintains a systems perspective; it doesn’t let individual department measurements or increased revenue opportunities distract it from the primary objective of maintaining profitability. Southwest makes it clear to every employee – from the agent closing the gate to the baggage handler transferring luggage – what is important from an overall perspective. Everyone at Southwest knows the mantra: “Airplanes don’t make money sitting on the ground.” So everyone works together to get each plane in the air as fast as possible.

The important here is that we have one measure. One variable that everyone can rely on to make decisions during their work, and the ability to do it makes a whole difference in the overall performance of a team,  fact that often not considered in software development, where different measures distract people from the main goal.

As an example, a common situation I’ve seen in project is to track bugs within the iteration, and use it as a measure of code quality. Well, the goal of a software team is to deliver software without bugs, but it doesn’t matter at all if in the process of creating software bugs are found and solved prior to the software being released. If that is the way the team works best, so be it.

Another example is a case where a project had a problem with bugs creeping (this time, after iteration was finished and software delivered), and when discussing the fact we’ve realized that because of the pressure to deliver, we were delivering development complete, and not QA complete stories, so QA was actually done after the iteration finished, and yes, the team’s velocity was based on development complete points.

Well… if the goal you set to the team is to deliver dev complete stories, guess what you’re receiving in the end… dev complete stories!, it doesn’t matter how many times you repeat “Let’s focus on delivering quality software“. As Goldratt said, “Tell me how you measure me and I will tell you how I will behave.”

So, what is your goal?

5 comments »

Posted in Agile, Development, Management, software

Tags:

Distributed Source Control and Set-Based Design

March 10th, 2009

That distributed version control systems are the current flavour of the moment, everybody already knows, so I’m not here to talk about the N reasons why you should not use svn/cvs anymore.

But what I hadn’t notice until recently is that git (or any other DVCS) actually allow you to do one very important thing in software development: set-based design

As Mary Poppendieck pointed out:

Toyota and 3M use the same concept for product design.  They explore the entire solution space and find intersections that everyone finds acceptable, gradually adding detail and converging on a solution.  This approach is called set-based design, and contrasts sharply with point-based designs which start with a single solution that undergoes a series of optimizations.  In most cases, set-based design produces the best design in the shortest amount of time with the least amount of communication.  It’s strange that this principle, so obvious when you are scheduling meetings, seems counterintuitive in the development environment

The eureka moment came to me in my latest project (in which i’m using svn), when I was thinking about exploring an alternative path to some code that was already implemented, but I thought it could be redone in a better way. How to do it with svn?

I could enter the obscure world of svn branches and merges, where I would have to fight hard to get my code back in one piece, but that didn’t sound inviting at all, and that’s why I haven’t actually implemented the second option, waiting to be more certain about it.

The interesting thing is that since I’ve been using git for the last year, I always took it for granted, and didn’t actually realize this benefit from DVC systems.

So, if you are thinking about why change from cvs/svn to a distributed system, add this point to your list.

1 comment »

Posted in Development, software

Tags:

Does it Really Work?

March 5th, 2009

Last week during TW London Last Thursday event, I had the pleasure to see this presentation from Dave Robertson and John Johnston (or at least part of it), about how Agile and User Centered design are more a match, sharing goals and values, than different approaches to software development.

If you have some time you should really watch it, it is worth the time.

The overall presentation is really good, but the reason I’m posting here is one specific point that was mentioned, which I believe really hit the spot, and that’s when they say we should rethink the word work in the “the simplest thing that could possibly work” sentence.

This point goes back to the Agile Vs Usability discussion and it is very correct IMO, because it reiterates that development teams should not deliver any code just because it was quick to develop it and the client is happy (although he shouldn’t be at all) since it didn’t cost a fortune.

And what is interesting about this subject is how agile teams don’t usually accept low quality code standards (code without tests, lots of hacks, etc..), but easily accept low usability standards, not understanding that is also their responsibility to define what a good user experience is.

What I’m NOT trying to say is that the user should be left outside from the application design. He should definitely have his opinion (and a strong one), but should also receive advice in UX standards as much as he should in code quality, making sure that he understands what he loses when is trying to save money on each particular feature.

4 comments »

Posted in Agile, Development, Management, software

Tags:

Rails 2.3 New Features

February 2nd, 2009

In the set of new features from Rails 2.3, I was quite pleased by two of them: nested attributes and nested forms.

Both allow the creation of forms containing information about more than just one model, and may solve a recurrent problem I had in past projects, which has lead to some painful headaches…

Can’t wait to try it!

More information (source):

3.1. Nested Attributes

Active Record can now update the attributes on nested models directly, provided you tell it to do so:

class Book < ActiveRecord::Base
  has_one :author
  has_many :pages

  accepts_nested_attributes_for :author, :pages
end

5.1. Nested Object Forms

Provided the parent model accepts nested attributes for the child objects (as discussed in the Active Record section), you can create nested forms using form_for and field_for. These forms can be nested arbitrarily deep, allowing you to edit complex object hierarchies on a single view without excessive code. For example, given this model:

class Customer < ActiveRecord::Base
  has_many :orders

  accepts_nested_attributes_for :orders, :allow_destroy => true
end

You can write this view in Rails 2.3:

<% form_for @customer do |customer_form| %>
  <div>
    <%= customer_form.label :name, 'Customer Name:' %>
    <%= customer_form.text_field :name %>
  </div>

  <!-- Here we call fields_for on the customer_form
       builder instance. The block is called for each
       member of the orders collection. -->
  <% customer_form.fields_for :orders do |order_form| %>
      <p>
        <div>
          <%= order_form.label :number, 'Order Number:' %>
          <%= order_form.text_field :number %>
        </div>

  <!-- The allow_destroy option in the model
       enables deletion of child records. -->
        <% unless order_form.object.new_record? %>
          <div>
            <%= order_form.label :_delete, 'Remove:' %>
            <%= order_form.check_box :_delete %>
          </div>
        <% end %>
      </p>
    <% end %>
  <% end %>

  <%= customer_form.submit %>
<% end %>

No comments »

Posted in Development, Rails

Tags: