Some day, somewhere in the net there was iBlog. It was about everything and nothing. A few persons was reading it, some of them maybe even liked it. But I am not interested in writing about myself anymore. This blog will be about Project Management. Less personal, but in fact it will be my personal tool: to not forget what I have learnt. And what I ll learn in future.
RSS
sobota, 22 sierpnia 2009

Management styles might be divided, at least for my own purpose, into two basic categories.

The first category is black/white style. A black/white manager usually manages in the finger-pointing way: most of the time he is engaged in finding guilty (black) persons. You can either do something well (white) or wrong (black). Of course in the constantly-changing business situation this means that white results will be found as black tommorow.

The second style will be... you'd say: aah! the shadows-of-gray style! I'd say: no! - shadows-of-gray is just a slight divergence of black/white style, used by managers having the main goal of self-protection (i.e. job protection). They just use shadows of gray, in a more diplomative and political way, but the effect is the same.

The second style is more colorful: green/yellow/red. This style addresses issues, problems, risks and business situation changes, not guilts of the colleagues. The situation may be green. It doesn't mean that somebody done something right or wrong. The situation may be yellow - this indicates that some escalation might be needed and corrective actions must be taken. The situation may be also red - this indicates that escalation is a must, and resolution of the risk, issue or problem is beyond reporter's management level capabilities. None of these colors say anything about who's fault it is, who's bad, who's good. It's just plain, objective (although usually qualitative, not quantitative) report of current business situation.

Look around you and try to divide managers to those two categories. Beware of the black/white ones because in case of difficult situation, they will, sooner or later, try to fingerpoint you black. If you see such a threat you can easily win the black/white fight, even in Taylor-style managed organizations, with just bringing buckets of red, green and yellow paint. Just bring them early enough, don't wait until the situation is really red.

wtorek, 07 kwietnia 2009

One way to avoid the large penalty for a change during final production is to make the right design decision in the first place and avoid the need to change later. That was the Detroit approach. Toyota and Honda had discovered a different way to avoid the penalty
of incorrect design decisions: Don't make irreversible decisions in the first place; delay design decisions as long as possible, and when they are made, make them with the best available information to make them correctly. This thinking is very similar to the thinking behind just-in-time manufacturing, pioneered by Toyota: Don't decide what to manufacture until you have a customer order; then make it as fast as possible.

Lean Software Development: An Agile Toolkit, L&M Poppendiecks.

 

wtorek, 24 marca 2009

Performance rating of a manager cannot be higher than the one we would accord to his organization [he manages].

Andy Groove, High Output Management

sobota, 28 lutego 2009

ALM is the connection between the tools, not the tools themselves.

Carey Schwaber, Mea culpa, ALM toolmakers say

 

Recommendations: Not let support for requirements management drive their ALM tool selection. [...]

  ALM 1.0 solutions don’t offer much support for ALM beyond what can be accomplished through brittle tool-to-tool integrations. Characteristics of ALM 1.0 solutions include: 1) a single tool for each role; 2)  redundant and inconsistent ALM features locked in practitioner tools; 3) microprocesses embedded in tools and macroprocesses embedded in tool integrations; and 4) integration through brittle repository synchronization mechanisms.
  Characteristics of ALM 2.0 solutions — tomorrow’s ALM platforms — include: 1) common services available across practitioner tools; 2) practitioner tools assembled out of plug-ins; 3) repository neutrality; 4) use of open integration standards; and 5) microprocesses and macroprocesses governed by externalized workflow.

The Forrester WaveTM: Requirements Management, Q2 2008, Carey Schwaber and Mary Gerush

wtorek, 10 lutego 2009

No matter how annoying the situation feels today, it will be funny in five years. So do take notes.

Cornelius Fichtner, PMP

wtorek, 20 stycznia 2009

I hate ClearQuest. Quoting http://blogs.onresolve.com/?p=47, it's a clunky, ugly, grey blob, that’s a throwback to the early 90s.

But after one year in an organization where nobody even knows what's ClearQuest for, I do miss it. 

I used to work in a company where we have developed over 250 CQ Schema Iterations. We have implemented a full ALM on CQ. We have integrated CQ with virtually every piece of development environment and with every aspect of software development, including: document reviews (with ergonomic sharepoint interface);  Continuous Integration builds on CruiseControl (on home-made steroids, of course - work item based, fully managed); code metrics; automated software QA reports. 

When IBM folks visited us, they were shocked what can be done in CQ. We exceeded all the limits of the tool. We developed more CQ schemas than IBM did for their internal needs! We created a real Process Enforcement Tool, and CQ was the kernel of it.

CQ might be perceived as the awful, buggy, old-school piece of ALM. But I will state again: you can build everything what you imagine, based on it. Just ask your engineers to do it. They know best, what's are the pain points of their working env, and they will improve it in single days, provided they receive your strong support, time allocation and opportunity to show themselves.

Now the hard part:I am a PM in a typical so-called weak matrix organization. This means that I don't possess an own team, dedicated full time to my projects. I just contract multiple persons for very part-time jobs (or single tasks). I don't manage them or their bosses directly. 

How a PM in a typical weak matrix organization can ignite the changes in dev env, dev processes and dev culture? Is he/she destined to fail?

Your thoguths?

sobota, 17 stycznia 2009

My day always ends when I'm tired and ready to go home, not when I'm done. I am never done. Like a housewife's, a manager's work is never done. There is always more to be done, more that should be done, always more can be done.

 Andy Groove, High Output Management

niedziela, 21 grudnia 2008

I love Zope. It connects python's well-known hiperproductivity, Java's best design patterns and component oriented programming. It is a real mental amusement to code in Zope.

Last months I haven't been programming too much. But I have a bad, worrisome feeling that Zope3 development pace has slew down. But I just thought this just means that I've lost my interest in Zope when I switched my job.

But today I've looked to zope wiki and discovered that there are virtually no new articles. I've also found that last release is almost one year old and zope 3.4.0c0 is not even a real release, but a release candidate.

Someone would say: hey, but maybe the development has just been decentralized? Zope 3.4 is the first eggified release, so maybe the development just moved to eggs (z3c.* and others). 

But I digged deeper and displayed some stats of Zope3-Users traffic, thanks to google. What I found is below.

Zope3-Users List Traffic - compared 2007 to 2008. 2008 traffic is more than half lower.

Maybe the traffic moved somewhere else? This hypothesis haven't worked: I looked to zope 3 wiki and:

  • the last new topic is 3 months old
  • last month there is one edit of a topic
  • After July 2008 there was not a one month with more than 5 edits.

To summarize: It seems that zope3 development and engegement have been stalled for over half a year.

Any thoughts? Have I missed some switch to other communication channels? Has grok really took of all the hearts and souls?

What are the causes of the slowdown?

niedziela, 14 grudnia 2008

Indicators tend to direct your attention toward what they are monitoring

Andy Groove, "High Output Management": Managing the breakfast factory.

 

piątek, 12 grudnia 2008

For over 4 years I was accustomed to the meetings making sense.

I knew that everyone coming to the meeting will accept or reject invitation, will come on time, will be prepared and will be constructive.

It would be simple when your company's boss name was Andy Groove: http://meetingsnet.com/strategy/cases/meetings_meeting_effectiveness/

Otherwise meetings become distorted, unorganized bunch of people presenting their statements whenever they manage to interrupt a statement of others, not listening others and not seeing any purpose of the meeting except that they can always say after the meeting that "look, I told you at the meeting that this can happen, you haven't listened to me, or you haven't reacted to what I said. You are stupid, you are the guilty!"

Effective meetings... how much I miss them,,,

 

One statement is a packaged set of multiple informations on different layers.

  • Facts
  • Self-disclosure: about me and my feelings
  • Relational: about relationship between sender and receiver
  • Appelative

It is important to remember everytime you send a message (email, telephone, f2f), you actually send four messages.

Different people receive these four messages with varying strengths: some of them receive mainly one of the layers, others receive all equally, or one of them depending on situation. But be prepared that someone understood your statement in very different way you mean.

 A good example: a marriage in a car. The husband is driving. They have stopped at traffic lights. The wife tells: "look, we have the green light!".

  • Facts: there is the green light, we can go ahead
  • Self-disclosure: I'm in hurry to the hairdresser!
  • Relational: You are hindsighted, I would drive to the destination much faster than you! How could I marry such a muff!
  • Appelative: please hurry up!
poniedziałek, 24 listopada 2008

I've just deployed my first not-so-small project.

It's time for some lessons I have learnt for the last half of the year

Partnership, trust and long term cooperation

What would you expect when a software house sells its software to its long-time customer?

I would expect the following: the software is really good, and there is a trust relationship between the companies.It's doesn't need to be always true, even when you try hard. Believe me or not.

Stakeholders communication is the most important thing

I always knew that, but in the pace of the project I tend to forget it. Communication always returns. Communicating issue early is easier and less painful. Asking about possible issue is always better than not asking.

But it's impossible (at least: for me) to ask all proper questions, foresee all the possible issues and remember about all the things you have to talk about. Should I accept that sometimes I fail to communicate something, or rather should I improve myself (how?) to make me more fail-proof?

Good software is not everything

If your customer is unhappy using your software than you have to be perfect. Once he/she like it, he/she'll forgive you everything. 

Solution: make a nice, usable, beloved pieces of software. Nobody likes perfect, but hard to use and not jazzy software.

 

 

 

piątek, 13 czerwca 2008
Human beings were not meant to seat in little cubicles staring at monitors all day, filling useless forms and listening to eight bosses.
niedziela, 13 kwietnia 2008

At the last SPIN meeting we discussed what's the difference between verification and validation. To summarize, I'll quote prof. Bogdan Wiszniewski, who quoted some common statement (also found in CMMI): 

Verification ensures that you built it right; whereas, validation ensures that you built the right thing.

sobota, 12 kwietnia 2008

Meetings have a bad name. One school of management thought considers them the curse of the manager's existence. But there is another way to regard meetings … a meeting is nothing less than the medium through which managerial work is performed. That means we should not be fighting their very existence, but rather use the time spent in them as efficiently as possible.

Andy Groove, http://meetingsnet.com/strategy/cases/meetings_meeting_effectiveness/

 

sobota, 05 kwietnia 2008
Untested code is broken code”
— Philipp von Weitershausen, Martin Aspeli
poniedziałek, 31 marca 2008

Total failure. After 3 months, I have decommited my participation in Wiki effort in my organization.

I advertised Wiki at scientific conferences. I know TWiki syntax and features inside out. I was a major driver of a difficult and complicated, but very successfull TWiki implementation in Intel Technology Poland. We changed the R&D world there, we changed the rules of the game, and it worked.   

I have never thought that in any place it can be more difficult to widespread Wiki than in Intelectual Property-savvy Intel. Now I know it can be more difficult. I still don't know why.

For now I just gave up. Hopefully something will reignite in near future.

For now I have to admit to my failure.

 

wtorek, 25 marca 2008

Fajna przypowieść o Marsjanach, którym zaczynamy sprzedawać MP3Playery ze słuchawkami. A tak naprawdę to historia o tym, jak trudnym problemem jest interoperability.

Cała historia - na Joel On Software

 

 

piątek, 22 lutego 2008

Some people think processes are unneeded bueraucratic burden. Some people think processes make engineers' work unpleasant make them sink in papers, instead of doing their job. Some people think processes forbid them to improve anything, change the way they work even if the way is silly, inefficient or error prone.

But a good process description can be a one screen long Wiki page, with a snapshot of a handwritten lifecycle drawn on your whiteboard. And such a process description may be good enough to pass a CMMI audit.

But do you know why I do like processes so much? ...

Because I like to change them. It is very difficult to change something if something does not exist. If you don't have your baseline, you don't know what the f**k is going on and what to change.

Writing a one-pager process description is about two-three hours of talking with engineers and one hour of writing. Then you can change the way your people work in any way you could imagine. Try to do this if you don't have a process.

 

czwartek, 21 lutego 2008

Where is Quality? Who creates Quality? Who can improve Quality? When should you check Quality?

Quality is not free. Everyone who knows ISO or CMMI, knows this fact and knows that even if not free, Quality is still cheaper than lack of Quality.

But not everyone realizes that Quality is Everywhere.  And you cannot have Quality by having a one, big check after some stage. There are some methodologies having lengthy audits and review phases at the end of each stage of the project. And these methodologies either fail or make your project ridicously long. And make your people to paint the grass green.

And there are also aproaches knowing about Quality is Everywhere. These approaches measure everything in background. They foster open communication and innovative thinking. They give managers quick feedback and prompt warnings, just after something wrong could happen - not months or years after.  They detect real problems and not only issues of "not enough kilogrammes of documents" class.

If you choose any methodology to improve your quality and your projects, whether it is ADP, CMMI, ISO, PMBOK, PMI, whatever - remember:

  • Quality is Everywhere: measure it as early as possible, only when you trust data is reliable, and in background
  • Quality is Everywhere: defects prevention is always better then defects detection
  • Quality is Everywhere: never blame people on errors. If you are Quality Manager, Project Manager, Engineering Manager - low quality is always your fault because you haven't set up proper Quality Management System. It's not a fault of your people, it's not a fault of engineers.
  • Quality is Everywhere: but you cannot have it without time spent for it.

So you can ask: I have a low quality project. I don't have resources for improving quality. What should I do. Where should I look for help?

LEAN can respond to your question: help yourself and clean up the things first. This doesn't cost you a broken penny. Ensure that you use bug tracking system. Ensure that your people know what to do next. Ensure they know what they do. Ensure that they have some backup and are not irreplacable heroes, because it's too big responsibility for any single person to be irreplaceable. Then - you'll easily find out next steps.

I hope I'm also able to clean up the things first and find out next steps.

Gdy przychodzi mail z recepcji że przyszedł pan sprzedający kanapki, a Ty, czytając ten mail popołudniu, pół minuty zastanawiasz się, czy można już go oznaczyć jako przeczytany.

(zdarzenie autentyczne)

niedziela, 17 lutego 2008

Stary osioł wpadł do wyschniętej studni. Gospodarz stwierdził że nie da rady go wydostać, osioł już stary, strata niewielka, więc trzeba go pogrzebać. Zaczął więc sypać ziemię do studni. Osioł na początku ryczał w niebogłosy, ale po chwili ucichł zupełnie. Gospodarz sypie, sypie, ale w końcu cisza go zaniepokoiła, więc zajrzał do studni.

Co się okazało? Osioł po każdej łopacie ziemi otrzepywał się z niej i udeptywał pod sobą. Jeszcze kilka łopat, wygramolił się ze studni i zadowolony podreptał na łąkę.

czwartek, 07 lutego 2008

Dzisiaj na SPIN pan Bogdan Bereza-Jarociński reklamował nową metodologię, z której będzie prowadził szkolenia i certyfikował: Automated Defect Prevention .

Wykład był naprawdę fajny, pan Bereza wykazał się nie tylko wiedzą ale i swoim talentem oratorskim. Automated Defect Prevention, to świetna filozofia. I tylko jedna rzecz mnie wkurzyła: przeciwstawianie na siłę standardu CMMI do tego nowego, kochanego przez Pana Bogdana ADP.

Wdrażałem CMMI. Znam go na wyrywki. Przeczytałem od dechy do dechy specyfikację modelu. Zgłaszałem do autorów błędy modelu. Wiem, jak zaimplementować High Maturity Levels (poziom 4 i 5). I nie zgodzę się na deprecjonowanie CMMI jako czegoś ciężkiego, biurokratycznego i nie promującego doskonałości.

Każdy, kto widział dobrze zrobionego CMMI, wie co to znaczy:

  • lekkie, automatycznie mierzalne procesy
  • procesy projektowane przez ich wykonawców (inżynierów), którzy wkładają w to serce i swoje niezrównane umiejętności, wiedzę i inteligencję
  • procesy doskonalone przy każdej okazji
  • automatyzowane testy, buildy, release'y, code review, pomiary
  • procesy, o które staramy się żeby były ergonomiczne i przyjazne dla ludzi (ADP'owskie Happy People)
  • wykształcenie kultury firmowej promującej szacunek do standardów i procesów
  • ale też promującej świadomość, że procesy są po to, żeby było wiadomo co się zmienia

Ja nie wyobrażam sobie innego CMMI. A takiemu CMMI nie brakuje żadnego ze składników, które pretenduje sobie ADP.

Tak, słyszałem o takich wdrożeniach CMMI, o jakich mówił Pan Bogdan. Tak, można spierdolić CMMI.

I gwarantuję, że za 3 lata będzie mnóstwo firm które będą twierdzić że mają ADP, a tak naprawdę (a) nie będą miały nic, albo (b) będą miały równie ciężkie i sztywne procesy jak te, którymi tak straszył Pan Bogdan w CMMI.

Podsumowując: przeczytajcie o ADP. A następnie: wdrażajcie CMMI, pamiętając o tym co przeczytaliście.

 

 

wtorek, 29 stycznia 2008

Był sobie kiedyś CMM: model dojrzałości firmy programistycznej, który mniej więcej mówi, co taka firma powinna robić, żeby być przewidywalne terminy i koszty oraz wytwarzać produkty przewidywalnej jakości.

Potem zrobili model CMMI. To taki CMM, tylko uogólniony na produkty sprzętowo-programowe, a potem na kolejne klasy produktów. 

Spytałem kiedyś jednego z autorów oryginalnego modelu CMM (jedynego którego znam osobiście :P), co o tym myśli. To taki starszy, dobrze ułożony pan, który wyraża bardzo wyważone i ostrożne poglądy. Zaskoczyło mnie, bo odpowiedział mi bardzo dobitnie:

They believe that CMMI applies to any "project", including house building projects, which of course is nonsense

piątek, 18 stycznia 2008

Okres spędzony w Intelu, dzięki wspaniałym szefom (Jackowi i Marcinowi) i całemu dream-teamowi CMMI, nauczył mnie jednego: nie ma rzeczy niemożliwych. Wszystkie upierdliwe, utrudniające i nie przynoszące wartości dodanej ograniczenia w organizacji są po to żeby a) ignorować je z powodu "business need" b) likwidować lub zmieniać je c) wykorzystywać je w dobrych celach.

Dziś przypomniałem sobie pojęcie "wyuczona bezradność" [Seligman, 1972]. Polega to na tym, że nie wierzymy, żeby nasze działania mogły wpłynąć w jakiś sposób na poprawę sytuacji. W konsekwencji - przestajemy działać w kierunku tej poprawy.

Skutki wyuczonej bezradności (ekstrakt z: Wikipedia, na licencji GNU FDL):

Ludzie szybko uczą się bezradności, czyli poczucia, że ich osobisty wpływ na sytuację jest nieefektywny.

To prowadzi do:

  • deficytów poznawczych: człowiek przestaje rozumieć co się w danej sytuacji dzieje i nie potrafi przewidywać dalszego jej biegu.
  • deficytów motywacyjnych: brak motywacji do działania i umiejętności angażowania się. Długi czas dochodzenia do równowagi po porażce.

A jak oduczyć się wyuczonej bezradności? Myślę, że trzeba zrobić taki find&replace we własnym mózgu: zamiast myśleć "jest problem bo klient jest taki i owaki", myślimy "jest problem, bo nie zadbaliśmy o to, żeby klient był siaki i owaki. Zamiast myśleć: "nie da się tego zrobić, bo to zagrożenie bezpieczeństwa", pomyśleć: "ryzyko z powodu zagrożenia bezpieczeństwa jest mniejsze niż koszt niezrobienia tego". Kilka schematów myślowych tego typu, które... działają jak magiczna różdżka, szybciej niż nam się wydaje!
 
PS Udało się. W książce wydrukowali poprawnie moje nazwisko - tylko mój promotor miał pecha :P

 
1 , 2