Project Management methodologies are like recipes. They are. Stop fooling yourself. Ten steps to success, 2 steps to annihilate poor-performance teams…whatever. Have you ever tried to cook?
You can’t cook so you follow a recipe. It may work or not. Surely, even if it does, one thing is guareentee : it will never taste as good as it could.. you’re missing some natural talent, inspiration, intuition…more than this.. inspiring yourself by tasting and feeling what you are doing.
Managing projects is like cooking. Nothing guareentess you’ll manage it by following the recipe. Best case scenario you won’t fail completely..but surely you will not be fully successfull. Even if you manage to do a good product in time (which I honestly doubt), you’ll loose your team – or working group..because if your following recipes, they don’t teach you how to grow and manage teams, rather how to discipline and dictate working groups.
So, when managing something think about cooking. Feel the flavor, smell it. Talk to those that will eat your food, eat it yourself and see what’s missing (aka eating your own dog food). Gather insights, inspiration, suggestion from others in the kitchen. Don’t blindly follow the recipe. You’ll end up with an tastefulness thing in your plate and you’ll never be a Chef!
My pre-weekend 2 cents.
I would simply quote Hannah Arendt:
“Storytelling reveals meaning without commiting the error of defining it”
Carpe Diem! :)
Because we should never forget them
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.http://agilemanifesto.org/
Manage by means, not by numbers
Loved it when I heard it. Although it may go against all principles of simplicity. No way you can manage anything in a simple way if you’ll do it by means. So much simple to manage something by numbers.
Anyway, I really liked this sentence. So full of meaning in any workplace pilled up with burocrats (not saying mine is). Although I guess if this sentence is said in this kind of place, probably it won’t be understood anyway. Worth the try.
But this was before. Then I realized this sentence is not all it represents. There’s a hidden place between “manage by means ” and “not by numbers. Yep! I’m talking about the comma. That damn comma is important, believe me.
That “Comma” (I now assume it as a divine entity full of wisdom and magic) knows about the in-between of decisions. I heard her whispering…
Except if the mean leads to a number… then.. don’t fool yourself.
Take the courage to assume you need a number. If you do that, at least you are giving yourself a chance and the others fighting along with you.
Nothing else is more deadly than the lack of expectation.
We walk, run, stand, fight, we go to the end of the world. We just need to know whom to follow and why. Show us a mean. Even if it is a number.
I guess she’s right… I don’t want to be top of the class… I want to be number 1.
This last weekend Agile has just turned 10 years old.
I was still in School. And I guess back then I already applied some Agile principles. We all did.
I used to brief with my closest colleagues between classes. (15 minutes break) [Daily Scrum?].
I used to have a small group of colleagues (around 6) with whom I used to study [Scrum Team?].
We got together in this open space in the School, like a lost space faraway from classrooms, no noise, a big table were we could all site face to face and discuss [Open Space ?].
We used to define action items and subjects to study as well as prioritize them and define a timetable for them- ok today we’ll study Maths in morning doing exercise 1 and 2 and afternoon we can study Porter’s chaperts on Management [Backlogs ?].
We used to do some pair working- specially on those Math or Algorithm exercises, we used to sit by pairs having one person that really understood those exercises and another with more difficulties. It worked. [Pair-working?]
While explaining one exercise, we could think about why it was like that and figure out why it was like that [RCA?]
we used to go out and drink after exams (Also after the exams results- no matter what result) [Team building?]
We used to organize ourselves- Whom would go and request books from library, ask the teacher for help on some doubts, take fotocopies, go to other group and ask for help or material on some suject [Self-organized?]
“I heard that chapter 10 and 11 will also be refered in the test- we need to study those, lets re-plan our study” – we used to welcome late requiments.
So many silly little things we used to do, not only while at School. And we all did it. Think about it. This was already Agile oriented. Why were we able, back then, to keep our eyes on the ball, keep simple.. get the job done..and now..it looks so complex and hard to do.
Is it that we forgot to embrace our job as we did back then?
Happy anniversary Agile!