Gerd's Blog » projectmanagement

Let’s commit

Gerd Saurer — Wed, 31 Aug 2011 15:14:13 +0000

Currently I am the first time in a commitment setting process within a world wide company and have to say that it is really interesting to watch the process. I know from different big companies that they are handling the commitment settings in a similar way so it’s not a big secrete that at the end of the process every subsidiary, department, division, group, down to every employee need to commit on goals for the financial year. Normally reaching these commitments is directly related to the bonus which is big part of the salary. Commitments can be very specific, e.g. revenue for a product in the financial year, or a little bit more vague like involving in the locale community.

Everybody want’s to reach his goals in our current society, first of course because it means more money for the employee, but there may be also other reasons e.g. acceptance within the company or the possibility to change position. On the other hand awards are often use to honor specific persons within a company for specific work they have achieved. This two components try to drive employees to do the best they can to support the company.

Several times you see commitments not aligned between the employees. This may happen by accident, which can easily happen in such big companies sometimes it may also be by purpose, because management thinks this will increase the revenue for the company. Individuals try to reach their goals because of different reasons as mentioned above and competition starts to grow within the company.I like competition but I am not sure if it is a good thing within a company.

As I have a software development background just imagine the following: Every developer of a team would be driven by a commitment like the number of lines he writes for a program. I don’t think a valuable and stable SW would be the output of this project.

Currently I am thinking about a, in my opinion, better way to structure and drive business within companies that gives also the possibility for employees to stand out and get credit for special performance. Input welcome…

What I see questionable about this is that

Agile == Planing

Gerd Saurer — Sun, 16 Sep 2007 21:52:43 +0000

In one of Alister Cockburns last posts he was writing about Using RUP to fix Scrum. As i read his small article one sentence attracted my attention. He wrote: The pendulum has swung too far from “too much planning” to “not enough understanding”. I have the same feeling for some time now. The picture on the left shows a typical iterative scrum process where the backlogs on the left side are used to add features to a new iteration. What’s interesting is that more and more people and companies try to hold the Product Backlog as small as possible and push new features directly into sprints. So what is bad with this approach you would ask?

The backlog was intended as a place where ideas can grow. I never have seen Stories/Features that can be developed as they are written in the Backlog. In my Opinion this happens because most of the people involved don’t have or take the the time to think about the feature that should be implemented. A short cycle to develop new features should be aimed but not for every price. There are some other aspects that need to be considered and one of is that people must understand the product they are developing.

The second issue I have seen with short Product Backlogs is that Release Planing suffers. If you do not have enough Stories in your backlog to plan for the next release you will ship everything breaks down. In this moment everybody in the Team looses the goal for the Product. I would compare it with a scene from Forrest Gump where he starts to run without any goal. This is not working in reality.

There are three lessons I have learned in the last three years in reference to the issues I mentioned above:

Never start any sprint without a goal
Never start a product development without an Release Plan
Try to discuss Stories/Features as soon as possible with a bigger group of people

Agile JIRA

Gerd Saurer — Sun, 09 Sep 2007 12:24:25 +0000

Several weeks ago i posted about “Making JIRA a little more agile“. Today I found a Company called Green Pepper Software that has developed a product called Green Hopper which extends JIRA with stuff that is more common in the agile world than the list views the product provides out of the box.

They added an very intuitive Dash board for planing releases and a possibility to generate Burn down charts. In comparison with Mingle I have to say that i would prefer Green Hopper. Mingle is just an agile project management tool, JIRA was original invented as Bug Tracking Tool but can be extended with Green Hopper to an project management tool. The second advantage of JIRA is that there are thousands of other Plugins available and you have the possibility to write some of them on your own.

Making JIRA a little more agile

Gerd Saurer — Mon, 09 Jul 2007 22:50:00 +0000

We are using JIRA in our company as bug tracking tool and Confluence as our enterprise wiki. The tools are very useful and i like them but they need to be ‘pimped’ with some plugins and extensions. Concrete i am thinking about two extensions which i would like to see in the near future. Maybe i will find time to do develop them on my own.1) Print feature to story card
As we are using Scrum as development process in the company i’m working for i would like to see some possibility to print features/bugs on story cards that can be used for the planing meeting.

2) Dashboard view
The second thing i would like to see is a Dashboard functionality, which should not be seen as an replacement for the physical dashboard (otherwise my first feature would not make any sense) further more as an extension.

With these two extensions JIRA would become an more agile planing and tracking tool like Mingle.