Archive for June, 2009

How some piece of software started a very bad habit

2009/06/30 4 comments

I’ve never been a person who’d been late for meetings. I think I was late once to school and is the kind of person who really makes sure that I’m on time. We’re always first arrivals at parties.

But when I started working for my current employer, I started missing meetings and becoming late at occasions. I even have double booked meetings in my calendar. After having worked for nearly 15 years, one cannot help wondering what started this bad habit.

And it boils down to software which does not help me in the most fundamental way. When I’m invited to a meeting it is crucial to know if I’m already booked. I guess that this is just not me; most people have a problem being at two places at the same time. So, a calendar for professional use should probably warn me directly if I’m invited to a meeting when I’m already booked in my calendar.

Also, if I make a booking, it’s good to know if the participants are available or not during the time in question. And again, this is hopefully not just me but a universal need for everyone.

So, what happened was that I started using the calendar in Lotus Notes, and who ever is responsible for this system does not find this to be a fundamental need: I need to do some clicking before I learn if I’m already booked or if I try to make a booking when people are already busy. And if I accept or suggest a double booking, I’m not prompted or warned. I guess the product owner at Lotus Notes is a super hero with the power to be at several places at the same time, so I guess that is why he haven’t seen this need as a universal, fundamental need for the booking process.

So, what has sneaked into my habits during the months past is that I’m always double booked for meetings. Since I can accept or book meetings without this being flashed in my face, I’ve started to see it as less of a problem. But it is a problem and a bad habit.

But the lesson is more important than so. If we just imagine the product owner of Lotus Notes being that super hero who can be at many meetings at the same time, he can either realize that his reality is a bit different from others, why a need that he doesn’t have is really important. But one cannot wonder how often you just disregard a crucial need just because your reality is a bit different from everyone else.

News in Team Foundation 2010

From a project manager’s point of view

On 2009-06-25, I and a colleague listened to a seminar concerning news in Team Foundation Server (TFS) 2010. We are currently using TFS 2008 mainly for source code handling and tracking progress (using the work item tracking functionality) during projects. Here are my notes.

Fundamental changes

TFS 2010 include a new client, especially for testers, Test Essentials or Test & Lab Management. This will mean that to be able to work effectively as a test leader or tester, you don’t need a Visual Studio installation. It is today unclear how licensing will work with the new client.

The integration with Microsoft Office require Office 2007.

SQL 2008, SP1 is required.

You can run a VS 2010 client against TFS 2008 SP1 and using patches, a user can run VS 2008 against TFS 2010. This enables a step by step upgrading of the environment.

The installation of a new server is complicated and takes a lot of time. You can though make the installation first and make all configuration in a second step, This means that the person responsible for installation does not need all configuration variables to complete the installation.

The possibilities for load balancing has been increased which would enable us to runt TFS on multiple servers and also make use of several SQL Server.

Work item tracking

The most important change here is the possibility to not only link work items but actually specify how items are linked. You can for example:

  • Specify a hierarchy. This would mean that we can specify which tests are included in a test plan or which tasks belong to a product backlog item.
  • Predecessor/successor relationship. This would mean that we could specify that one task is dependant on the for filling of another task.
  • Related items of a specific work item type. This would mean that we could specify requirements in the form of tests and we could then specify on a task Definition of Done in the form of which tests are to be passed to see the task as completed.


A smaller change is that you can group different work item types to ease the creation of reports and queries. Using our current development process, we have no need for this.

The reports are as before available in Reporting Services format but there is an increased number of Excel reports, which also use the data warehouse. This would make us less dependant of reporting services for our project management.

There is also a specific report called Agile Workbook. In this, a number of reports, focused on the product owner and scrum master roles has been gathered.


Building environment

The concept of Gated Build is introduced and means that when a developer checks in, he can make a test build before an actual checkin. This would better hinder checkins which breaks the build.

The build scripts use Workflow 4, which enable a more graphical view of builds.

TFS Admin Console

A new client, targeting the administrator wanting control of his TFS and include the functionality which an administrator needs.

Test & Lab Management

This is a Windows client which does not require Visual Studio and target the needs of the tester. Here a tester can set up test manuscripts, run tests and report bugs. What was also really interesting was that while running tests, a tester can choose to record his steps and when filing a bug, he can automatically send a film or pictures of the situation. The recording can then also be used when verifying that a bug is fixed: the macro retakes all steps to the failing step, which makes the validation faster.

What also was interesting was the possibility to set up virtual environments for different test scenarios, for example different cultural settings and configurations. Since a test is run in a specific environment, we can keep better track of the environment in which the tests are run and not run. Also, when filing bugs, a snapshot of the environment at the time of the failure is possible.


Visual Studio for Architects

The seminar did not cover functionality in Visual Studio but notable is the inclusion of modeling in UML using Visual Studio. Use cases and processes can be directly modeled in Visual studio and linked to code and work items. Also, it is possible to automatically derive a model from a current system.

Since this is stored in the source control system, the models would be source controlled, which means that you can track changes of the system and even see which checkins have changed the model.



Query handling

The visualization of a search result has been improved since you can view a tree view or a link of the items and their directly related items. You can also click and drag to move work items in the hierarchy, for example if you want to move tasks between sprints or product backlog items.

Queries can now be collected in folders and you can also make rights settings these folders to hinder users from accidently changing common queries.


Source control

You can in TFS see graphically how branching and merging has occurred and using a graphical tool merge.

Web client

The user interface in the web access has been improved and include a dashboard functionality to enable views which are specific for the different types of users.

Measuring productivity

You get what you measure

So true, so true. These famous words from Mary Poppendieck point at an important objective of anyone interested in their work.

But there is a risk to these words. Because you can be lead to believe that you can measure everything you want.

I want my son to love me. So, following Mary’s words I should probably measure his love. This should ensure me success in getting his love.

Sounds goofy? Well, to most sane people this sounds crazy. I cannot take out a chart and plot my son’s love for me.

But how about productivity? In the agile community I’ve read a couple of discussions about if you can use velocity to measure productivity. I don’t like this idea much. I use velocity for predictions and my priority. Story point estimates are in my world a relative value of size, and if I start measuring how many dots they complete every month, they are not sure to start making their estimates bigger. I still don’t measure productivity but I’ve also lost my chance of predicting my upcoming deliveries.

So, how do I measure productivity of the developers on my team? Well, I measure it by how happy my users and stakeholders Do they feel that the investment was worth it. But, but, you might say: that is too vague! And I say that just this is what matters. If the customer is happy about the investment. Can they make the money they hade anticipated or save the cost they were counting on.

And frankly, I have a hard time finding a good measurement of productivity. I can just look back at my role; project manager. What is a productive project manager? Is it the one who makes the most Gantt chart bars? Or holds the longest steering groups? How does a project manager know if he’s been productive a day? For me it’s a feeling. Some days I can have had this ten minutes meeting which clarified a lot of stuff which will save us a lot of coding time or make us reach our goals. But a numeric calculation, I don’t know.

It was perhaps easier when I was a test leader. And yet not. A productive tester does not find a lot of bugs, he prevents them from occurring in the first place. And how do you measure that? Yes, you can measure the decline in bugs, but how do you know if a specific tester was the reason.

So, to summarize; I wouldn’t feel productive as a project manager if I was asked to measure the productivity of team members.

Summer issue of Methods & Tools available

An issue by solely female writers, and it covers Testers/Developers, Mock Objects, Quantify Quality, Scrum roles, PDD and Open Source messaging services.

Categories: Agile

Are you planning a project or just drawing a Gantt chart?

I guess the main reason for most project managers to use Microsoft Project is drawing the traditional Gantt chart. It’s kind of obvious, since the Gantt chart view is the default view of the program. This view is also confirmed by the default fields that are visible. A task is in Microsoft Project described by over a hundred fields but only eight of these are visible using the default settings.

If you just start up a default session of Microsoft Project and don’t change any setting, this is how you define a Task:

· Name (Text)

· Duration (Days)

· Start (Date & time, even if only the date is visible)

· Finish (Date & time, even if only the date is visible)

· Predecessors (Numbers – ID of tasks which the task directly depends on)

· Resource Names (Names of Resources)


If you open one of the templates provided by Microsoft, they all look something like this:


There are all these tasks where one leads to the other and where the assignment is already done. You’re supposed to enter the Duration (in Days).

What is important is to understand what Duration is and what it’s not. In agile methodologies such as scrum, when defining tasks during sprint, you estimate how much work a task should result in. In other words; how many man hours it is estimated that a task will result in. This attribute is in Microsoft Project referred to as Work. And that is not the same as Duration. You cannot even see Work with the default settings. Work is what you get when you add resources to a task. But why is this? I believe that it all comes back to what I assume is the basic use for Microsoft Project; drawing the Gantt chart.

The Gantt chart is made up of all these blue bars, all connected to each other and leading to the end of the project. So the assumption of the Gantt chart is that if you make a Gantt chart, you can calculate when the project should be completed. That sounds great! Just what my stakeholders want.

The individual bars in the Gantt chart have a length and a place in time. The length is the attribute Duration, and therefore it makes sense to have the attribute Duration clearly visible and editable. And to place the bar in time you can use two methods, you can either link them together or you can place them on a specific date. The linking information is saved in the field Predecessors and you can specify a date by changing the Start or Finish Columns.

The final touch to the Gantt chart is the displaying of the resources names and that is stored in the field Resource Names.

So, there you have it; the columns in the default view of Microsoft Project are the ones which you need to draw the Gantt chart.

But does this mean that you can calculate the finish date of the project based on this? Well I think that experience talks against this. Just the fact that you cannot see the assumed workload makes the planning blind. And as I’ve previously discussed; since the focus factor is 100%, no holidays are in the system and the slack is 0, we all know that this is an illusion. Looking at the Gantt chart, I see the similarity with stairways and you get the feeling that all tasks are individual steps on the stairways. You just have to walk down that and you’re done. You can just check of the steps as you fly by them. Right.

Another problem with having the Gantt chart as the objective of your planning is what you want to do with that Gantt chart. Yes, you want that planned end date but you also want to show the chart to your steering group. And then you need to print it or take a screen copy and enter it into your PowerPoint presentation. Let’s see what happens when we open one of the templates:


But hey, I can’t see all those bars, and I cannot see all those rows! But then I need to collapse the heading tasks and change the timescale:


But then I’m missing out on my nice blue bars and it looks strange. So, to keep my project nice and clean, it’s better to keep the number of tasks down. Also, linking in the Chart view is a pain if you cannot see all the tasks at the same time.

And here, we also see a conflict with agile values. In most agile methodologies, you want to keep the tasks as small as possible to enable more accurate estimates. But this clutter up the Gantt chart, making it hard to read and linking becomes complicated.

Finally, we have another problem with having the Gantt chart drawing as the objective of our planning. The product backlog does not fit into this scenario. A product backlog is a prioritized list of requirements but this does not mean that the product backlog items are interlinked. So you cannot link them in the Gantt chart. But if you don’t link them, you don’t get your Gantt chart.

Next time you start Microsoft Project, ready to create the plan for you next project, keep your objectives clear; is your goal drawing a dreamy Gantt chart or do you have higher goals?

I’ve on this blog posted a tutorial on using Microsoft Project as a planning tool. I cannot say it’s easy but neither is planning. Thinking that you’ve planned your project just because you have a Gantt chart to show your steering group is a first step towards a challenged project.

There can only be one product owner – reply on harvesting developer intelligence

I got a very interesting reply on my latest blog post concerning the harvesting of the passion of the developers. Kevin E. Schlabach rightly pointed out that you could misinterpret my suggestion to leave some time for developer’s own initiatives and ideas.

So, just to make it clear; product owners can, if they think that the developers have great ideas, keep this in mind and when scheduling deliveries, leave some slack so if a developer comes up with a great idea, you as a product owner can choose to prioritize this. As Kevin points to, this is not up to the developer to decide. He can come with suggestions just like stakeholders, but just like everyone else, he cannot decide on priorities.

I’ve also been in situations where developers have thought up an idea and just started working on that instead of the stuff that needed to be done. To be frank, I’ve had some serious problems with this and finally had to take very drastic steps to end this, so I know that this is an important and serious problem. Serious, since other stuff isn’t being done, and dangerous since cheating in a team in contagious. It spreads to the other developers.

When you instead harvest the developer’s ideas you place them on the backlog like everything else. But I do like to make the guys happy sometimes and push up something on the priority list if it’s a really good idea and something which is truly valuable to the customer. But as a product owner, I am responsible, and it’s my decision to take.

Thanks, Kevin, for pointing to the risks for misunderstanding of my point of view. Keep the comments coming! I’m agile in point of view.

Don’t forget to harvest the passion of the developers

2009/06/17 1 comment

Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.

If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.

Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.

So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.

If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.

I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.

But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.