Archive for the ‘software’ category

« Older Entries

Kaizen Lego Game @ Agile 2011

October 2nd, 2011

Everytime me and Danilo presented the Lean Lego Game, the common phrase we heard from the participants was

 We want to make this process better!

so for some time we had thought it creating a similar game focused only in continuous improvement, which would allow attendees to learn about improvement principles and practices while having some fun with Lego bricks : )

 

This idea has turned into reality in the format of the Kaizen Lego Game, which was presented for the first time at Agile 2011 in SaltLake City, earlier this year. Unfortunately Danilo couldn’t make it, but I was lucky enough to have Pat Kua as the substitute, helping me a lot with all the work involved in it.

 

Keeping the same format as the original one, the idea behind this workshop was to create an immersive environment where we could introduce continuous improvement principles and practices while improving a small Lego production line. Amongst the topics we focused during the workshop were:

  •  Kaizen
  • Value Stream Mapping
  • Inventory
  • Waste
  • Standards & Improvement
  • Cycle Time
  • 5 Whys
  • Cumulative Flow Diagram (CFD)

I was quite pleased with the result for the first time we presented it. The attendance was very good and we had great positive feedback (and also suggestions for improvements, which were great!).

Kaizen Lego Game

View more presentations from frankmt

Want to run it yourself ?

As with the Lean Lego Game, all the material to run the workshop is available through a Creative Commons Attribution-Non-Commercial license. If you are interested, feel free to run and adapt it, as long as we get given the appropriate credit and that you don’t use it for commercial purposes. We also would appreciate receiving some feedback on how it worked out for you.

We have created a package containing all you need to try it out in your environment, including:

  •  Facilitator’s Guide: instructions on how to run the workshop
  • Print material: instructions for participants and worksheets using during the activity
  • Slides

Just get in touch via email to request it!

Kaizen Lego Game by Francisco Trindade & Danilo Sato is licensed under a Creative Commons Attribution-Non-Commercial 3.0 Unported License.

 

2 comments »

Posted in Agile, Lean, Learning, Presentations, software

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:

Which side to pick ?

December 13th, 2010

What would you suggest should be done with a software development team where there is a significant difference in skill levels, let’s say up to 10x difference ?

Jason Yip shared this question he proposed to Takeshi Kawabe, who answered as follows:

Set the best performers as the standard. Pair people with the masters in a master-apprentice model. Find other suitable jobs for those without aptitude. Like professional baseball players, you need to practice every day to be a professional. Software development is a team activity an team are only strong as their weakest link.

Couldn’t agree more with it, but unfortunately is not the reality in most of the companies, that seem to be trying the opposite, setting an anti-productivity policy, which could be summarized as:

Set the worst performers as standard and create rules around everyone to avoid them making big mistakes. After that, just wait for the ones with aptitude to leave for a better place.

No comments »

Posted in Agile, Lean, Management, software

Tags:

Simple Planning

May 4th, 2010

What is necessary when you need to plan the next sprint/iteration ?

The picture above is the result of a chat with Lasse in my current project, and it was enough to set the expectations for the two weeks of work we had to plan.

Each post it is a story and time goes from left to right. Stories that are in the same vertical line can be played at the same time, and that big pile on the right means that those stories are dependent on each other, but can still be played simultaneously if developers are careful and communicate enough with each other.

This wasn’t anything planned, but it was simple enough for what we needed, and since we were working in a distributed team, taking a picture and sending it around was they way we had to share it with everyone. Worked just fine : )

4 comments »

Posted in Agile, Management, software

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:

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:

Porto Alegre Agile Weekend 2009

April 6th, 2009

For the Brazilian crowd (or anyone who wants to be part of it), between the 25th and 26th of April will take place in Porto Alegre (my home town : ) ), the 2009 Agile Weekend, which has my friend Daniel Wildt as part of the organizing team.

This will be hopefully the first of many Agile conferences happening in South Brazil, and will serve to boost even more Agile adoption in the region.

portoalegreagileweekend2009_banner_468x60

Needless to say, I really wanted to go, but London is not close enough to Brazil yet…

No comments »

Posted in Estimation, Learning, Portuguese, software, Uncategorized

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: