Comments for select *

Comment on Mother Of All UTF-8 Checklists by benny boy

benny boy — Mon, 29 Aug 2011 14:56:45 +0000

The collation-server value for my.cnf reads “utf8_generic_ci”, should be “utf8_general_ci”. Great guide aside from the typo.

Comment on Company self-examination by Wagner Herreklær

Wagner Herreklær — Thu, 07 Jul 2011 06:38:50 +0000

I believe you need a balance between criticism and complements – people feed on complements and for every negative comment they need 10 positive complements to balance it. People tend to notice only the negative and it breaks them down. A good leader must be able to adjust there leading approach to each specific employee – every employee is unique and demands unique access. By pulling together all workforce and making a discussion around this sounds like a plan – just remember that employees are different from one another, and there will always be those who steal the spotlight and others that will have problems sharing their thoughts. SE the working people – there the one holding the company up!

Comment on Company self-examination by exchangerates

exchangerates — Tue, 22 Mar 2011 07:07:14 +0000

I believe that leaders should also be able to create an environment of trust wherein employees feel empowered. Trust can be built by encouraging transparency in communication and information sharing. Leaders should also be able to create a sense of urgency by enabling the employees to see the truth of the company’s current state and as well as feel the “romance” of its possible future state.

These tenets are discussed at length by Vineet Nayar of HCL Technologies, in his book ‘employees first, customers second’.

Comment on No Scrum, No More by Pierre E. Neis

Pierre E. Neis — Fri, 04 Mar 2011 13:48:32 +0000

Hi,

Congrats for your "courageous" post. I do also appreciate your reasons to do not Scrum.

As a branded and certified Scrumers, I follow the line that this framework does not fit to all of us but, if I have to go to the core of Scrum: we have to continuously improve ourselves.

You taked it, you'd improved it, and choose a better path for the team.

Great stuff.

Comment on Automated Unit Testing for JavaScript by Bowmanave

Bowmanave — Thu, 20 Jan 2011 05:31:22 +0000

It would probably be good to start a javascript testing project in contrib (e.g. qunit), before trying to move it into core for Drupal 8. That way, we can have tests for Drupal 7 even if they're not in core, and it would be a great starting point for a JavaScript testing framework for Drupal 8.

Also, I'd like to note that I no longer think that using qunit is the best approach. While qunit is a wonderful automated JavaScript testing framework, my understanding is that it's really designed to test JavaScript independent of web content, not JavaScript that depends on PHP-driven web content (such as collapsible fieldsets, sticky table headers, tabledrag, and nearly every other major JavaScript implementation in Drupal). I think we should work out the details of a testing framework in contrib before coming in with a core patch.

Comment on Estimation Using Planning Poker in Scrum by Customer Experience, Design Thinking und Scrum: Wir führen die Themenstränge zusammen – Tag 5 der Stimmt Konferenz | Customer Experiences That Matter

Wed, 05 Jan 2011 07:53:31 +0000

[...] zu können: Den Backlog und die MoSCoW-Priorisierung, um effektiv ans Ziel zu kommen; mit dem Planning Poker Aufwände und Risiken für Aufgaben oder Projekt-Schritte schätzen; dank Timeboxing und [...]

Comment on 3 More Industry Problems by Döner K. Babb

Döner K. Babb — Mon, 22 Nov 2010 21:37:17 +0000

Vetkje om e e heilt eni asså, men … la gå!

Comment on 3 More Industry Problems by Geir Berset

Geir Berset — Wed, 03 Nov 2010 09:25:47 +0000

One more thing.

Just-in-time planning of details frees a lot of time of prematurely fooling around with too many details. This freed time should be spent analyzing the 'big picture'. Bby understanding long-term strategy for the project, this insight will translate into well-informed design decisions early on — such as creating a loosely coupled architecture at the right places which again will lend itself nicely to refactoring into future needs. All of this without significantly impacting us today with a lot of assumption-based development.

It becomes the best of both worlds. We are able to make small (but significant) investments for the long haul, while not losing focus on the imminent challenges.

Comment on 3 More Industry Problems by Geir Berset

Geir Berset — Tue, 02 Nov 2010 13:49:09 +0000

Thanks for the comment.

If I understand your use of "dynamic story card development" correctly, I agree with you. Keep planning on a strictly business value/strategic level. Break into details when it gets in line for implementation, just in time. Thus, details should only exist on ongoing work, not future work. This removes a lot of the need for extensive tools and backlogs. I really believe in going all-in (Tom Gilb-style) on ongoing work — specifying and measuring everything — but never on future work. Specs will be good only when we have as much knowledge as possible while writing them. We do not have future knowledge now, so we must wait until the last responsible moment.

I think this is what you mean by dynamic story card development?

Comment on 3 More Industry Problems by Jerry Durant

Jerry Durant — Tue, 02 Nov 2010 00:21:39 +0000

I have also found that dynamic story card development, as a catalyst for real thinking, is an exceptional way of breaking the big whole requirement spec mentality (especially since all is impossible to ascertain). Then through application of risk, business value and effort discussions; showing burndown delivery create an atmosphere of possibility!