Where to start building up solution?

    We have passed kickoff negotiations and concluded that we have keep on building new platform from sketch. Our team and customer is leaning to be agile as possible, so we immediately started from elaborating use case. Our initial plan is following:

1. Login to the system
   
2. User management tool
   
3. other ...
   

    Is it a dream? Or deja vu? I have seen so many projects which started namely from those two items: login and user management, that I think there must be something enchanted and supernatural in those items.

Why login and user management is so important?

    Although login functionality is in 90% cases are the same (login, password, attempts to login before being locked and forget password, of course: nothing special) everybody wants to start from this. Probably because it's very evident part of the front page of any website.
    But pay your attention: this is nothing that can distinguish your web solution. In fact if you want to place on front page your logo and news and public speech of your CEO it would be further more recognizable and authentic. Don't you think so?
    Ah! I see: you still not sure what kind of info should you place on the front page. That makes difference: probably let's do easy start with login and password fields
    What then?
    Yes, sure we have very very sophisticated user management. Here how much roles we have, how to assign roles and groups to user, how to specify and handle rights of them on reading, writing and view profile of the assets?
    Wait a bit! Do we REALLY have assets in our system? Or any other entity? And do we really know what END-USER should see on our web page?
    In a second I realized an evidence: we DO NOT KNOW what our final user is going to see, but we already put efforts to build up user management tools ...
    I have a question: what kind of user do you have in your system? The answer would be (let us imagine a bit):

1. Administrators
   
2. Extended users
   
3. Normal users
   

    And what is distribution of those users?

    Can you believe that? Our users are mostly common users and they are community we creating system for! Why do you so anxious about administrator UI, rights, obligations and privileges until you don't know what user should see?
    Well, administrator is a God in system and if we wrote Bible today we probably started from definition of God.
    This may be a reasonable way to found new religion, but enterprise system is not The Universe and not something we should worship (Sometimes it is really considered to be like this). Let's try to think another way: try to imagine what your usual user should see in your system. Do you have a few arguments why he actually should use the system? And finally if you have perception about

• what user should be able to get from the system (features and information)
  
• what user should be not able to get from the the system (security)
  
• what is our benefit in the system?
  

    Does it mean that you can find out what is needed from user management, security, automation and so on just if you know aforementioned points?
    You probably will blame me, but my personal answer on the latter question is YES. Indeed, security rights, user management or any other management exist to allow user to have services they want to have, charge them for those services and to not allow them make harm to other users and system itself ...
    Even if your system is difficult for administrating but very friendly to end-user it can have success, but if it's not friendly to end-user whatever you have in back office it makes no difference for outworld anymore!

How should we start?

    Ok. Let's try to start with very small things ...

    I have a question: what kind of user do you have in your system? Answer is

1. Normal users
   
2. Extended users
   
3. Administrators
   

    Oh! That's much better! Let us think about normal users first :)

Good luck!

Who should take care about negotiations?

Yesterday I was blamed by my boss because of using term "collective opinion" during meeting with customer. How strange, three years ago I blamed myself for thought that "collective opinion" actually exist. I consider this as something very rudimentary inherited from old Soviet times. And my chief actually shares this idea

In civilized society there is no entity like "collective opinion". It would rather be an opinion of your self-important ego

There was indeed more ado about this, but generally I can assume two basic reasons why "collective opinion" is to be blamed:
* Collective opinion means someone talks as representative of others, who apparently where excluded from the discussion
* Collective opinion means that nobody can take over responsibility for what is said.

My questions I would like to raise are:
* What is collective opinion in "civilized world" in general?
* What is collective opinion in Agile context?

I concluded that collective opinion as term should not be so bad surprise civilized world. It accepts terms like collective security and Agile community even sustains having so called collective ownership. Collective opinion not necessarily brings you to chaos of responsibility, like collective ownership does not. In XIX century Gustave Le Bon noticed that collective opinion exists and sometimes brings to very positive (sometimes to very negative :) ) results. The most great distinction was discovering that sometimes collective opinion is biasing from average opinion of people that are "collected". The next great thing Le Bon discovered is that rules how collective opinion (or in general collective mind) is built up can be investigated and used. Since his lifetime there are many different things emerged: Dale Carnegie practical psychology, people management in XX of Peter Drucker, new approaches in XXI century, public relations (both white and black) and so on: nowadays we have huge set of methods to bend collective opinion to some certain way and approaches to control collective mind. So even people suffer hearing about collective opinion, we should admit that it exists, it is used and will be used until humankind lives ...

What about agile? Can it mitigate parasite usage of collective opinion?

What 2 of 4 principles in Agile Manifesto declare emphasizing on Individuals and interactions, from one side, and Customer collaboration, from another. So Agile pretty straightforward about who should negotiate with customer:
as many and as much as team member can.
Agile suggests having egalitarian team with equal rights and possibilities to make a contribution.

That's very logical: in idealistic situation all team members can ask responsible person about this or that and use his (her) decision to go ahead ...
What about reality? Customer (Product Owner in SCRUM) is indeed very complicated role in Agile: I know few cases when we really had proactive product owner that was able to answer incoming questions team need to ask. But in most of cases product owner is not motivated enough or doesn't have enough administrative power/time/resources to make decision or team members are not skilled enough to ask "correct" questions (Correct is not that word, probably to be exact I should have used figure like questions, that bring us to correct decision in the shortest way).

In our situation when team members are not acquainted with product, distant from customer and have language barrier this trouble is even bitter. More negotiation skill of team members are very different: some people can hardly speak English ...

One friend of mine says that the key is to have proper people in team. That would resolve the problem.
But people can never be ideal!
Can we make team better than people we have?
Some people call this synergy (collective benefits prevails the sum individual benefits). Can it be applied here? How do you think?

Agile team egalitarian, but it doesn't necessary mean that all should have the same activity. One of us is better in DB administration, somebody in designing UI, somebody in investigations, why can't we consider negotiations as one more branch we can play with. What if you have in team guy who probably not so good in developing software but can do following things better than others:
* explaining how software should work to team
* explaining how it actually works and how it can be changed to customer
I would say that it's better to have such team member than to not have. And it's better to keep him more organizing negotiations than to try to smooth distribution of negotiations between different other people.

Some investigation I would like to do, will show how it works ...
(if it indeed works)

Programmers Competition

Recently I partook in organization duties in All-Ukrainian Software Programmer Competition called Programmania.



This event pretend to be ultimate for all kinds of developers in this country. Spectrum of tasks indeed very wide: from high low level languages to logical tasks, from very specific languages like 1C (development environment for accounting management in CIS countries) to generic questions about project management. We were lucky to have good sponsors and adequate anchors (thank you so much, Leviza :)) and that was impressive that competition was conducted in 3 different location. But by the same causes we had troubles:

There were too many "bugs" in tasks, as I was watcher during competition(not only preventing cheating was my duty, but also suggesting what we were intending to mean by very confusing statements in task bulletin. The bulletin itself was also very wide: there was no chance to finish up it all before time is over.

The most annoying for me was one candidate, that was pretended to be keen in project management and I was often asked by him to interpret what was written. Oh, no this time it was not failure of our authors and experts, that created bulletin, but there reason was quite complicated language that was used in PM tasks to knock out potential cheaters ...

How do we assess participants and their work?
Sum of all chapters (say all programming languages and tasks)
Average scores for all touched topics?
The most successful chapters?

In any case test doesn't reflect skills of participants in being team members. In fact, it was rather the fest of egoism ...

Although competition is used to attract potential candidates to our job offers, it's very naive to think that competition would estimate people in proper way ...