The developer’s perspective

No comments

Saturday, January 28, 2012

You’re lucky you know, said the developer to the consultant. You get to come and save the day and leave before all hell breaks loose.

You got it all wrong said the consultant to the developer. I solve problems, teach best practices and explain what should be done and then they change and twist everything I said and done 5 seconds after I’m gone.


I wanted to share part of a conversation I had with a consultant I know.

SCISR Meeting with Corey Haines

No comments

Thursday, January 26, 2012

Today I attended a meeting of the Software Craftsmanship in Israel group with Corey Haines.

Corey gave a talk about agile practices and how to decide which to choose.

The talk went something like this:

Our objective is to reduce the time between doing something and doing the right thing and the time between doing one thing and starting the next one. And thus the goal of every single methodology is to make the feedback loop smaller – at all levels.

The main reason we want to reduce the feedback loop and provide value as soon as possible is that we want to minimize the cost of change. The cost of adding feature decrease over time – the promise of agile/code craftsmanship is that that time would not be exponentially – it would still be fairly easy to add a new feature a year from now.

Usually systems begin simple and beautiful and over time as the features accumulate it becomes more and more complicated. This can be handled by using evolution design/Iterative design which means that you take the time to clean your work after adding a feature instead of rushing to the next task on your to do list.

Early feedback by giving product early. Because it’s much nicer to change a system when its small. Thus reducing the time between doing something and finding out what you should have done.

The second part of the session was about testing and on how to reduce the Dev-QA feedback cycle which is why too long. In essence the objective is to know if the code today works as well as our code yesterday or even if our code work as well as 5 min. ago. Corey has talked a while about testing and automation and how to reduce the time to deployment.

One of the key points I liked was that we shouldn’t discuss whether or not a methodology A is better than methodology B we should discuss the value we’ll receive from using that methodology.

And finally a simple rule: If you choose not to use a practice, you must replace it with another of equal value.

Corey has answered a few questions from the audience about how to evaluate the cost of certain practices, mocking and working with legacy code followed by a short exercise – we had to parse Piet code by hand – namely the following “program”:

I caught two of Typemock’s finest – Gil Z. and Elisha writing a parser using unit tests and what looks to be a new soon to be released tool.

All in all an evening well…

Just a quick reminder


I’ll be presenting at the Agile Practitioners conference next week – so don’t forget to come and say hi. And incase you’ve missed Corey’s session or want to hear more of what he has to say about agile and software development in general – come to the Agile Practitioners conference next week.

Didn’t sign up yet – don’t worry because registration is still open. Just tell them I’ve sent you or better yet use this link.

See you there!

The evolution of a task board

1 comment

Friday, January 13, 2012

I’d like to tell you a story about how we manage tasks in my team…

Once upon a time (about a year and a half ago) I’ve started working in a new place. Since I’ve came from a company with very strong agile practice I wanted my new work place to be as agile as possible – and one of my first “missions” was to improve the way the team’s task tracking.

Task Board #1 – Sticky notes

I’ve convinced my manager to start using a “task board” which consisted of using sticky notes and one of the walls of the office. And as simple of that we had all of the team’s tasks in a simple, easy to read (and understand) display for the entire world to see. And the improvement was felt immediately. The team members could tell what are the priorities and their current and future work. And the team’s manager was happy because now it was clear what each of us were doing.

Some of the team liked the idea, some not so much… And over time it was clear who was updating his current progress and who’s tasks didn’t change on the board for the last two iterations.

Task board #2 – Distributed

I’ve done a quick check with the team to understand how we can improve the task board and one of the problem raised was that because the tasks were displayed on a wall that was less accessible to some of the team members they didn’t update their tasks as often as possible – instead of moving tasks from To-do to In progress and then Done they waited until several such “updates” were accumulated (or until they happen to pass by the wall) before moving the tasks on the board.

And so we’ve found a solution – each developer had his own task board right above his head. I know it’s not SCRUM but it worked for us.


And so we’ve continued working this way for a few months until another challenge presented itself…

From time to time a developer had to work on site which meant that he was out of the office and could not update his backlog another problem was that as the project progressed more and more top managers needed to know what the team is doing and whether or not we were reaching our goals. At about the same time the team has grown and we now were filling two rooms and looking to hire more developers and my manager had problems tracking the team’s goals.

Task board #3 – Excel spreadsheet in shared folder

Building upon past experience my manager came up with a simple Excel spreadsheet that was placed in a network share and that the team could update. The advantage was that Excel files can be copied, sent on email and shown at meetings a fact that helped explain what we were doing and how much time it would take to project managers, product owners and top management of our company.


We worked with the excel for a few iterations and it worked for us – we could move tasks between the team and everyone knew what everyone did. But the more we’ve used it the more it became clear that this “Excel task board” was holding us back. Since only one user is allowed to update the file – whenever two developers needed to update their progress it caused us grief – especially before start/end of iteration when all of us needed to update the file at once. Another problem was that once an iteration ended another file/book was created and the old iteration data was “archived” never to be seen again.

We knew we needed a better solution and we’ve found one just under our nose – TFS. We were already using TFS for source control and continuous integration (CI) server so why not use it to track our tasks as well.

Task board #4 – TFS + Work Item Manager

I was able to update the TFS Task using Visual Studio and we had a simple SCRUM workflow:


Using this task we were now able to use TFS as our backlog and task board. Another added bonus is that using Telerik’s TFS Work Item Manager we were able to see the old task board we were used to see on the office wall:


Now we had it all:

System that we can update easily – from the comfort of our Visual Studio

Easy to understand visualization

Statistics on iteration, remaining tasks and team progress

Project dashboard

And this is how we work today.


The lesson of this tale is that you should not be afraid to change. Just because we were using a tool that worked for us in the past didn’t mean that that tool cannot be changed if a better alternative is available, or if he required functionality changes. Because being agile is embracing change not just in the product you’re delivering but also the way you deliver it.

One final note

Using a task board is a simple practice and yet many teams just don’t track their tasks properly. Showing my team to use a task board is only one of the ways I’ve used to make them more “Agile”. If you’d want to learn more about how to make your team more agile or looking for tips and tricks that I found useful – I’ll be talking about it on my session at the Agile Practitioners Conference at the end of this month.


Happy Coding…

Related Posts Plugin for WordPress, Blogger...