Harry Nieboer

My Personal Christmas Greetings (Yep, I'm Singing!)

2009-12-26T12:07:00Z

OOMouse - More buttons for Open Office

2009-12-10T15:08:00Z

A super mouse optimized for the use of Open-Office applications has been announced. This programmable mouse has 512K Memory on board and an astonishing amount of 18! buttons.

If this evolution continues, will the difference between mouse and keyboard disappear in the future?

How would that compare to the zero button (but multi-touch) mouse from Apple?

Ivar++

2009-09-16T22:06:00Z

This week I attended a presentation by Ivar Jacobson at Microsoft in Amsterdam.
I've read several of his books, starting with a text on Objectory, an object-oriënted methodology considered one of the roots of RUP.

At Info Support we have already contacted many people from Ivar Jacobson's company.
This week was the first time I saw Ivar Jacobson and Pernilla Ramslov in person and could shake hands.

It was nice to hear Ivars passionate talk about working smarter (and not harder).
Smart can be defined (Ivar's words) as Agile++. It's just a next step, all you need is the right knowledge and the right experience ;-)

Ivar recently published a (related) whitepaper on Scaling Agility. That sounds like Agile++ too. Or am I trying to be too smart?

Generation Y

2009-09-16T21:40:00Z

Last week we had a quarterly meeting at Info Support. One of the presentations warned us about a new generation of people entering our workforce, and the workforce of our clients.

Generation Y is a term used for people born between the late 1970's and the late 1990's. They typically make a lot of use of, and are very familiar with communications, media, and digital technologies. They've been called "self-absorbed, entitled or even narcissistic".

Lindsey Pollak is not that pessimistic. She concludes "Yes, those Gen Y-ers are a little different than the rest of us. But I assure you the benefits of having one (or more) by your side are well worth the difference."
Read her post on five reasons why she loves her Gen Y Assistant.

As Requirements Specifiers It is good to take a look at the list as Lindsey concludes:

- They bring up things that never occured to other people (that might be good news, and it might introduce some new risks in your project)
- They are techier (very familiar with the latest technologies and trends, so they might expect that kind of functionality in the system you're specifying)
- They understand personal branding (and thereby they might more than other stakeholders wish to have there name connected to your project, or not)
- They are not really into 9 to 5 (so they answer there emails at midnight, and might appreciate you doing the same)
- They have a lot of energy (and all of you know what a good product champion can do for your project)

In the light of agile development with the customer on your side, I expect it will be great fun pairing with a Gen Y customer !

Lucky

2009-05-23T22:59:00Z

Sometimes you are lucky, some times you are not.

In this video montage everybody is lucky. Hilarious is the part of the bankrobbery, a must see!

- bankrobbers run out of the bank and jump in their car.
- the alarm from the bank attrackts two policecars
- they park their cars in front and at the back of the bankrobbers
- bad luck for the bankrobbers?

Tired of managing changes? Try this for a change!

2009-05-18T23:14:00Z

As a Business Analyst I'm concerned with scope creep in my projects.
One of the top priorities in a project is to get control of changes.

But let's be frank, sometimes making changes is fun!
"The bright side of life" features a list of 25 Little Changes to Make the Day More Exciting.

The blog is a golddigger's paradise if you are looking for the unexpected.

"Shall" lost in translation

2009-05-17T22:49:00Z

"Shall" does not translate very well.

Scott from Tyner Blain presumably read the post on optimal options for sleep schedule.

At least he apparently had some time left to get to the bottom of a problem.

Scott translated the word "Must" from English to 41 other languages, and translated the found word back. For 41 of 41 languages this exercize returned the word "Must".

He als found that the word "Shall", translated from English to another language and than back, does not translate back into "Shall" most of the time.
It is translated in Will, Should, Must, To be, We, I, Point, Has and Going. His advice: "You need to use the word must when writing requirements to avoid ambiguity"

Mastering one Scrum team at a time

2009-05-17T22:28:00Z

This week a group of Info Support collegues, including me, became Scrum masters.

We learned a lot from the training, but afterwards we discussed the possibility to run multiple Scrum teams as a Scrum master.

Michael James from Danube Technologies makes it clear why mastering a Scrum team is a full time job.

Michal presents a nice Checklist for Scrum Masters. It's almost two years old now, but still a good list.

Danube also hosts several whitepapers about Scrum and Agile.

When you need more than eight hours in a day

2009-05-17T22:16:00Z

A lot of times I heard the excuse "Sorry, the day only has eight hours for me" when I asked people to help me out.

It seems to be an arguement that is hard to defeat, as the day only has 24 hours and you also need your eight hours sleep a day. Or don't you?

Sleeping eight hours in a row is not the only way to get you daily dosis, there appear to be more optimal options for sleep schedule.

Ever tried the Uberman schedule?

Useful techniques alongside Use-Case modeling

2009-03-12T13:06:00Z

Alex Papsworth (stating he is a Dogsbody doing unpleasant work) actually did a nice post on his Business Analyst Mentor blog on useful techniques you can use alongside Use-Case modeling.

He mentions storyboards, wireframes and prototypes.

One of the reasons for using other techniques is that different people respond better to other techniques.
Some people prefer the visual approach of storyboards, wireframes, prototypes. Others are happy with the more formal approach of Use Case modeling (which can be done very interactively).

When choosing techniques, it is alway a good idea to keep in mind the reasons for modeling:

Requirements Models Allow Us to Organize Our Data in Multiple Ways.

Models Help Us to See Things That Might Be Missing.

Models Create a Visual Representation of What’s Expected.

Ales states: "When combined, the techniques bring life to the use cases".

I add: "When combined, missing things are easily identified, resulting in better requirements"

Those interested in ***deep*** details on combining informality with precision should look into this paper of Michał Miałek.

Making life easy - helping others succeed

2009-03-05T22:26:00Z

In our profession we are constantly searching for ways to make our life and our work easier.

Sometimes, you ask an outsider to help you, to facilitate you. Once in a while you get great help. You don't know what the facilitator did, but somehow your meeting delivered results, your brainstorming session really worked or a stalled project gets moving again. And amazingly, the facilitator did not give any input to the meeting, all the ideas came from your projectgroup

How did this facilitator make this all happen?

Ingrid Bens wrote a step by step guidebook on Facilitating with Ease well worth reading.

An handy fact sheet was excerpted and adapted from this book, including do's and don'ts on using flipcharts, a facilitation at a glance chart and a comprehensive list of behaviours that help and behaviours that hinder a facilitator.

A checklist and a handy observation sheet (how well does the facilitator do her job) derived from the book are available from AAMC.

When a Vision is not a shared Vision

2009-02-04T16:46:00Z

Some years ago, the project manager of our software project was having a hard time collecting all the stakeholders for our project.

In the mean time, in order to do something useful (or maybe not so useful, see later) the project team crafted part of the Vision document for the project.
As we were using RUP in our project, part of the Vision was to document the problem statement and the product position statement.

The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved.
The product position statement is the “mission statement” for the system to be built (the solution).

After a while, when all the stakeholders were connected to our project, we proudly presented our problem statement and product position statement.
The stakeholders were not amused! Even though the crafted statements made some sense, they definitely were not discussed with the stakeholders and therefor did not describe a shared understanding of neither the problem nor the solution. Our Vision was not a shared Vision!

We organized a brainstorming session with our stakeholders to develop the shared vision and came up with statements all the stakeholders agreed on. In our opinion the differences with respect to the content were minimal. With respect to the followed process the differences were huge of course! The new Vision was a shared Vision!

Some time ago we discussed a project with a problem: it had no shared vision. The team used the vision of one of the stakeholders, but that vision was not shared by the other stakeholders. It resulted in years with ongoing arguements on the scope, the quality of the system and the way to go.

I suggested to organize a session with all the stakeholders to define a shared vision. To my surprise the project manager ignored the advise argueing that discussing the vision would potentially have a huge impact on the scope of the project. He also feared the risk that the stakeholders would hold him responsible for using the wrong Vision and the wrong scope,
He would not have that fear if the Vision would have been a shared Vision from the start.

Requirements freeze against scope creep?

2008-12-28T18:46:00Z

Recently an interesting question was asked:

Is a requirements freeze in a software project a bad idea?

The person asking the question was running a project that got delayed because the users kept adding requirements.
Robin F Goldsmith answered that in his opinion a requiements freeze is the wrong solution to the problem of scope creep.

Mr Goldsmith must have been really happy the question came along, because he wrote a book (http://www.gopromanagement.com/book.html) on the subject.

Requirements freezes usually don't work because they don't address the real causes of creep:

Project budgets and schedules are commonly fixed without proper understanding of the work that must be done and the time and effort needed
Scope is often not defined in terms of requirements that provides value when delivered. As a result everybody has a different idea about what must be delivered, making everything look like a change.
Most creep is actually not new or changed requirements but rather new or changed awareness of requirements that have been there all along but haven't been identified adequately

In essence, Mr Goldsmith suggests a two-step process:
- define the scope in terms of REAL business requirements (or deliverable "whats") that provide value when delivered.
- base your estimates for budgets and schedules on "how" to accomplish these REAL business requirements to make them more reliably.

This advice matches nicely to our guidelines on the use of Use Cases. We state that Use Cases should deliver REAL value to the stakeholders!

- High Level (shortly described) Use Cases define the scope. This scope is in terms of the value to be delivered and is froozen.
This scope becomes the basis for estimating budgets and schedules.
- When we are unsure about the estimates or the solution, some more elaboration on the Use Cases is needed before we can give accurate estimates.
This is common to all projects, typically we would elaborate when we are unsure about the (logical or technical) solution or the process to get to that solution

Templates considered harmful

2008-11-30T21:35:00Z

At least one hundred times the last few years, while introducing collegues and clients to our processes, the infamous "Where are the templates?"-question popped up.

For some reason lots of people think using a process is mostly filling in the templates. And who is to blame them, as the templates that are offered nowadays contain a lot of process knowledge inside the template. I suppose you all have seen the blue printed guidance (InfoBlue) in RUP templates.

At my former company, we extended the RUP process website to include the companies best practices and to tweak the processes to the companies preferred toolset (not being the Rational toolset). We proudly presented the result to the company and asked their opinion. The (by far) number one remark was that they missed a way to quickly get to the templates.

In my opinion, as all future users of the process would be given extensive training, the need for this quick access to the templates would quickly be gone. After the course everybody would be able to find the artifacts and accompanying templates themselves and would know when and how to use them.

In my opinion, adding the quick access to the templates would do more harm than be helpful, as it would encourage people to jump to the templates and use them without thinking.

I considered easy access to templates to be harmful, but was alone in my opinion. At least I thought I was.

I'm happy to find out I have at least Joel Spolsky (scroll to the end of his article), Ivar Jacobson and Kurt Bitner on my side.

I also found out that the catchy title of my blogpost was not as original as I thought. "Templates considered harmful" is good for 155 hits on Google.

It's all about teamwork, isn't it?

2008-11-25T23:52:00Z

When you think you have seen all about teamwork, you have not seen despair.com yet!

This is the place to go for your demotivators ...